The road to success — On the minimum viable concept
“Miss by an inch, miss by a mile.“ — Chinese proverb
Whenever you’re trying to create a product from scratch or thinking about a major new feature, you will inevitably bump into the term MVP (minimum viable product). The concept of MVP is there to help you build something that the users really want in the shortest, cheapest, and leanest way. This week, I went to a meetup where I heard some talks that planted the seed: to reach success, maybe it’s not only the product (or feature) we want to ship there that should be scrutinized along the “minimum viable” concept. Let me share with you the saplings that grew out of those seeds.
Product
Recap: A minimum Viable Product (MVP) is the simplest version of the product that includes only the essential features required to deliver value to early adopters and validate core assumptions about the product’s viability. In my view, the same concept can also be applied to major features.
Core functionality only
A good MVP contains only the core features, no decorations or knick-knacks.Rapid development and launch
A good MVP allows teams to quickly develop and release the product without overdoing the initial investment and risk.Validation
A quick MVP can help you gather honest user feedback to validate whether the product is worth further investment.Rinse and repeat
Based on the insights gathered from each release, the product can be improved step by step with additional features, design improvements, and optimizations.
Business
Many startups bleed out due to wrong or missing product-market fit. Similarly to what the MVP means to the product, you should also validate your product-market fit and broader business model.
Core offering and product-market fit
What is the core problem we’re trying to solve with our product? Is there a real need in the market for this, or are we just trying to find the problem for our solution idea?Revenue and business model
Is our product for the B2C, the B2B, or the B2B2C market? Who will be our customers? What’s our revenue model? Direct sales, pay-per-use, or subscription? Are there enough customers who are willing to pay for our product?Customer acquisition and retention
How will you attract new customers? What channels and what kind of communication might work? How much effort will it take to attack and onboard enough customers to become sustainable? How will you leverage your existing customer base to provide input for your product roadmap? Will initial customer satisfaction and loyalty lead to repeat purchases or longer-term engagement?Operational and financial feasibility
Collect what you will need for product delivery, customer support, and other critical operations. Can the current model expand with additional demand? Uncover the essential costs required to run the business. Will your revenue cover all your costs, including product development, marketing, and operations?
Technology
Our goal is to establish a minimal yet functional technological foundation that can support the initial phases of a product without over-investing in complex, resource-heavy solutions. What design and data structure will support the needs of my MVP, and what is not needed? The idea here is to outline the path from the initial concept to the shippable product, removing the ambiguity.
Design
Don’t be shy with design discussions. Don’t just code something and let it evolve into a nice bowl of spaghetti. Don’t fall into the trap of “Weeks of coding can save you hours of planning”! Even if you’re following an iterative approach, planning for the planned features and use cases is essential.Infrastructure
Verify your infrastructure from multiple angles: how much does it cost now, and will it cost if your product scales? Can you leverage free credits or services?Data structure
Software engineers tend to say that code is concrete. Once you’ve developed something, it’s tough to change it or to let it go. We tend to forget it, but the same is true (or even more accurate) for data structures. If you’ve ever migrated a live database with a ton of data, you know what I mean.Automation
In the beginning, you most likely will perform all operations manually. But that’s not sustainable in the long run. Identify possible areas for automation and tooling and the cost of development. And only automate what’s worth the investment.
Build or buy
There is an app for that! The slogan for the iPhone years ago is also valid for software services. Chances are there are multiple free or paid services that you can use as Lego blocks to build your house. They might not be perfect, but they are cheaper than building something from scratch, especially in the beginning.
Analytics
Insight into the product’s performance, user activity, and system reliability is key to a successful improvement. Think about these aspects early on so that you can collect events and slice and dice this data to gather information that can be fed into your product, business, or technology roadmap.
If you would like to dig deeper into the technology aspect, then check out my earlier post to dig deeper into unnecessary complexity:
As you can see, this no-nonsense, down-to-earth, focus-on-the-minimum approach that characterizes the MVP concept is very much applicable to your strategy with business and technology as well. All aspects are essential for a successful product or feature launch.
Food for thought: What’s your approach to avoid unnecessarily complex products? How do you avoid building something as complex as a space rocket in your first release? What’s your secret weapon to verify product-market fit? I would love to hear from your personal experiences.