Jasper den Ouden6 min readWe've helped dozens of startups build their first product, and the same three mistakes keep coming back. We've made them ourselves too. They come down to where the effort goes, rarely to talent or hard work.
Mistake 1: Building too much
An MVP is not version 1.0 of your product. It's the smallest thing you can build to test your main assumption. If yours takes more than six to eight weeks, it isn't small enough.
The trap is that every feature feels indispensable when you're close to the idea. Most of them are bets you haven't earned yet. Pick the one thing that has to be true for the product to work, and build just enough to find out whether it is. The rest waits until a real user asks for it.
Mistake 2: Testing too late
Don't wait until the product is finished to talk to users. Test your assumptions with a clickable prototype, a landing page, a sketch on paper if that's all you have. The earlier you learn, the cheaper the lesson.
A change on a sketch costs you ten minutes. The same change after launch costs a week, plus the patience of the people who already hit the broken version. Put something in front of five people this week and watch where they hesitate. You'll learn more than another month of meetings would teach you.
Mistake 3: Solving the wrong problem
The most expensive mistake is building a beautiful solution to a problem nobody has. Go into the problem before you start on solutions. Talk to the people who'd use it. Look at how they solve it today.
The workaround they use now is the signal. If people have already rigged up a spreadsheet, a group chat or a pile of manual steps to get the job done, the problem is real and you know exactly what better looks like. If there's no workaround, ask why. Often the problem just doesn't hurt enough to pay for.
Start as small as you can
All three mistakes come from the same place: you commit before you've learned. The cure is to make the first step small enough that being wrong costs little.
That's what a design sprint is for. In four days you go from a vague idea to a prototype you test with real users, without a line of production code or months spent on an assumption no one has checked. After those four days you know what to build, what to drop and why.
