The mistaken assumption of software startups

We all know that most startups must fail. But after working on many different projects, it surprised me that many seemed to struggle because of essentially the same problem - they underestimated the difficulty of acquiring users.

Building a product is just the first step, so here is some of my advice to deal with the real challenge of attracting and retaining users.

Balance confidence with scepticism

As a startup founder, you'll spend a lot of time talking about your ideas. While pitching confidently is essential for inspiring teams and attracting investors, it is important to balance confidence with scepticism in the planning of your product. When you're building your product, you have to ensure that you test your ideas.

Don't let your confidence become dogmatic over-confidence. Until you've actually shipped anything, it's not a done deal - you don't have any users yet.

You're probably working on your product because you're excited about it. You may be surprised by the indifference of your potential users - even if your product is objectively better than what they currently use, they may not care enough about the advantages to make the switch.

Until you've acquired users who have begun to rely on your product, you are the one who cares the most about it, and all your potential users care less than you do.

Don't build too much in one go

Most ideas can be built, it just takes time. The more features you include, the longer it will take. The longer it takes, the more it costs.

If you have too much confidence in your idea, and in your ability to acquire users, you might conclude that you may as well build all your features now. After all, why bother having multiple releases if you're going to have tons of users as soon as you announce your completed product to the world?

But that's not how it works. If you don't release and test your first features with real users immediately, you're robbing yourself of essential feedback.

If your product is not complete enough to convince anyone to pay for it yet, give it to your test users for free, or you can even pay them to use it.

Gather facts in your user research

You can actually pay your potential users for information before you've built anything at all, but make sure you focus on the facts.

If you ask your potential users whether they would find your product or feature idea useful, you'll get misled by the number that say "yes" when they are really a "no".

They don't mean to mislead you, some might say "yes" out of politeness, but it's mostly because they can't predict their own behaviour until they actually try using it.

Instead, it is better not to put too much weight on these subjective questions and to ask your potential users things that are much easier for them to answer - simple facts. You can ask them how many times in the past year they've experienced the problem that your product solves, or how much money they spend on similar products.

Measure impact as well as value

Solving a real problem is important, but impact matters equally.

This is a bit like Bayes' Theorem - having a brilliant solution to a problem doesn't matter much if very few of your potential users ever experience that problem, or if they only experience it infrequently.

This applies to feedback too. If 80% of your users tell you they need a new feature, but it is the other 20% that account for most of your usage, it may be more worthwhile to make small improvements that only 20% want, instead of building new features that 80% want.

Avoid feature overload

The mentality of continuously adding features in the hope of attracting users can lead to product bloat.

Don't assume that your struggle to acquire users is because you haven't got enough features yet, and set about adding more features that no-one will ever use.

If you're testing your features early immediately, you'll already know which ones are useful. Consider deleting the ones that aren't before letting your product get bloated. Quality trumps quantity.

Conclusion

The path to building a successful product requires much more scepticism and adapting to feedback than you might expect. Hopefully by following these principles you will increase your chances of building not just a software product, but a thriving user base.