From 0 to 0.0.1

How we’ve built a startup from a doomed product.


Chapter 1: Qwote

The journey starts back end of 2014 when my co-founder and I were working on a side project called Qwote.

Qwote is a Chrome extension that lets people highlight, share and save snippets of text, images and videos quickly.

When you find something interesting on a website or blog, just highlight it, click on the Qwote button and share it with your friends, colleagues or followers on Twitter, Slack, Facebook, Google+, etc.

What’s different about Qwote?

Unlike other highlighting tools out there, Qwote redirects users to the exact location of the quote within a webpage — which makes it very easy to pinpoint specific passages in long documents, FAQ, etc.

It’s quick, simple and very effective. And we (still) use it a lot internally.


Chapter 2: The Fame

The product organically gained some traction and got featured in blogs and newsletters, including Netted by the Webbys and Product Hunt 😽.

We had a lot of positive feedbacks, users coming from around the world and a ton of new cool features to implement…

We saw an opportunity and decided to leave our daily jobs to start working on Qwote fulltime.
My co-founder, Tierry, was a frontend engineer at Fifty-Five, a data an analytics company. 
And I was working as a business manager at Apple.


Chapter 3: Back to reality

Engagement and retention metrics didn’t take off, user signups were declining…

We had applied to a few accelerators to get some help and funding but got rejected each time.

We were scratching our heads to figure out what to do next but we knew that Qwote wasn’t going anywhere per se. We had no targeted audience and no product/market fit. 🎯

All sorts of people were using Qwote: data analysts, designers, PhD students, sports fans, developers

And they saved all sorts of content: poems, code, sport results, gifs and even sex pics… 🙈

When you’re targeting everyone, you basically target no one.

We knew that if our product didn’t solve a real pain for one of our audiences, adding new features wouldn’t fix it. 💩


Chapter 4: The Backup Plan

We decided to play our own version of the MVP playbook and laid down a strategy to lure users and find out our target audience:
 
1. We segmented our audience into 13 different categories;

2. Then created dedicated landing pages with distinctive value propositions for each segment;

3. We then launched an ad campaign on Facebook for 1 week with a small budget to target those audiences;

4. Each ad redirected visitors to the dedicated landing page and through a tedious funnel before they could signup — just to make sure they were REALLY interested in our product;

5. And eventually, we invited them to leave their emails.

Our funnel:


Chapter 5: The Results

Luckily for us, the results were pretty clear.

Developers were the most interested in our product.

They converted with:

  • CTR of the ad: 0,38% versus 0,16% on average for all other audiences;
  • Conversion rate from the landing page (i.e they clicked on Pricing and Plan): 32% versus 10% on average for all other audiences;
  • Conversion rate from the pricing page (i.e free or paid plan): 37%
  • Even 3 of them clicked on a Paid Plan — without seeing anything from the product…

Sure, the figures were low and probably not statistically significant — but hey, we dealt with what we had at the time.

The value proposition we had put forward for developers was pretty straightfoward. Developers could build their tech library.


Chapter 6: The Pivot

We had identified an audience interested in our service. We now had to sit down and think a lot about the main problems developers had to face when building up their personal library of content (code, frameworks, docs, etc.).

Since Tierry is a senior fullstack dev, we quickly identified 3 major pains related to content/resources:

  1. Keeping up with all the new materials being pushed out every day is hard but also critical to build robust and reliable technology;
  2. Choosing the right resource can be daunting and is (very) time consuming;
  3. Saving useful resources is difficult because bookmarking tools are not designed for developers.

Early January 2016, we launched the new website… without actually building the product itself.

We then posted a short message on some targeted communities on Google+, Reddit and on Hacker News… Et voilà!

2,000 developers signed up in less than 3 weeks

The response was extremely positive — developers came from +100 countries and were really enthusiastic about it.

We had spent 0$ in PR or marketing and had not wasted our time building something nobody wants. 🎉 💵


Double check:

To make sure we were still in the right direction, we implemented a feedback loop and asked 3 questions to each new user via email:

Again, the feedback was really helpful and positive and confirmed we were onto something.

It was now time to actually build the product…

Chapter 7: SlugBay

In September 2016 (9 months later), we launched a first version of SlugBay in private beta.

SlugBay is a new platform for developers to find, save and share resources. Think Pinterest for developers.

Since the launch, we have a gathered a growing community of developers saving a lot of useful resources. More importantly, they’re helping us shape the product.

SlugBay is still in the very early days but I’m confident it’s something useful for developers.


Update: Since I wrote this article, I’ve joined AB Tasty as their new Head of Product. I’m no longer working on SlugBay full-time.

P.S. If you’re interested in SlugBay and want to get in on the beta faster, send an email to (tierry@slugbay.com). ✉️ ⚡

P.P.S. Thanks for reading this far! If you found value in this, I’d really appreciate it if you recommend this post (by clicking the ❤ button) so other people can see it!.