August 23, 2016

6 Steps to Define Your Minimum Viable Product (MVP)

6 Steps to Define Your Minimum Viable Product (MVP)

Identify Why Your Product Will Be Used

A Minimum Viable Product (MVP) is the leanest, full-featured product that meets the core needs of your users. Your MVP is not a prototype or beta release. It’s a fully-tested, user-acceptance tested, viable product that achieves a business objective. In other words, your MVP answers one simple question: Why? Why are you creating an application in the first place? What needs does it satisfy?

Too often, development teams jump to how to create a solution before grasping a full understanding of what problem they’re even solving. In order to satisfy your customers’ needs, you must understand why they will use your new app. From there, you can determine what comprises the most concise list of features to satisfy the core, driving need of your users. And finally, you can figure out how to get from inception to your MVP better, faster, and cheaper than if you’d started with the how. It’s a new way of thinking about development that works. Here’s our 6 steps to help you get your product from inception to MVP.

Understand Your Users

  • Capture your ultimate goal

When you set out to create a product, you’re really trying to solve a problem, fill a gap, or satisfy a need. By clearly and concisely identifying why your product will be used, you’ll be able to use your statement as a sanity check throughout the project inception process. Later in development, it can be used to vet proposed feature changes.

Capture your ultimate goal in as few words as possible. In the movie industry, there’s the idea of a logline: 25 words or less that capture the essence of a story. The same idea can be employed when getting to the root of why you are creating your application. Keep asking “why?” until you have a firm understanding of the core driver behind your MVP creation.

  • Understand your users

Once you have a goal in mind, it’s important to completely understand your users. Creating complete user personas to identify the habits, drivers, and pain points that will attract that particular type of user to your application. Then, go one step further and identify specific users from those personas who are willing to help with user acceptance testing.

There’s an old saying in software that users don’t know what they want until they see it. By identifying users who are willing and able to act as a sounding board during conceptualization, and who can provide early feedback during development, your MVP stands a much higher chance of meeting its strategic goal upon first release.

  • Map out your ideas

At this stage, imagine that everything is possible and believe that no dreams are crazy. Write down every feature that your app could possibly offer your users. Dream big and don’t hold back! It’s best to create feature maps in a group setting to maximize creativity.

Once you have a big list of grand ideas, use your ultimate goal and your defined user personas to rank each possible feature. Determine those that are must-have features, and test them with real users. Ask your users, through surveys, emails, or focus groups, which features are critical, which are nice to have, and what features they’d like to see that you didn’t even think of.

WHAT?

  • Determine your timeline and budget

It might seem counter-intuitive to plan your timeline and budget before determining your exact feature list. However, this critical step provides firm metrics around how many features can be included in your MVP. In order to produce a minimum viable product on time and in budget, it’s necessary to exactly understand your time and budget constraints.

When determining your timeline and budget, don’t reach for your feature list. Set a realistic timeline based on your resource capacity. Set your budget based on real dollars. Plan for a bit of buffer space so that you operate on a realistic schedule and have extra dollars for unforeseen expenses.

  • Create your stories and backlog

Now that you understand your goal, how it meets the needs of your users, and how much time and money you have to devote to your MVP, it’s time to separate your feature list into user stories and backlog. During this phase, it’s helpful to create wireframes, define process flows, and trim, trim, trim at your feature list until it contains all the necessary components – and none of the fluff. The list of user stories you decide on should be constrained by both your available time and your budget.

The process of defining what actually goes into an MVP is a give-and-take exercise. It might seem painful to exclude features that are high on your wish list, but potentially low on priority. Remember these two key phrases: “This is just the beginning.”  – and – “Users don’t know what they need until they see it.” After your MVP is out in the world and in use, the features that will make up your phase 2, 3, 4, etc. will become abundantly clear based on real-world use and feedback.

HOW?

  • Sprint for success

Only start your first sprint once you understand why you’re creating your app and what you need to create. At that point, you have a solid definition of your minimum viable product. Once you set out to develop your app, start with your hardest tasks. Knock those out and get the results into the hands of your acceptance test users as early as possible. In the beginning, don’t worry about “pretty.” Just make each iteration a functional, finished, and testable set of deliverables. Create a constant feedback loop in order to incorporate acceptance test feedback from the earliest iterations of development.

Keep your development sprints short and concise. Short sprints that produce working code remind your team that they’re constantly succeeding. Pause at the end of each sprint long enough to celebrate those successes, and then build some more.

Throughout your project on-boarding process and through each development sprint, keep your why statement in mind. It is the nature of software development for scope to change. The act of creation breeds creativity, and new ideas are sure to surface mid-development. Keep track of them. Add them to your backlog. Only add them to a development sprint if something of less value can be taken out. By running dedicating your team to the ultimate why statement of your application, and by continually seeking and responding to real-user feedback throughout development, your MVP is sure to hit its target right out of the gate.

Do you need help defining your MVP? Give us a call. We’d love to talk to you!

Atul Shukla

Written by Atul Shukla

Share post