I have briefly touched on MVPs before when discussing the Agile Transformation and their importance to the overall success of an Agile undertakings.  When building a new product, an MVP is the team’s True North. It guides prioritization, backlog grooming, and what will be accepted as known defects at go live. 

Getting it right is paramount to adoption and success. Yet many organizations struggle with pinning down a realistic set of criteria for a true minimum, especially when making the switch from waterfall. 

Consider dexterity games like Go Cuckoo, you want to have a nest that will hold eggs with the fewest amount of sticks placed in order to win.  The sturdiest foundation will keep you from dropping eggs, but you’re less likely to be able to place all of your eggs before other players.  It’s a balance of finding just good enough to progress.

So how do you get there?

1) What is the problem you’re trying to solve?

Product 101 tells us we don’t just create things and find the target audience. We listen to the market and solve problems in a way people will pay for.  The key is framing it from the customer perspective. What is the main thing you are trying to solve for them?

An example may be Amazon’s original line of business in selling books:

Allow users to receive selected books. 

2) What does the user journey look like?

While journey mapping can get extremely detailed, including the search process to find you and exception handling, focus on the simplified happy path.  What are the steps needed to get your users to the stated objective?

Using the Amazon example:

Find Books     >     Buy Books     >     Track order     >     Receive Books

3) List Features

At this point, you can now start brainstorming all of the features that would make up these steps.  List it all.  What doesn’t end up in the MVP will be added to your backlog for future prioritization. 

I like to do this with the team and multiple pads of sticky notes. Let everyone write their own without input from others and then add them to a wall groups by the steps.  During group review, you’ll likely think of more to add.

Continuing the example, these might be some of the features you would list.

Find Books

Buy Books

Track Order

Receive Books

4) Prioritize Features

Up to now, you may have some variation in approach but we all largely do the same steps to get a backlog created.  This is the critical piece for determining your MVP and where a lot of organizations falter.

A lot of product owners start ranking items in one large list. Whether you are using a scoring matrix, your own preference, or ranking according to sponsor dictation for an overall roadmap, you should start by prioritizing features within each step.

There are things that are important, and then there are things that are functionally critical in order to facilitate the step at all.  These features make up the absolute basic frame that you will build everything else on.  Once you identify what those items are, you have now defined your MVP!

You may at this point determine that you do need to add additional features as industry standards or what will be your product differentiator to be included as well, but you have stripped it down to the fundamentals. This allows you to minimize waste, developing more leanly, and will make you much more able to shift quickly as you receive user feedback.

Your MVP

Your Backlog

5) Get to work!

Now that you have defined the base path, start breaking down your features into user stories and plan your release!  While planning your sprints, keep in mind the tenants of vertical slice architecture. You want to be able to have a shippable piece of functionality at the end of each sprint, even if you are not yet choosing to go live with it.

In future articles I will cover prioritization methods and backlog management.