How to Scope a Minimum Viable Product (MVP)

Often when requesting a development contract, clients want results fast, cheap, and ideally "perfect." Although optimizing around these metrics may be our target goal, clients usually end up creating a never ending list of must-haves that lead to a slow, inefficient, and expensive project.

In this post, I'll share a process for planning, scoping, and prioritizing your MVP that will better enable you to engage in a developer contract that will get you what you want cheaper, faster, and with less miscommunications/headaches.

Start with business goals

When starting to scope a project, don't focus on brainstorming features. If features are viewed as the end-goal, of course you'll end up with a list of every possible feature your product could have. But does your product need to have every possible feature right now?

Instead of focusing on features, establish what business impact you expect to result from investing time and money into a development project.

Some common business impact goals:

• Get VC/Angel funding
• Validate product-market fit
• Land your first 10-100 customers
• Act on user feedback to increase customer retention
• Scale your product to support millions of customers

Depending on the goals you have for your business, you might have way more/fewer restrictions. For example, if you need to validate product-market fit, you only need to demo the main features people will pay for (ignore logins, dashboards, account management, password resets).

If you need to get your first few customers, don't invest time and money into expensive infrastructure to supports millions of users. Your first thousand users won't know the difference and if you can't acquire a million users, that investment in scale was wasted.

If you're seeking investment, does your demo or initial project need to be perfect? You could build a simple platform today, acquire more funds, then build a more sophisticated system later. Of course pre-planning rebuilds sounds like wasted cost, but more often than not, project planners are more disappointed that they spent too much prematurely over-optimizing than having to rebuild/refactor an old project.

Work backwards from business goals to feature scope

Once you've determined what business impact you want to achieve with your project, now you can go about choosing what is absolutely necessary to achieve that goal.

Don't worry too much about creating an ideal MVP scope from scratch. Just start with a first draft, however messy it may be, then iterate and refine it. Scoping shouldn't be viewed as a hole-in-one — there's no rush for perfection. Just follow a process and until you feel confident and you'll save much more time later in developer time.

Creating your MVP scope draft

To start your first draft, imagine the story of a user trying to achieve the goal your platform provides. Draft out the flow/paths of each of these steps with a very acute level of granularity.

Iteratively reduce your scope

Walk through each use-case and, for each action/step, ask yourself the following questions:

• Is this step absolutely necessary to proceed to the next step?
• Why is this step necessary?
• Can I achieve the goal of this step in a simpler, intuitive, or more automated way?
• What would be the impact of the cumulative user experience if this step were removed?
• Can this step be split into smaller, more granular steps?
• What would the user expect to see during this step?

Whenever you spot a step that can be split, simplified, or removed, go through each use-case again and see how this changes the story and if that change introduces more flexibility for further changes.

Simple, Minimal, Durable

Less is more. People do not evaluate software quality by the sum of each part. They evaluate by the average, meaning, it's better to have a few things that work very well, than a lot that work in a mediocre way.

For every additional feature in scope, there is more complexity, inter-connectedness, and opportunity for bugs. By limiting scope, not only do you save development costs, but your core platform will be more robust and intuitive.

Every design has a limited amount of pixels/real-estate to convey to your user what they can do. Every feature takes up some portion of a user's focus. By removing a nice-to-have or stretch feature, your users can better focus on what really matters.

An MVP often doesn't have to be beautiful, but it has to be intuitive. If a user doesn't understand how to use your product, it serves them zero value. If a user is only willing to use your product if it's beautiful, that means they don't value the core functionality enough.

An MVP doesn't need to be fancy or flashy, it just needs to easily communicate the value you are trying to provide and either function intuitively or be easy to learn.

A user is rarely won over by a very flashy or impressive sub-facet of a platform. However, users are very often lost by a critical error, bug, or frustration. By removing the number of features on your platform, you reduce the risk of frustration and losing users because there are fewer places for something to go wrong.

Be explicit at prioritizing tradeoffs

When planning the best-case, worst-case and every scenario in-between that your project can take, it is useful to know what you value. Whether it is speed, cost, design, functionality, and/or durability, there will be trade-offs and it's important to rank what you know is most critical to the success of your project.

If there is some stretch feature that could improve the odds of achieving the business impact goals you set for your project, write down the pros/cons and evaluate which is more important to you. If you needed to collect user-feedback yesterday to validate your idea, the fluff can wait.

If you can't afford to disappoint your first few clients, maybe it's worth investing more into robust testing. With any decisions, there will be trade-offs, and if you prioritize the metrics for each decision, you'll minimize disappointment.

Translating scope into technology

In general, there are different constraints and trade-offs to adopting one technology over another. When talking with potential developers, ask them what critical dependencies they expect to use and why. Discuss what are the limitations of those technology choices compared to alternatives. Get many opinions, obtain a high-level understanding of how these components could connect together, and decide what is the simplest functional solution to achieve your goals.

Execute, Evaluate, Learn

No one is a perfect product manager on their first day. As you work with your consulting team and acquire more feedback around progress to your goals, write down what surprised you and didn't match expectations. Revisit your scoping document and check what were the things you built that you didn't need and what critical scope you might have missed. By further inspecting what you over and underestimated, you can learn more about how to better plan your next project.