Lots of people using a free product is validation that people want to use it for free. It’s not validation for a business model.
Last September I launched Markfolder, a free Twitter bookmarking browser extension and web app.
I built it for myself because Twitter’s bookmarking sucks* and I needed a better user experience for tweets I want to save and get back to later.
(*Twitter’s new premium product, Twitter Blue, will improve upon their bookmarking feature).
It was a side project that had suddenly become my focus for the last few months, due to
- the steady growth of users, all through organic search and word of mouth, and
- great feedback from existing users. A few users even said that they wanted to pay for it, because they love it!
I spent 2 months polishing the product and adding the first premium feature (keyword search) for a new Pro plan, and launched it to the existing 500 users.
The result: zero sales.
Nobody upgraded. Not even the users who said they want to pay for the app, ffs!
What I did wrong
Let’s start with what I did right, at the start of this project:
- I looked for the existence of the problem I’m trying to solve.
- I created a landing page for people to signup.
- I was building it for myself.
- I shipped an “embarrassing” MVP which was good enough to use.
- I iterated.
And then I fell back into that bad habit of building before validating.
I would make “improvements” without talking to enough users. The first few were fine, because they were improvements that I needed for myself anyway.
But then when I saw the encouraging metrics and when I thought this could turn into a premium product, I started imagining customer needs. Of course they’d want to pay for keyword search! Who doesn’t? Google who?
Hindsight is a wonderful thing…
Unclear customer — problem fit
I knew the problem I was trying to solve, because I had that problem.
But I didn’t know whom exactly I was trying to solve it for. Everyone? Everyone like me? I did write down “Twitter power users”, but what does that even mean? Do they tweet while doing a handstand?
If you don’t know who you’re trying to solve a problem for, then you’re building for nobody.
Yes, it could eventually be a product for everyone, just like Twitter is, but building for everyone from the start is like setting sail for everywhere and hoping to get there.
I ignored my best user — me
As I said, this was initially built for my own use.
But somehow, down the line, I even ignored the improvements that I myself wanted, and started going after features I “thought” people would pay for.
What I needed were incremental improvements that would make the product do “one thing really well”. Instead, I went after more features, trying to make the product do more because I thought this is what people would pay for.
Free too early
I made it free without figuring out early on whether it could work as a paid product. Which would have been fine if I wanted to keep it as a free product.
Looking back, this product is solving a pain that isn’t severe enough for most users. What I should have done is to identify a painful enough problem and validated that people would pay for it, right at the start.
Lots of people using a free product is validation that people want to use it for free. It’s not validation for a business model.
(Freemium itself is a valid business model, but there should be a good reason for the free tier, e.g. for lead generation).
For the new premium feature, I have an upgrade CTA for free users. This would have sufficed to test demand before spending days building out the feature!
What’s next?
Time to get back to basics:
- Ensure I have all the basic assumptions written down so I can systematically validate them. I did have a Lean Canvas created for this, but it got neglected. It’s been updated now with new learnings. One pleasant surprise: the assumption that my early adopters are writers and academics were validated!
- Identify a specific niche to serve. Obviously, I’ll be going with the validated early adopters. But I’m going even more niche — newsletter authors. I think there are interesting problems to solve for this group that Markfolder can pivot to.
- Keep the product scope narrow for now, but for a large enough market. Twitter bookmarking is fine for now, but for the niche I’m thinking of serving, it will need to expand past Twitter ASAP.
- Systematically test those assumptions before building. For everything. And I need to stop building before validating (unless validation requires building).
- The most important one: talk to my users. Every week. This is the only way to discover real pains to solve and if my solution to them are acceptable.
What I’ll do differently next time
Raise VC money first, of course… just kidding! Such blasphemy.
I think building for yourself is still one of the best strategies because you know straight away whether the problem is real and whether the solution makes sense. My experience with Markolder confirms that. Failing that, I would build for a customer segment that I know well.
Next is to identify a real pain point to solve.
Then, combined with a large enough market of people willing to pay, those will give your idea a great start.
In fact, I have already started doing this for my next project (that I’m going to work on with another person).
To help me with my evaluation, I’m using a pre-evaluation worksheet from my eBook, Start Strong: How to determine if your SaaS business idea is worth pursuing.
The hustle continues.
And you can follow my progress with Markfolder and my next project as I build in public on Twitter: https://twitter.com/farez
