Building the minimum viable product (MVP) is a core aspect of every startup’s journey, but most founders struggle knowing how to define what constitutes “minimum” functionality for their MVP. Entrepreneurs tend to over build their MVP, resulting in painful delays launching the product, which sometimes results in fatal downstream business problems. Founders can maximize their chances of MVP success by following a disciplined, structured process to plan and restrict the scope of their MVP build out, which accelerates the product development.

Avoid the Domino Effect

I previously provided a framework to help startups build out their minimum viable product (MVP), from earliest showable product to earliest lovable product and beyond. One key factor that entrepreneurs must do well is the ability to manage the scope of their MVP. 

This may seem like a trivial, low-level implementation tactic, but it’s actually quite important. Failure to do so often results in bloated requirements that increase your development costs and time. Early-stage delays in developing your MVP have downstream ripple impacts, as market traction will also be delayed. Any delays in traction impact the strength of your story during fundraising. Weaker stories result in either investor disinterest or funding on sub-optimal terms. For most early-stage companies, the investors hold the vast majority of the leverage. Entrepreneurs need every advantage they can get to tip the scales back into a more balanced negotiation. Demonstrating solid traction mitigates a key investor concern.

Typical Feature Management

Most product teams manage features using some form of a brainstorm, prioritize, and build process as depicted below.

Most product teams encounter problems because they use a simple one-dimensional rating scale to prioritize features. I often see teams use three or four point rating scales are depicted below.

These flat, one-dimensional rating scales tend to create problematic results where the majority of the features receive the highest priorities. This leads to an unbalanced distribution that looks something like the bar chart below.

Given this sub-optimal distribution, it becomes difficult to determine exactly which features need to be included in the earliest releases of the product development. Too many features appear important, resulting in a bloated MVP target. Attempts to thin down the MVP requirements often results in disagreements and disputes where sensible decisions take a back seat to the person who has the biggest job title, is paid the highest salary, holds the most equity, shouts the loudest or is simply the most stubborn.

If Everything Is Important, Then Really Nothing Is

Instead of a one-dimensional rating system, product teams are better served with a two-dimensional feature prioritization system based on business benefit and technical complexity. Product managers should determine independent scores for each feature’s business benefit and technical complexity. In order to provide sufficient granularity, I strongly suggest using a five-point grading scale for both scores.

Assessing business benefit is a difficult process because the business value is often subjective. To inject objectivity into the process, product managers should determine the criteria used to justify a certain core. Possible criteria may include: value, cost reduction, comparison against the competition, regulatory requirement, safety, scalability, interoperability, availability, etc. Product managers should determine the thresholds for each criteria that justifies a certain business benefit score. The table below provides an example of how to objectively determine business benefit scores:

Even with a five-point business benefit grading scale, there will always be a tendency to rate the business value too high. Product managers must be diligent in thinning out overweighted business benefits and push to determine the true business benefit of each requirement. A dozen different questions can be incorporated into a ruthless process of assessing the business value:

• Does the customer have this feature today?
• What does the customer do if the feature is not built or not ready?
• How much pain does the customer feel if the feature is not included?
• Is there a workaround if the feature is not included?
• …

The technical complexity score should also use a five-point scale based on an estimate of how much engineering work is required to implement the feature. Features can vary widely in the effort required to implement. In my experience, anything less than a five-point grading scale fails to provide the granularity required to properly represent the broad spectrum of engineering investment required. One example of a technical complexity grading scale follows below.

Once the business benefit and technical complexity scores are determined, each feature’s prioritization is determined by mapping the respective scores to the 5×5 matrix below.

The 5×5 matrix results in a nine-point prioritization scale. As one would expect, a feature with the highest business benefit and lowest technical complexity receives the highest priority. Conversely, features with the lowest business benefit and highest technical complexity receives the lowest priority. 

A thoughtful, disciplined application of this process usually results in a much more balanced distribution of prioritized features, such as the example below.

A more balanced distribution of feature priorities makes it easier to pare down features into those that are truly required to build your MVPs. By applying the concepts in Getting to MVP, product managers can more easily determine features that make up the earliest showable, earliest testable, earliest usable, etc. versions of the product. 

Putting It All Together

Startups that excel at efficiently building their MVP mitigate a significant risk factor for themselves and their investors. Building a solid plan for the MVP must be done early in the startup’s journey as the money and time required feeds into the detailed financial model. The financial model subsequently feeds into the startup’s funding strategy that dictates when, why, how much and from where to raise money.

Guesswork MVP plans result in unreliable financial plans, which often result in either distressed fundraising, funding with suboptimal valuation and/or terms, or startup failure because you’ve missed deadlines and overspent cash resources. Avoid these problems by engaging expert advisors to guide you in your journey. Execution Matters offers several packaged advisory services that apply a wealth of expertise, best practices and tools to guide founders through these uncharted waters. We can also offer custom-tailored startup advisory services. Let us know how we can help.