In this video on my YouTube channel, I explain how to build a minimum viable product (MVP), by selecting a feature that shows users your core value proposition, as well as two features that “delight”.
Whether producing a software product for a new market in a startup, or introducing a major change in an enterprise – planning a minimum viable product is a good idea.
When building a minimum viable product (MVP), you should select a feature that shows users your core value proposition, as well as two features that “delight”.
The core value proposition is a part of the Business Model Canvas, a visual tool created by Alex Osterwalder that you can use to determine which aspect of the business is being effected by a change.
The “delighting” features provide something sexy for users that is a differentiator and attracts potential customers due to it’s sleekness, innovation, or ease of use.
When planning what goes into an MVP, don’t budget for only the MVP. Budget for enough to build software for 6-12 months that will adapt to feedback.
Spend a small portion of the total budget to release the MVP, and use the majority of the remaining budget to adapt so you can deliver exactly what customers want – and in the way they want to buy it. These other “ways” than the product’s features itself are the other aspects of the business model canvas.
If you only budget enough for the MVP, you won’t have money left over to adapt. Adaptation is the difference between a product that “meets needs” and one that “exceeds expecations”. It is this latter category of products that cause companies to be leaders in their market and cause substantial growth.
When selecting technologies for the MVP, don’t box yourself into feeling you need to use technologies already familiar to the development resources you might have. Hiring a specialist in a technology that is faster to build prototypes and minimal products in can save substantial money.
Should the market lead you to find that what you’ve built is successful, you can always change the technology used down the road to meet scaling challenges, if the original technology can’t handle the volume.
This is a GOOD problem to have, and means you’ve found a large user base – but until this happens, don’t spend the time and money planning for it! You need as much budget as possible to simply ADAPT at first, and so your money is better spent with excess funds for adaptation than building out an infrastructure or technology stack that assumes a size of user base you don’t yet have.
You can watch my video on Lean Software Development here.
You can watch a short video about the Business Model Canvas here.
You can watch my video on Agile Project Management here.