Setup
Seven months ago, the idea for a “FaaS webpack integration” emerged at a team brainstorming session. As with most great ideas, it was initially misunderstood, miscommunicated and therefore, dismissed.
Three months ago, it became apparent that some changes were needed. We had a few great customers with some specific use cases, but in order to continue growing, we needed something more. We still believed strongly in our core product value (scalable and easy to use cloud compute), and therefore weren’t looking to create something entirely new. Instead, we wanted to take the product we loved and shift it, so more developers could love it too.
Over the following month, all energy was dedicated towards understanding our options. We revisited past ideas, came up with some new ones and did as much market research as possible. The outcome: a narrow list of 4-5 ideas for repurposing our existing product to broaden developer appeal. On paper, a few of the possibilities seemed to have real potential, but the excitement wasn’t there. As a business, not choosing a potentially lucrative path due to lack of internal excitement is one of the hardest choices to make, but almost always the right one. Great products are equal parts understanding your users, solid engineering, and passion. It’s possible to have a successful product without passion, but not a truly great one.
Two months ago, a reimagining of the webpack idea popped into my head, and I started to feel the excitement. After spending some serious time researching the front-end ecosystem, it became clear that there was still no adequate solution for full-stack development. There were a myriad of offerings, but none of them seemed to address the crux of the problem.
Product Definition
Using the webpack plugin as a basis, I began imagining a platform that would enable front-end developers to focus only on the things that bring them value. Armed with this idea and the approval of Avner (our CEO), I quickly began work on a demo version of the system with the help of Vladimir (one of our senior engineers).
Two days, a few thousand lines of code and too many cups of coffee later, the demo system was working. As an engineer, I can proudly say it was one of the most hacked together, janky pieces of software that I’d ever been a part of, but it worked. I was also quite nervous, I felt very passionate about the idea and was worried others might not like my interpretation of it. Avner was the first to try the demo, he instantly dispelled any worries I had when he said “Where has this been all my life”.
As the rest of the team heard about the idea, excitement started to grow again. Not wanting to lose momentum, I began pushing for an initial “demo release”. The demo release would only include a video and a blog post, showcasing this new product. It’s always important to validate your assumptions and beliefs, before investing dev resources in a full fledged product effort. The demo proposal was quickly approved. So I began working on a product document, that I could use to align with the rest of the team. During this time, Roey (another senior engineers) had played with the demo system, and started making some feature additions. Within a day he released a highly improved version of the original demo system. Working closely with him, I was able to quickly iterate on an initial proposal that could be shared with the team.
After collecting more feedback from the team, I set to work preparing for the release. It was Monday, and I had agreed to Friday for the release date. There was now a deadline looming. I needed to make the videos, get the demo system and code presentable enough for the video and prepare the material that I planned to release on social platforms. The first thing I handled, was setting up accounts for social sharing, those can take days to become usable (for example reddit). Next priority, was getting the code presentable, as this was a blocker for the video and other content. This process took a few iterations, which is a challenging feat, considering our 10 hour time gap. Everyone pushed extra hard and stayed in constant communication, allowing us to avoid basic misunderstandings. During the periods of downtime, I made the necessary modifications to the demo system so it would be presentable for the video.
The Final Push
It was Wednesday by the time the code had reached an agreeable state. I now had two days to publish the blog post and make the accompanying video. After a 14 hour push on Wednesday, I was able to finish the initial draft of the blog post and video. For our team in Israel, weekend begins on Friday, making “Israeli Thursday” the “American Friday”. This meant, it was the last real opportunity to get feedback from the team. Unfortunately, when you do 14 hours of work without communicating, there’s a high chance of misalignment. So when I woke up Thursday morning, it was to a daunting number of comments, suggestions and fixes on my post and video. It was obvious that my document and video didn’t meet the team’s expectations. So instead of trying to “put a bandaid on a broken leg", I decided to start from scratch, using the feedback I had received as a guide. After another seriously long day, V2 of the blog post and video were complete. At this point I was feeling very stressed. Release was set for the next day, and both components of the release (blog post and video), were entirely unreviewed.
I woke up the next day, fearing the worst. My phone was full of notifications from Google docs. I immediately jumped on the computer, and was incredibly relieved to see that this time I've hit home. While there were considerable comments, they were much less fundamental compared to the previous day. All of the actionable feedback could easily be completed within a few hours. This was still far from optimal, as it’s never a good feeling to be working on a release the day of release. It was also Friday in the states, which is deep into the Israeli weekend. Fortunately, Michael (our CTO) sacrificed his weekend and supported me in every way he possibly could. This allowed me to quickly address the feedback on the post and video, making them release ready.
As I went to publish the post on our blog, disaster struck. The npm package ecstatic which our blog depends on, had been unpublished entirely from npm and removed from github, just 1 hour before. I first attempted to look for an older version, but the author had been incredibly diligent about wiping everything ecstatic related. Luckily, Michael had a cached version of the blog on his computer. Using him as a proxy, I was able to make the final formatting changes and corrections, allowing me to release the blog and video.
Gathering Feedback
It was time for the hard part, getting people interested enough to give feedback. There’s absolutely no easy way to go about this, and usually brute force is the most viable option. I knew that if I limited the marketing effort to a single platform, we would receive nowhere near enough feedback to reach a reliable conclusion about the product. To increase our chances of success, I opted for a breadth approach. This meant posting on countless subreddits, Slack, Discord and Gitter channels, Spectrum chat, Twitter, YCombinator, Dev.to and many many more. Even then, things were difficult. Getting people to give feedback is much harder than getting them to retweet, like or upvote, the conversion rate is incredibly low.
But it seemed my efforts were not in vain. After a few hours, our post on /r/reactjs hit the front page. The comments we received were incredibly insightful, but there were only a handful. This isn’t surprising considering we only had a video and blog post, meaning that potential users had “nothing to try”. In fact, the number one criticism we received across all platforms was, “it’s hard for me to judge it without trying it”.
Once it became clear that the reddit posts were not generating enough feedback, I shifted efforts elsewhere. I knew that the only reliable way to get more feedback was by starting 1:1 discussions on a live chat platform. So I began posting in every Discord, Slack and Gitter channel related to our space, immediately responding to anyone who showed interest. This is an incredibly uncomfortable undertaking for many people (myself included), but resulted in the most (and highest quality) feedback by a large margin. It’s also very time consuming, so the rest of my day was spent strictly DMing potential users.
By the end of the day, I had managed to collect a substantial amount of feedback. My hundreds of conversations allowed me to produce a list of 40-50 tangible criticisms and observations, which is exactly what I set out to collect.
Takeaways
There are definitely some learnings from the experience, I’ve shared those below
Communication is critical. Without daily syncs and continuous alignment checks, the release would have never been possible. Teams that are constantly communicating are usually constantly productive. This is especially important with a remote team spread over different time zones.
Prepare in advance. Because I didn’t fully prepare for the social marketing effort, a few channels weren’t available to us. Remember, each platform has its own requirements and etiquette for posting. You definitely want to get those things underway far before release day.
It’s never too early for feedback. We didn’t have a usable product, demo or even solidified APIs and we were still able to get the validation we needed. The top priority for any new product should always be validation.
Initiate dialogue. It’s always uncomfortable to start a conversation with a stranger. Most times, if you’re willing to initiate, people are more than happy to give their opinions. The majority of the positive interactions I had, stemmed from me cold starting a conversation.
Overall, it was an incredibly valuable and defining experience for us. We gained the confidence needed to feel comfortable moving forward with a new product.
Updated (July 31 2019): Over the last few months we've been hard at work to provide something that will change developers lives. Binaris is now ShiftJS. If you've ever thought that full stack development isn't quite as easy as it should be, ShiftJS is for you. We have a killer team, and with the addition of Amir Shevat (previously VP Product Twitch/Amazon) as CPO, we are now full fledged ninja assassins. Join us!
We are now in private beta. If you’d like to give ShiftJS a try, sign up for the waitlist here.
For those interested in seeing the original blog post and video in question.
https://blog.binaris.com/cloudless/
Top comments (0)