Common failures in creating Minimum Viable Products & how to avoid them — Part 1: Business vision and prioritization in MVPs
Jakub Maziarz | May 1, 2024
Welcome to the first article of our key ingredients series for excellent Minimum Viable Products. This article highlights the importance of a clear business vision and effective prioritization in MVP development. There is, of course, a lot more to get into on the topic, so remember to check out our other posts in the series on Ownership and team dynamics in MVPs and Technical capabilities, metrics, and feedback in MVP development. Together, this article series will guide you on how to build successful MVPs.
Articles in this series:
Part 1: Business vision and prioritization in MVPs
Part 2: Ownership and team dynamics in MVPs
Part 3: Technical capabilities, metrics, and feedback in MVP development
- Core IT as a bottleneck
- No success metrics & feedback gathering
- Conclusion: How do we ensure you won’t fail with your Minimum Viable Product?
Business vision and prioritization in MVPs
The Agile Manifesto, which is considered the start of delivering Minimum Viable Products to the market just in time, was created in 2001, over 20 years ago. Common sense suggests that after that time, we should have mastered MVP delivery - and yet, 90% of startups, companies where the minimum and fast approach is a native one, fail (source: Forbes).
Why is it so difficult to deliver something minimum & succeed? Can’t I just design the Product UX, then the architecture - and give it to my engineers expecting delivery? Well, you need much more than that. Let us look at the most common failure pillars for the best business ideas to become the worst nightmare for investors.
Lack of Business Vision
The first one is the misunderstanding between idea and vision. An idea is something that pops up in your mind one day, that something is missing from the market; or something existing on the market can be done better. An idea has no metrics, no market recognition, no clear customer definition, and no clear definition of business value and customer journey. An idea is just… an idea. And the vision is what you need first. According to Fortune, the lack of market need for the Product is a reason why 43% of startups fail.
So… what is a vision then? Well, besides the idea, you need to have a clear understanding of who the customer for the product is, what the value proposition of your products is, how the product will make or save you money, and what and who you need to create it. You simply need to define why the customer will be choosing your product instead of what is already on the market. You also need to understand the surroundings of your product - if your company is ready for MVP creation, who are the competitors, and partners and who are the MVP stakeholders? The definition of a vision is essential for the product to be accurate and well-designed (both in business processes and technical levels).
Here are the common mistakes in business vision creation:
- Treating a business model as a vision: How you are going to make money on the product is not a business vision. “Making more money than we do now”, “30% of income growth in 2024” or “reduction of operational costs” as well. The vision is not about you - the vision is about who the customers are and what you provide for them better than anyone else.
- Starting with technology: The vision is not “leveraging AI in business processes”. The vision is neither “making the best-automated platform with terraforms”, nor “implementing CRM”. Those are vision execution plans, not the vision itself. The vision itself consists of the definition of the customer's pains or needs first - and then thinking about how to solve them.
- No customer and value streams definition: A common mistake is creating products for… everybody. There is nothing in the world that is universally needed at all times, except water, oxygen, and food. If you are thinking about a digital product (or a digital channel for your product), and not having your product personas defined well you’ll end up with a headache during the prioritization and design of business processes, customer journey, and technology architecture.
How not to fail?
In platformOS, we work with our customers and partners to co-build the vision of a Minimum Viable Product. In contrast to classic IT companies, we do not ask “what scope is required to be delivered” - instead, we are interested more in “what is that you want to achieve”? We have designed our own MVP Blueprint covering that part - where we use a series of workshops supporting our customers to express, clarify, and design their Vision. Depending on the case, we use market-known techniques such as Business Model Canvas, Product Canvas, Inspiring Product Vision, or Lean Canvas - so the vision becomes understood by all MVP Team Members (including engineers!).
Making everything a top priority
Prioritizing is probably the second most difficult task during Minimum Viable Product planning (after the Business Vision). Avoiding prioritization and treating each feature as a must-have is what essentially kills the idea of a “minimum viable” solution. This is because the need to implement every feature results in poor time-to-market. The main reason for “minimum” in the MVP is to live-test the business vision and value proposition - and then decide on the continuation and direction of Product Development based on real feedback from customers. You don’t want to invest tons of dollars and wait a year to learn that the market does not need your Product, right?
Here are the common mistakes in prioritization:
- Prioritizing features outside business vision and customer definition: The business vision is not just a nice piece of filled-up canvas on the wall. Business Vision should be a prism on every decision you make, starting with features definition and priorities. So if you build a product for elderly people who buy medicine, would an NFT token for every purchase be the best idea to spend time on building…?
- Prioritizing features that are edge cases: The Pareto Rule should be your friend while building MVPs. So if 80% of the cases are covered, you should go to market instead of waiting for those specific, development-consuming rest of 20%. For example, it’s better to even manually do part of the business process for edge cases - and release a month later, than wait for a complete, automated coverage of all cases. Remember, at the beginning, you can’t be sure if your vision is accurate for the market - so if you release faster, you’ll know sooner! And you will avoid further development costs if the market does not receive your product well.
- Prioritizing features based on “guess” or the “loudest stakeholder” voice: Every Product creation has more than one interested party (a person or a group of people) - and leading the prioritization based on the “importance” of this party instead of Business Vision and Customer Value Proposition will probably end up with poor reception of the product in the market. And possibly kill a very good idea because of the lack of further funding.
- “Pretty and fancy” over functional: Remember, you are not building a complete, battle-proven, best-technology-possible solution to be released in a year. With MVP, you are going to test your business vision with real-life feedback. So every “add-on” that extends the development part also delays the feedback gathering. Maybe you are now spending resources on making the product fancy, which is a total mismatch.
How not to fail?
Well, before you even have a prioritization headache - you first need to define and detail the customer needs in relation to the business value proposition. In platformOS, we are using market-known techniques like Value Proposition Canvas, Impact Gaps Canvas, and Pitch Canvas to clarify the customer needs - and then, based on priorities reflecting Business Vision and Customer Value Proposition, we plan the details only for selected items. We don’t create a full backlog for the complete product - instead, we go low-level only with priorities, keeping the high-level view of the target product in mind, both in business processes and technology design.
Continue reading the next articles in the MVP series