Minimum Viable Product in Software Development: The Lean Way
Every new business is born out of chaos. Three quarters of enterprises do not go past the initial stage, which is also the most decisive one. Whether you survive or go under depends on how well you steer through the troubled waters of startup. And that’s exactly where a minimum viable product (MVP) may be your beacon.
Why do you need a minimum viable product?
A minimum viable product, despite its name, is not really a product that sells, but a certain something that bridges the gap between the initial idea of a product and its final implementation.
With an MVP, you build and learn simultaneously. In fact, what you get is this:
- Early learning. You need to check the viability of your initial concept and find out your customer’s actual needs. Primarily, it 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. A full-fledged product version will take tons of resources and still not guarantee success. One of the components of the lean startup methodology is a ‘build-measure-learn feedback loop’, which allows to remove waste (extra effort, time, and money).
- 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.
How do you get your MVP right?
How do you make this quantum leap between an idea and a product? What do you do at each step of the build-measure-learn cycle? We’ve tried to collect the nuggets of wisdom and give a brief, though comprehensive guide to the practicalities.
The initial idea has to be verbalised, detailed and agreed on among the stakeholders. Luckily, you needn’t have a 5-year plan anymore: no matter how detailed, it’s just a hypothesis. So you might write it on a napkin, just as well. Though a business model canvas idea seems more compelling. All you do is highlight the 9 aspects:
- 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?)
- Customer relationships (How are you going to get, keep, and grow your customers?)
- Revenue streams (How are you going to get money?)
- Partners (Who are your key partners and suppliers?)
- Activities (What do you do?)
- Resources (What kind of resources are needed?)
- Cost structure (What are your payments?)
The colors in the picture represent three areas of risk. We’ll discuss them later in the article.
And that’s that. Now go build, measure, and learn.
This is where the ‘build-measure-learn-iterate’ cycle begins and where it returns to after each iteration. In fact, developing includes two interrelated cycles — Customer and Product development. The former involves making assumptions about the product’s value, the market, the customer and their needs, while the latter is about building a solution to validate these assumptions. Both these cycles represent the evolution of an MVP from the original hypothesis of value proposition to a complete Product-Market fit.
Let’s take a closer look at these two processes.
Product development starts with critical consideration of the project management triangle: cost — time — scope. It’s important to understand which one of these is your top priority — time-to-market, budget, or a unique set of features. This can be hard to determine right off while we’re still learning.
Fortunately, the iterative character of Agile Software Product Development provides the solution for building a minimum viable product:
- 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 to prioritize 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.
Above all, combined with lean development, Agile minimises development effort. For example, consider these lean practices when 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 test your hypothesis. So make sure you send a clear message of 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 monetisation, 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. For instance, the current mobile app development trend favors Android. And this doesn’t seem to change over 2017.
- Use an open source CMS like WordPress. 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. Where do you find them? How do you know you have found the right people? How do you incentivise them to stay? How do you get them to do what you want? This is your unique method of customer development that you’ll have to figure out by trial and error.
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 customers your competitive edge, or building their awareness of the world’s ailments and your mission to cure it.
Besides, every time you iterate, you will test different hypotheses with your minimum viable product — hence a different format or, perhaps, a new channel.
Your customer development strategy comprises these four stages with their own aims, 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. Get outside and speak to your potential consumers in person, learn about their needs, get them to try out a clickable prototype and elicit their feedback. There are plenty of ways to test your hypothesis of early adopters and your value proposition.
- Keep your customers. Now you want to discover their real needs and check if your proposition is sticky enough. How many people will get interested in what you’re making? How many will come back to your site? 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. If you want people to remember you and return to your site, create a memorable logo, a name and URL that bear significance and make you stand out from the crowd.
- Grow your customers. You want to validate your MVP and go viral? Become compelling. Engage, educate, entertain, inspire! Blogging is great for that. Extend your influence through likes, shares, and get the expected behavior via calls-to-action. Your early adopters will also be your evangelists who will spread word of your product in case of success: word-of-mouth endorsement (any statement shared online about the product, service or company) is a powerful marketing tool. Check how much time your audience is willing to commit to your demo. But do it no sooner than you expect your product to generate positive feedback!
- 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. Crowdfunding platforms like KickStarters, Indiegogo, GoFundMe can be of service here. Getting sufficient funding is a proof of concept (this basic minimum set of features has proved viable) and it also means you can take your startup to the next level.
Data analysis requires a great deal of insight.
How do you know what to measure?
Intuitively, you understand it’s either win or lose, but the ability to pinpoint the most risky areas makes your vigilance more focused. Ash Maurya, WSJ’s bestselling author and creator of the ‘Lean Canvas’, identifies three areas of risks:
- product risk — getting it right;
- customer risk — finding the right path;
- market risk — building viable business.
Obviously, the likelihood of various risks is not the same in every particular situation. Besides, it may change over time, you may learn about new potential risks as you proceed. So engage in a regular activity of de-risking your business model by finding the thinnest patches in your canvas and measuring them.
How do you measure?
In order to see how well you’re doing, you need quantitative estimation of your effort. There are a great number of tracking tools to match any kind of marketing campaign. However there’s always a fear of misinterpreting the data and mistaking insignificant indicators for important ones. According to the authors of ‘Lean Analytics’, when choosing a metric, consider three questions:
- What business are you in?
- What stage are you at?
- Who is your audience?
Keeping these in mind, you will know how to focus on One Metric That Matters. The picture below gives you an idea of a proper metric to use at each stage of your business development.
What makes a good metric?
Good metrics follow these basic 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.
The metrics should give you a clue as to what to do next — whether you change the direction completely, tweak some part of your process, or quit, depends on how your measured progress matches your projected ‘success’ indicators. Quantitative measurements may be subjective and situation-bound at times, and thus 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. Thus failure stories are even more important to learn from than success epics as the former probably have more regularities. As soon as you’ve learned those common patterns, you’ll be more realistic and critical of your own current state. Having ‘pre-mortem sessions’ like the one described by Gary Klein in this podcast may help you make well-thought out decisions.
This post begins a series of articles about ‘business-technology’ alignment. Have you found it useful? What’s your experience of building a minimum viable product? Share your story with us.
This post was originally published on CodeTiburon Blog