“A minimum viable product that is anything but minimum.”
This is part of my Nokia Startups Mistakes series. For a backgrounder, please read the introduction. This post is directly related to previous posts about the culture, the high burn rate, and being close to the customer.
For engineers with Nokia background, it seems customary to build gigantic minimum viable products (“MVP”). Nokia is not known for its agile software development practices. On the contrary, according to many Nokia alumni, it always took a hundred engineers to build anything at Nokia – no matter how small.
It takes a lot of product vision to define a meaningful MVP, and not being close to the customer makes it even more difficult.
How to keep the product minimum?
- Avoid excess funding,
- Slideware, paper prototypes, UI sketches are an excellent way to test market.
- Start with a small nimble software team comprising one to five people. If you need a bigger team, it is unlikely that you are building the minimum.
- Use agile and iterative software development practices.
- Get out of the room and establish a feedback loop with a few lead customers early on.
It is much easier to work with the problem definition and play with various paper prototypes etc. longer when there is only you and perhaps your co-founder. The whole situation changes mentally when you have even a small software team in place, and guess what they start to do?
Yeah, right – they start to code while it in many cases would be much wiser to keep working with the problem definition and cheap paper prototypes.
I hope you will enjoy this series, the thoughts it provokes, and the discussion it triggers. Please do participate to the discussion by sharing your own angle and experiences on this topic.