For as long as there have been products and people — or teams — making them, companies have struggled with issues like productivity, efficiency, performance and competition. Today, every startup company in existence needs to deal with finding the right problem to solve and the right market to sell it. And they need to do it fast and well. Up to nearly a decade ago, they would do it with heavy product management, following a top-down — or waterfall — approach. Things changed with the introduction of Lean Startup. These types of goals are much better served using an MVP approach.
An MVP (Minimum Viable Product), contrary to a fully specified product followed by a waterfall type of product management, can liberate founders from having to develop the entire thing before learning if customers need it, find it easy or are willing to pay for it. Notwithstanding that, an MVP is not easy to produce. Understanding what it is and what purpose it needs to serve will help avoid common pitfalls or misunderstandings regarding the direction to take in developing it.
What is an MVP and why do you need it?
History has it that tech CEO Frank Robinson coined the term in 2001, advocating that customer research and product development should happen in tandem, for a product to succeed.
Eric Ries described the term in 2011, in his book “The Lean Startup”. An MVP, short for Minimum Viable Product, is a free-standing product. One that can stand with the minimum number of features, solving the one, most important problem for the customers it’s supposed to serve. But it does need to solve it well, without causing other problems in the process.
Definition
According to Eric Ries, an MVP is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
In other words, it’s not supposed to start making money. It’s actually there to help understand how to develop a process — or SOP — to make money.
Why a Minimum Viable Product?
Typically, startup companies tend to look for funding, to help cover the expenses of developing their product. But first, they need to test their idea and assumptions over what it is their target audience needs and what resonates with them. And the fastest way is to develop a minimal product with the least amount of effort and minimal budget.
Of course — and this is not a side effect, but by design — this gives a startup company the opportunity to release a product (a version of it) to the market, really quickly. Perhaps, even allowing them the benefit of being the first to reach a specific market or market type. However, this type of benefit is, oftentimes, overpriced. Crudely put, it largely depends on the type of product and business model.
The main goal of a Minimum Viable product is to collect knowledge and validate assumptions in the business model. Knowledge is the currency the entire company will be using until they can learn all they need towards a viable business model. That’s what it’s all about, after all; a healthy, viable business.
The alternative to that is to develop a minimum product that people will just love. And as Sam Altman from Y Combinator indicates:
It’s better to build something that a small number of users love than a large number of users like.
The Lean Startup methodology
The Lean Startup methodology is a derivative of the Lean manufacturing process, developed for the Toyota Production System, pioneered by Taiichi Ohno, om 1951.
In 2005, Steve Blank supported the notion that this style of product management can be translated to software development, to be used by tech companies. And, he described all about it in his book, “The four steps to the Epiphany”. In 2011, Eric Ries set things in motion with his book, “The Lean Startup”, motivating a number of startups to begin experimenting with the model.
The Lean Startup methodology aims to minimize or eliminate wasted effort, promoting value-producing practices. In other words, the goal is to eradicate the expenditure of resources for any goal other than the creation of value for the end-customer. It’s based on three pillars; a three-aspect model named Build-Measure-Learn. In short, a startup company can build a minimal product, with the minimum effort and budget, measure the results by testing and validating their assumptions and using their conclusions to build something better. The process repeats with iterations of improvement, building a robust business model.
4 key elements in an MVP
The MVP should align with business objectives. And, given its nature, including the limited functionality, a lot needs to be achieved with the least amount of work; and fast. An MVP offers specific solutions to specific user problems. To deal with them, a product owner or manager will develop a series of user stories, epics, components, as per some type of Agile development. These user stories and epics are not representative of their vision of the product — or the business, for that matter. To choose which functionality will help the most in getting the most out of the MVP, one must be strategic and frugal. To that end, there are 4 key elements to help:
1. User research
Understanding one’s market and customers involves extensive research and direct communication with interested parties. Once a pattern emerges in customer behavior, we can draft a customer profile, which will help build a way to communicate the release of our MVP when the time comes.
This is also the point in time when we need to find all we can about our Total Available Market (TAM), our Serviceable Available Market (SAM) and Serviceable Obtainable Market (SOM). A market cap estimate is always useful in validating the viability of our business model. Learning all we can about our close competitors and the forces they can exercise upon us won’t hurt, either.
2. Competitive analysis
There are many different ways to conduct competitive analysis; or different fronts, rather. A multi-faceted approach will greatly help identify the path less travelled and take it to minimize resistance. Here are a few considerations:
- Identify close competitors
- Identify their positioning (market types, customer segments, longtail approach, niches)
- Create a perceptual map with the attributes you need (e.g. feature-set vs pricing)
- Review the customer experience on their websites if you’re after the same type of audience
- Look at their pricing. It helps if you minimize the chances of new players joining the game, by staying at the low end of price elasticity of supply. The midpoint method for elasticity can help with that
- Identify, verify and test your distribution channels
- Go over customer reviews and social media presence. Additionally, try to find what types of ads they’re running, if possible
3. Adaptability
Early on in the process of defining a product and the business around it, a product development team is small enough to retain a high degree of adaptability. The stakes are still low, the stakeholders are few and the decisions are easier and faster to make. This advantage can be leveraged with Agile development with continuous integration and continuous development (CI/CD). Any new advancement gets released to market, gets used by customers and the incoming feedback leads to important and helpful change. In short, continuous iterations function as enablers for improvement.
Once the team has grown beyond 9-10 people, there needs to be a way to retain adaptability. The formerly vision-based management needs to become mission-based. That’s because the departmentalization required to develop highly-responsive teams cannot go on while everything depends on the founders’ vision. A mission statement can lead multiple teams much more effectively. The command structure may also need some revisiting.
4. Runway
A startup venture involves several different costs. These include — but are not limited to — the costs incurred to implement the various user stories, epics or components for the MVP; starting with the most prominent ones:
- Technical architecture and related subscriptions
- Payroll
- Gear, office furnishing
- Admin, legal and financial advice
- Insurance, liabilities and patents
Depending on the types — and size — of funds available, they may or may not be sufficient to fund a startup up to the launch date. This is a critical consideration regarding the viability of the entire endeavor. Handling costs to try and optimally distribute funds and make sure the attempt comes to fruition is of paramount importance towards extending the runway, at least enough for the product to take off.
How your startup can benefit from an MVP
The most prominent benefit of an MVP is understanding whether customers really need or want the product. One can gather customers’ interest without fully developing the product. In essence, the sooner we can find out whether it’s appealing to customers, the less the risk of wasting effort and budget developing something that will fail in the market. That said, an MVP will bring focus to the product’s value proposition and promote efficiency; all without being the end-product.
1. Validation
The MVP should either have the ability to convince users that it solves the problem; or, it should include the actual features to solve it with. Early and quick iterations will field-test what is actually quite more than proof of concept — but not an entirely marketable product, in the real market it’s being developed for.
The Lean Canvas or the Business Model Canvas has 9 distinct components. Most of the time, for a startup at least, these are initially filled with assumptions and leaps of faith. Each of them needs to be thoroughly tested for validity. The MVP can be used to try and validate some or most of these assumptions; making for a more robust Business Model, at the same time.
2. Iterative process
Iterations, at any level, are enablers. They enable the product development team to gather feedback and understand their users insanely better than they would with a waterfall management style. But, they’re not “means to an end” in the strictest sense. Jumping from feature to feature leaving most of them in a flimsy state makes for an incomplete product experience. Customers will be unable to persist. Notwithstanding that, the product needs to actually work well.
3. Customer feedback
Feedback gathered as early as possible can provide the necessary signals towards product-market fit. That way, the product development team can take the right direction towards releasing useful features to address customers’ needs.
The team may run the risk of becoming too focused on taking every single point of feedback as granted, ignoring the actual signals from the market. This results in resolving singular customer problems instead of working towards product-market fit. Customer feedback should be used in batches, extracting market signals; not as single points of actionable data.
4. First to market potential
An MVP may allow the startup to establish solid footing as the first entry to market, ahead of competitors. It can be a good thing, allowing them the lion’s share of the market.
But it can also be harmful; especially if the product is exceptionally innovative or disruptive and potential customers don’t understand its value yet. And, unless the correct solution is delivered to solve the problem, competition will win out as people become more educated on the type of product and its value; and as the market matures, of course.
5. Growth to scale
The market is quite forgiving to a small startup at its early stages. Any mistake can resemble only a little bump in the road. The less customers there are, the less apologies need to be made when something goes wrong. The facts are different when it comes time to grow.
For a growing business, it’s really easy to veer off course and really difficult to put the ship back on course. That’s to be expected, since product and people management increasingly becomes all that much more difficult. Let alone, customers have gone from visionnairies to early enthusiasts to mainstream, changing the field two times over. And there’s a catch; in dealing with mainstream customers, the product must be robust and reliable. And it will no longer be “Minimum”. For it to be “viable”, at this point, it needs to be absolutely marketable; all things considered, including competition. In the off chance that not all aspects of a great customer experience are considered, the chances of sustainable, long-term growth become increasingly thinner.
6. Manageable investment
There is something absolutely counterintuitive about a manageable investment. Less time and money given to learn and adapt to the needs of the market, actually reduces the risk of failure for startups. And, that’s the whole point of starting with an MVP.
While the first thought to come to mind is that a small investment will not be enough to deliver a product that solves customers’ problem well enough — if at all — statistics say otherwise, in a very interesting way.
Less funds bring focus to the entire endeavor. If people are mindful of their spend and try to find ways to make ends meet with what they have, they will organically end up simplifying their demands, set clear goals and accept the fact that they are actually here to learn. In contrast to that, more funds can ultimately be fatal. Having the money to create huge departments for marketing, sales and customer care before you know why one needs them and how they need them to be, is just a way to waste investment money; and will put them in a zombie state, or get them caught in the proverbial spiral of death.
There is an interesting notion, called MVIF. It means Minimum Viable Investment Framework. It should be able to clear things up why less funding is better than more.
Common misunderstandings
Teams may know the term MVP but fail to fully understand its meaning or purpose. The most common interpretation is, perhaps, a product with the least functionality possible. That is to say, teams usually ignore the fact that it should be sufficient to help learn all they need about the viability of their product and the business they’re hoping to build around it. To avoid such a predicament, we should consider the most common misconceptions about an MVP.
It’s not a PoC
A Minimum Viable Product is not a Proof of Concept. In fact, most teams come together to form a startup after they’ve developed their Proof of Concept. That’s to ensure the available tech can help them solve the problem they’re aiming for. But, making it viable takes a lot more than proving the tech can support it. One must understand their market, its segmentation, its attributes and nuances and identify possible obstacles, such as competition, customer education, financial viability, legal red tape, and more, before they can transition from a PoC into an MVP.
It’s not a Beta
A Minimum Viable Product is definitely not a Beta version of the product.
While both concepts revolve around customer feedback, a Beta version is a relatively lightly tested product that gets out to Beta testers, so they can identify bugs, issues with User eXperience and general stability and reliability problems. Understandably, this is mainly a job for people with at least some tech savvy.
The “Viable” in Minimum Viable Product indicates that the product should function reliably and as robustly as possible to serve normal customers. These are people that may or may not be visionnairies enough to understand where the product is headed. Regardless of that, all recipients should be able to receive a version of the product that really works; and solves at least their most prominent problem. That’s so they understand its value and will be willing to buy it.
It’s not an MMP
That goes to say, it should not be one. A Minimum Marketable Product, sometimes comes long after the MVP. Despite that fact, oftentimes, teams over-engineer their product to outright accommodate the needs of mainstream customers. The development time — and budget — is considerably larger than what an MVP needs. This type of financially insensible approach, downright promotes waste; of both money and effort. In fact, by not releasing the product to market early and, consequently, not hearing from their audience, it’s the team’s loss. And it’s loss of direction, of focus and of clarity of purpose; not something to be taken lightly.
An MVP must be Viable
For a product to be viable — any product, really — it needs to be something that people want, need and can use to solve an existing problem. One that they would look for a solution for, on their own; one that costs them much more if it remains unsolved. Additionally, it needs to be easy to use, so they can understand it; get a great experience out of using it. Not to mention, it needs for it to be affordable. Making it good and making it easy is not enough. If the buying power of the target market is less than what the product costs, it will remain on the shelf.
Given all the aforementioned considerations are kept in mind, people will be interested in the product. Incoming feedback from demos, interviews, free — or paid — trials or subscriptions will yield results in receiving strong signals from market segments; signals that will provide the team with valuable information as to the direction the product development should take. It’s the most effective way to develop a product that people really want to use.
What you need before you start working
There are a few prerequisites to getting started on an MVP; provided one is required. Sometimes, an existing trustworthy business may be able to present a new product with a simple pitch deck. In other cases, a product may be so complex that an MVP would be unable to provide sufficient solution to any problem. An animated demonstration or an interactive mockup with dummy data might do the trick before any development is underway. In any case, proper preparation is essential to its success.
1. Ideation
A team is not a team if they cannot march under the same banner. When discussions of Proof of Concept begin, the team brainstorm their ideas, document them and put them down on canvases (e.g. Lean Canvases) to see how they work in the bigger picture of their assumed business model. At this point in time, the team will discuss which assumptions may be the weakest or when every actional idea should be tested; when it would probably be the best timing for it to work. This is when the type of presentation for the MVP is selected, as well.
This step, however long it takes, is one of the most important steps in the process. It provides purpose and clarity to the team, ensuring that there is sufficient alignment towards the same goals. It also helps build healthy relationships among team members.
2. Staffing for development
Developing anything more complex than Proof of Concept can prove exceptionally difficult if not done the right way. And, developing an MVP does require skillfulness and experience. If it is indeed the way to go, the team should grow and welcome a few developers. At least one with knowledge on back-end technologies and one on front-end technologies will be required.
3. Prototyping and architecture
Most tech startups need a product that can be scaled up to demand. That’s actually how they will scale their business up with even more traction, as well. The architecture of information is of paramount importance to the robustness, reliability and scalability of the product. This is to be kept in mind when transitioning from the proof of concept to a prototype, to the MVP. That is to say, product development should gradually include more and more considerations regarding the ability of the product to scale, without giving up quality. This is the stage where it all starts.
4. Building the MVP
The MVP is under way. And we’ve used all our knowledge and experience gained from talking to interested parties and initial users; and from the kind of visionaries we call early adopters of our product — also known as “earlyvangelists”. A lot of experimentation has already been done in validating various aspects of the business model, which are, at this point, based on assumptions:
- Target market and customer segments (and possible early adopters)
- Problems our customer segments have that are worth solving (and possible existing solutions)
- The offering and its unique value proposition (and possible high level concept)
- Leap of faith in suggested solution(s)
- Distribution and communication channels
- Revenue streams — even future prospects
- Cost structure — all aspects of business
- Key metrics for success (initially it’s about knowledge; later it’s about new or retained business)
- “Unfair” competitive advantage (something that’s hard or nearly impossible to be copied)
That kind of experimentation is what has helped take a certain direction in product development, clearing up the path towards helping our first customer segment, which could — or should — be our high-speed segment.
Types of Minimum Viable Products
There are, indeed, several different approaches to an MVP. In other words there is more than one way to describe minimum and viable. As food for thought, we can take a look at the most popular ones.
1. Landing page
Oftentimes, either due to inherent difficulty in developing a product, albeit a minimum one, or due to lack of time to do so, a mere description of what the product is for and what its value is supposed to be, along with a list of its advantages and how it’s supposed to be different from other products in the market, would probably suffice.
All this information can reside on a landing page. One that will be allocated a modest amount of the budget to bring visibility to the product. The value proposition is the most powerful tool under a founder’s belt to help identify emotional responses — on the customers’ side — that work.
A landing page, not only serves to validate at least a couple of the assumptions mentioned above. Be it the customer segment, the problem worth solving or the value proposition and any number of communication channels, the team will be better off, knowing where to go next. That sort of knowledge, is power.
2. Animation or Video
An explanatory video or animated sequence can probably explain the product’s benefits, helping identify emotional responses from users. All one needs is a few versions of the message before the video starts and a call to action after the video has played back. Experimentation over this will bring clarity and provide direction.
A great example of this is “DropBox”, where it was really hard to develop an MVP that actually made sense. An animated sequence was used instead, where Drew Houston explained how the app was going to work. It became viral almost instantly, identifying a great number of potential users to be.
3. Email
Email campaigns, even though one of the oldest methods to disseminate information, are all but obsolete. To date, they still demonstrate conversion rates that greatly outweigh that of alternative methods.
On many occasions, founders may be able to merely dispatch a single email containing an offer. This will give them the opportunity to identify whether there’s a favorable response from recipients, or not. While this method requires using a list of contacts that represents the initial customer segment, it remains easier and faster than nearly any other method.
4. Piecemeal
A piecemeal approach can prove that an MVP can be a really minimal product and still be viable. The concept is to introduce a reduced featureset, a demo of the product. The development team can use off-the-shelf tools to build it. Implementing just a little bit of businesswise innovation, the product can launch to market and start collecting user responses, identifying their intent to buy; with any luck, also getting a signal as to their buying power.
The piecemeal approach demands that some of the steps in the process are done by hand. And that’s perfectly fine, since it may take a while for that momentum to be built, before the team needs the process entirely automated for self-service.
A great example of this method is “Groupon”. While they started out with a partially manually operated sales process, they quickly managed to fully automate their business processes, towards the business they’ve become today.
5. Concierge
A concierge approach is a great way to test an idea with a manually operated process, before going on to make it into a product. Let alone an automated one. The concept here is that every customer gets our best possible service, talking to actual representatives, discussing — and getting — what they need. The process gets reviewed and each iteration serves to prove a point and improve the business model to a point that it can support an automated system.
“Food on the Table” did this, visiting customers at their homes, taking notes of what groceries they needed for the week and then rushing to get the best deals and quality products to buy and then deliver to customers at their door. The concierge approach helped the product development team build an automated system that would help people do their shopping sensibly and efficiently.
6. Illusion or Wizard of Oz
This approach works best when the idea is to sell products other companies make. An e-commerce platform is the ideal example. That is to say, the company stocks absolutely zero quantities of the products they aim to sell. But they do develop a presentation page for each product. Once a product is ordered, the product development team will physically visit the appropriate store, buy the product and then dispatch it to the customer, manually handling all the logistics.
“Zappos”, a now reputable, well-respected and established company, started out their shoes and clothes retail business using this method; learning what people were looking for from their shopping experience, in the process.
Developing your MVP
It’s difficult to strike a balance in what is really an MVP and what is not. There is such a thing as “not enough”, as there is such a thing as “too much” when it comes to producing an MVP that serves its purpose. Finding out the optimal description for it takes time. And there are 4 steps one can take to keep everything on track.
1. Identify problem worth solving and pertinent market
This is all a matter of asking the right questions. For example:
- What is the challenge?
- What is the problem not being solved; or not being solved really efficiently?
Who has the problem? - Do they know they have this problem?
- Have they tried to solve it?
- Do they know how much money or time they’re losing because of it?
- Are there other solutions they’re already using?
- Do they like these solutions? If so, why? If not, again, why?
- How much are they willing to pay for said solution or our solution?
Answering these questions will bring the team some clarity over what the market is, what the people in it need and how they perceive their problems and possible solutions.
2. Perform competitive analysis
Understanding the competition is of utmost importance in understanding what has worked in your targeted market and why. That’s how we can come up with what identifies as a strong element in any system, and what doesn’t. Consequently, this is an excellent opportunity to address the shortcomings of any existing solutions your customer segments may be already using. The point being, you can possibly avoid some or all of the pitfalls faced by older players in this industry.
3. Define the MVP feature-set
Defining the feature-set that will be available in the MVP boils down to understanding the user journey — or user flow. Putting labels on each step the user takes throughout the process will help identify which features would help in each step. And each step could be called — as we usually do in Agile Development — an ”epic”. Even though an epic can potentially encompass multiple teams and multiple projects, it’s not a bad way to start organizing all the work. If nothing else, it’s one way to go about it.
Once that is done, each feature could be represented by a “user story”; a type of task that identifies what the user needs, when and why. This can be broken down into several tasks and sub-tasks to be assigned to different members of the development team. Each user story may need to include more than one feature; this is also OK.
All the epics and user stories will be then ready to be prioritized based on their importance and urgency and, of course, placed on a time schedule based on the logical order they should be built in; it really depends on what will bring the most business value first, what feature needs to already be developed to support future features and what step in the process we can or cannot do without.
4. Develop, test, release and repeat
The body of work has been scoped and sufficiently described. A Lean approach — Agile development, too — suggests that items set for immediate development, should be fully described; whereas items that will be built in the future should be described right before we need them, using the latest and most complete information available to us. This makes sense, since it’s a great way to avoid guesswork and common pitfalls.
The importance of testing
The MVP should be regularly tested as new things are added to its functionality. There is no better way to reduce technical debt and bring robustness to the product. To that end, there are three distinctive steps. Alpha testing, beta testing and feedback testing.
- Alpha testing is done by employees of the organization, who are working on the product.
- Beta testing is done by employees that are not working on the product or, perhaps, even a few really early users we can trust and have a good relationship with. Incubated or accelerated tech startups may also get some help from fellow employees in other tech startups from the incubator or accelerator.
- Feedback testing is done by an external auditor; perhaps a specialized product testing company. At this point, the product does work. It’s relatively safe to say that another way to go about this is to release the product to market, in a controllable way; starting with a few verified early adopters, to help iron out any minor bugs and small details.
Feedback testing is really important; it serves as a reality check of sorts. It’s an excellent way to to verify that:
- The product does, indeed, solve actual problems
- It does it better, faster and more affordably than the competition does
- People are willing to pay for it and recommend it to others (referrals)
Testing is an iterative process. It should be part of any important change in the product. And, every time, this new change in functionality needs to prove itself as one that helps customers get one step closer to their goals.
In a nutshell (summary)
The value of an MVP has been proven repeatedly in developing a robust, reliable and scalable product. In a high-speed market, it’s exceptionally helpful to understand how the market works, what it needs and how it can be described. Older methods of product management, such as the top-down — or waterfall — approach have proven to be inadequate in such cases.
The Lean Startup methodology, in conjunction with Agile Development are probably the most efficient tools to build an MVP the right way, while achieving high responsiveness and minimal waste, leveraging adaptability and high performance; all while still under development.
There are several different types of MVP; that is, depending on the type of product, type of market and the relevant attributes and characteristics that describe any or all pertinent customer segments. But, one of them is bound to work for any type of product.
Notwithstanding that, there’s no secret recipe to a successful MVP. The Lean Startup methodology, the Build-Measure-Learn model and the Agile manifesto are all tools at the product owner’s disposal, to use at their discretion towards mitigating — or even eliminating — the risk of failure involved in their endeavor; all the while maximizing the available runway, giving the team the opportunity — and resources — to be able to take off with their product. Just like they wanted.