Product development starts with critical consideration of the ‘cost – time – scope’ triangle. Which of these is your top priority – time-to-market, budget, or a unique set of features? Oftentimes, you want it all ASAP, ignoring the fact that the product vision and it’s value are mere hypotheses. That’s where a minimum viable product (MVP) may be your lifeline.
In this post, you’ll learn how to build a minimum viable product in software development. Use the plan to skip to a question of your choice:
What is an MVP in software development?
The Minimum Viable Product concept, introduced by Eric Ries, is a discovery tool for a team ‘to collect the maximum amount of validated learning about customers with the least effort.’
The concept of a minimum viable product is not the same as a proof-of-concept (POC) or prototype. Though all of them serve to validate a hypothesis of a product, a proof-of-concept only tests minor technical assumptions, not an entire system, and a prototype tests multiple versions of a product’s design, usability, and functionality – these come before the release of the product.
By contrast, an MVP in software development is a product (or website) that is released with just enough value to retain early adopters, make them pay for it, and get feedback for future development.
Why do you need to build a minimum viable product?
A minimum viable product as part of your product development strategy gives you:
- Early learning. Software MVP tests your value proposition and verifies your idea of early adopters. You may use this knowledge as a base for building other products as well.
- Lean development. Building an MVP may seem like a waste of resources. But it actually spares you from going too deep into software development and building a product that no one needs.
- Early launching. Getting, activating, retaining and growing the right sort of early adopters is crucial to your business success. Unless you go early (I didn’t say ‘go first’, mind you), you may miss a window of opportunity.
So what exactly can you learn via an MVP?
Examples of minimum viable products’ value
Everyone knows a major travel and hospitality disruptor, whose product was born out of necessity. Airbnb founders, Brian Chesky and Joe Gebbia, rented out an extra air mattress in their living room to pay their rent. They went the extra mile and created a site to bring the supply and demand together and make hosting as easy as possible. Little did they know then that the sharing economy model was the next big thing for the future of traveling and beyond.
Before the iconic swipe became Tinder’s action branding, users hit a heart for ‘yes’ and a cross for ‘no’. But Tinder MVP hit the sweet spot with customer development. One of the co-founders, Whitney Wolfe, run the guerrilla marketing campaign among college kids. And Tinder-mania caught fire.
Instagram’s first MVP wasn’t actually a success. But its owners learned and pivoted fast. The problem was the product wasn’t unique. There were plenty of photo-sharing apps as well as photo-editing ones, but not the two together. That knowledge gave Instagram its USP.
So how do you build an MVP?
The minimum viable product strategy
In his ‘Lean Startup’, Eric Ries offers a ‘build-measure-learn-rinse-repeat’ cycle of building an MVP. In software development, lean MVP development fits best with agile methodology.
A key to efficiency in Agile Software Development is in its agility and flexibility:
- It delivers piecemeal, so you get a potentially workable product, ready for feedback every 2 weeks.
- It embraces the changes deriving from learning and is capable of tweaking the code promptly.
- It allows prioritizing a minimum set of important features making the product viable.
- It’s collaborative enough to consider the needs of everyone – the business, the developers, and the early adopters.
In agile software development, you create an MVP in short 2-week design-and-development iterations of:
MVP software design
Iteration Zero puts everyone on the common ground about the product vision, the hypothesis and key performance indicators (KPIs) of success. That kick-starts the quest for the best model. From there, every new iteration delivers a milestone that tests the product’s viability.
Ideate your product
Start by making a minimum viable product business plan. The initial idea has to be verbalized, detailed, and written down. A business model canvas helps break your concept down into the 9 aspects:
- Unique value proposition (What is it you’re building?)
- Customer segments (Who are you building it for?)
- Channels (How are you going to get your product to your customers?)
- Unfair advantage (What makes you better than competition?)
- Revenue streams (How are you going to get money?)
- Problem (How do you understand your customers’ needs?)
- Solution (What is a minimum viable solution?)
- Key metrics (How do you measure your progress?)
- Cost structure (What are your payments?)
Brainstorm the features
You know your value proposition. The next step is to transform it into a feature set, which is done in many ways. Use divergent thinking to brainstorm a pool of features that you can evaluate and pick from later. Sketch a roadmap for your initial hypothesis so you can put things into perspective.
Prioritize the features
Now it’s time to define the product scope. Your MVP software won’t deliver entire value. But you can design it with the best guess of the features your users would want. Use prioritization techniques to pick the precious little from your pool of features.
POC or prototype
The MVP software design may skip this stage altogether. But if you want to verify a single aspect of your system, build a proof-of-concept. Prototyping is great to test the system for errors, A/B test the design, or attract investment. Interactive prototypes have a look-and-feel of a real product.
MVP software development
In MVP agile development, product is built alongside customer development. The assumptions about the product’s value, the market, the customers and their needs determine the product’s features and get tested on the market ASAP. The feedback determines the scope of change for a better product-market fit. It’s circular.
Let’s take a closer look at these two processes.
Since agile minimises the development effort, these lean practices are commonplace while building an MVP:
- Use cloud services. It saves your time and money, and it’s much easier to scale out. When you’ve grown big enough, you can buy your own hardware for bare traffic and use the cloud for excess one.
- Stick to simplicity. Too many features are a waste of resources and may confuse your users. Remember, all you need is to test your hypothesis. So make sure you send a clear message of the value proposition. Staying simple (at least in their UI) ever since the start has proved a winning streak for Google, Dropbox, Craigslist and many others.
- Utilize SaaS. Such services as monetization, customer support, data collection, and analysis take long to implement. So why not use a 3rd party service and focus on the core feature development instead?
- Choose a limited number of browsers or platforms for your mobile app to run on. This requires some market analysis to pick the right ones.
- Build a PWA. With progressive web apps, and yet get a native app look and feel by building once and using in every browser, on any device. Developing a ‘lite‘ MVP allows you to maximize the reachout.
- Use an open-source platform. It considerably reduces your time and effort of building a site or a landing page. Moreover, it provides you with in-built analytics tools and much more.
Your product may be unique and priceless, but it won’t sell unless you figure out how to get, keep, and grow your customers. The strategy will vary whether you plan to enter an existing market or discover a new one. It means your major effort will either be channelled towards showing your competitive edge, or building customer awareness of the world’s ailments and your mission to cure it.
Besides, every time you iterate, you will test different hypotheses with your MVP – hence a different format or perhaps a new channel. Customer development strategy has four stages, each with its own goals, channels, and metrics.
- Get your customers. You want to generate attention and attract early adopters? Tell them about your unique value proposition via explainer video on Youtube, or send them cold emails via ActiveCampaign, engage them in a questionnaire on Facebook or conduct a survey on Quora or Reddit.
- Keep your customers. Now you want to discover their real needs and make sure if your proposition is sticky enough. Build a landing page to find out, start a group on Facebook, build your web presence on LinkedIn. This stage is about branding, so great UX is indispensable.
- Grow your customers. You want to validate your MVP and go viral? Become compelling. Engage, educate, entertain, inspire with a blog. Extend your influence through likes, shares, and get the expected behavior via calls-to-action. Your early adopters will also be your evangelists for word-of-mouth endorsement.
- Have them pay. What’s your product’s optimal feature set that will make people pay? That’s the tough question we love to hate. But we need to be tough! A fundraiser campaign is your answer.
Measure your MVP
Data analysis requires a great deal of insight.
How to know what to measure
The ability to pinpoint the riskiest areas makes your vigilance more focused. Here are the 3 areas of risks:
- product risk – getting it right;
- customer risk – finding the right path;
- market risk – building viable business.
You know where your most risky areas can be. So go de-risking your business model often and measure the results.
How to measure
When choosing a metric, consider three questions:
- What business are you in?
- What stage are you at?
- Who is your audience?
One Metric That Matters is enough to give you a clue.
What makes a good metric?
Good metrics follow these rules:
- A ratio is better than an absolute value.
- Dynamic data over static. The possibility of comparison across the timeline is preferable to percentage.
- A proper combination of quantitative, qualitative, comparative, and competitive measurements.
- Simplicity and clarity of interpretation.
- For experiments, convincing enough to make you change your behavior.
- For reporting, easily convertible into predictions and trends.
The last observation raises a question of ‘audience’. Who are you going to report your findings to? This could be internal business groups, developers, marketers, investors, or media. What interests them will vary considerably and the data may get different interpretations.
Learn, rinse, and repeat
So what’s next? The ‘success’ indicators will show whether you pivot, tweak some part of your process, or quit. Quantitative measurements may be subjective and situation-bound at times, and as such needn’t be taken in isolation from other indicators.
However, some benchmarks applied at a later stage indicate a real state of affairs. For instance, Sean Ellis’s 40% rule helps measure success of a minimum viable product and the enterprise’s readiness to scale by simply getting users to answer one question that matters: How would you feel if you could no longer use [product]?
- Very disappointed
- Somewhat disappointed
- Not disappointed (it isn’t really that useful)
- N/A – I no longer use [product]
The benchmark of success is 40% rate of ‘very disappointed’ users.
One final thought
Whatever the outcome, it translates into experience. That’s the reason why failed entrepreneurs are deemed experienced. Failure stories are even more important to learn from than success epics as they have more in common. Knowing those common patterns will make you more realistic and critical of your current state.
What’s your experience of building an MVP? Tell us in the comments or in person.
How much does it cost to build an MVP with CodeTiburon?