You are viewing a single comment's thread from:

RE: How I bankrupt my first startup by not understanding the definition of MVP - Minimum Viable Product

in #programming8 years ago

This is a useful article for me, as I'm working on setting up a software startup. I'd identified the needs more-or-less correctly, but I was utterly stumped on what to actually do about them. It's extremely difficult to identify what is "added value" when, a lot of the time, the customer knows objectives from their perspective but not what is needed to achieve those objectives.

Two, maybe three, entire courses at university were dedicated just to this one problem, of analysing user behaviour in order to infer user requirements, because the user is often the last person to know what they require from the perspective of a software or hardware engineer. What users believe they want can end up being something the user hates and loathes because it gets in the way of what they actually need.

On the other hand, you can't disregard the user either. Giving them exactly what they needed but not what they wanted has been disastrous for many products down the line. Even when it hasn't been catastrophic, it hasn't done the product much good either. Linux and OpenBSD are technologically superb products, best-of-breed without fear of doubt or contradiction, but there's a reason why Microsoft can have disaster after disaster for the best part of a decade and lose only 1% of their desktop marketshare to these two systems (and why Microsoft can have essentially equal marketshare in the server market) - the user is only getting what they need and not what they want.

At university, the courses considered contracted businesses going and engineering a complete solution for one individual customer. That market is dead, Netcraft confirms it. Seriously, though, you can't use that approach when you're trying to sell to a lot of people. You can't visit each one and try to engineer something that works for everyone. Too many people, most of whom are unlikely to welcome door-to-door systems engineers.

I still don't understand how to conquer this problem, but (a) I now know I'm trying to solve the right problem, and (b) I now have key terms and vital explanation for how to go about solving it.