MVP – Thinking Out Loud [Product Management]

My lovely team taking part in a user story mapping session – the main focus of this piece.

In my previous article I discussed what an MVP looks like in government and that, whilst they are not a true MVPs, defining one is still an essential requirement to moving your team in the right direction.

In this article I aim to get amongst the weeds and discuss how you actually go about defining your MVP.

The article will focus on a technique called user story mapping and briefly touch on how you can use visualisation techniques to help bring your stakeholders on the journey.

Some important prerequisites

Before you can effectively use user story mapping, it’s advisable that you have done the following things.

Ran a discovery to understand the problem space and the user needs that you are trying to solve.
Created an as-is service blueprint that shows the current process users must navigate, making it easier to visualise where your product can add value.
Go through an alpha stage to devise and test some concepts that you may use to meet user needs.
Agree upon the winning concept that you can develop into the MVP you plan to release in order to test and learn from.

Before we get into user story mapping, I just want to clarify something.

If you’ve agreed upon the winning concept in the alpha stage, why do you still need to define the MVP?

Well, in my experience, even when the concept has been agreed upon, there likely to still be debate within the team over how to best implement it, or around which features are truly necessary for the first release as opposed to being nice-to-haves that can come later.

Here’s where a user story mapping session is really useful and can help your team nail down what’s going to be included within the MVP by teasing out some interesting conversations.

User story mapping

User Story Mapping is a technique associated with Jeff Paton and is, in his own words ‘a simple idea’.

One that I’ve found to be unparalleled system in helping teams showcase the entirety of their product, build shared understanding and simplify complexity.

What is user story mapping?

It’s a process that will help your team to visualise your product’s features in it’s entirety, including features you want to launch with, plus what to expect from later releases.

How do you run a user story mapping session?

I prefer to do user story mapping in a room using post-is but you could just as easily use a digital whiteboard. Try to make it a collaborative session in which attendees agree upon what user stories are needed to help meet the needs that have been identified in your discovery, and the order in which they’ll be met within your product.

On the board you’ll have your top-level row running from left to right that will have your high-level tasks, or epics.

Underneath that you can have the tasks a user will need to take to complete your epic.

And finally, underneath place the features (or user stories) that are required to enable the user to complete the tasks.

The task will be for you and your team to firstly agree the epics, and then work your way down the board row by row, agreeing what user tasks and stories are needed to complete each epic. What you’ll be left with is a top down view of your whole product from the perspective of your user.

Top tip for running the session.

Have an icebox section in which you pop ideas for the future or questions you may need to answer or consider. Reason being, as you go through this process you may find it triggers some amazing thoughts and discussions within your team. And whilst that’s all well and good, it is handy to have a way to put a pin in discussions that are going too far off track whilst also making a note so you don’t lose cool ideas that may come in useful down the line.

Below is an example of the end result of a user story mapping session.

*Example of user story map. Image from* http://winnipegagilist.blogspot.com/2012/03/how-to-create-user-story-map.html

What does story mapping help you to do?

Walk through the whole user journey and see the bigger picture.
Visualise the MVP and help the team build a shared understanding.
Unearth fantastic conversations about the product that may not otherwise have surfaced, especially around prioritisation.
Prioritise what features are required for MVP whilst also defining your future roadmap of releases.
Define how your solution will meet the needs identified in discovery / alpha phases
Understanding dependencies and showing where you may have blackspots or unknowns in your user journey.

Visualising the MVP

Whilst the user story map that you’re left with is a helpful exercise to go through and will leave you with an asset that your team will understand, I personally feel the end result is perhaps a little off putting to stakeholders.

That’s why, I recommend supplementing this work with low fidelity hand drawn wireframes that you can use with stakeholders to bring to life what you and the team have in mind in an accessible fashion.

Image from https://miro.com/templates/low-fidelity-wireframes/

Did you find this article useful?

If so, I urge you to do a number of things (should you wish to)

Sign up to the newsletter and receive new posts straight to your inbox
Follow me on LinkedIn or Twitter
Share the love and post this article on your social media accounts

MVPs in Government Delivery: Part One – are they actually MVPs, and if not, do I need one?

What is the concept of an MVP?

When I was trying to break into product management, I spent a lot of time reading about agile. My favorite book on this topic is the seminal “The Lean Startup” by Eric Ries.

If you are looking for a book that brings the principles of agile to life, look no further. One of the key things I took from that book is the importance of creating a minimal viable product (MVP) – something Ries defines as a version of a new product that allows the team to collect the maximum amount of validated learning about customers with the least amount of effort. A key concept of “The Lean Startup” is the build-measure-learn feedback loop.

The idea is to eliminate uncertainty by putting products or even concepts out into the wild as early as possible to see whether they have legs, whether the ideas can be improved, whether you should pivot to a new course of action or simply abandon the idea before you waste time and money on something people aren’t interested in. The first step in this process is to establish a problem that you think warrants solving. The next step would then be to define a solution (or an MVP) that you think will help you to solve the user pain point. You would then aim to release this MVP as early as possible to test it with users and iterate based on your findings of live use cases.

Examples of successful MVPs

The origins of the company Zappos are a well-known example of a successful MVP. Nick Swinmurn, Zappos’ founder, wanted to know whether people would buy shoes online. Before buying a load of stock, he tested the concept by creating a website with a load of pictures of shoes that people could buy. If they bought them, then he would go to a shop, purchase them, and post them out himself.

This was a low effort, low-cost way of discovering that people were, in fact, happy to buy shoes online, and so, with that, his business idea took flight as he fine-tuned the MVP into the company that we know today. Check out this link for more examples of successful MVP case studies.

What does the MVP process look like in government?

In my experience, I’ve found working in the public sector prohibits MVPs in their truest sense. It always seems like there is a reticence against putting something truly minimal out there.

I think there are a few factors in this: the civil service having a low appetite for risk, ministers expecting to see something quite polished, and the miles of bureaucracy, red tape, and governance steps you need to navigate in government before you can release anything onto the internet.

This means that government projects tend to use alpha phases to test concepts using prototypes and user research as opposed to observing behavior on live software. Therefore, when government projects launch what they refer to as their MVP into a private beta, what is being released tends to be more like a small-scale version of the eventual product, backed up by a roadmap of future features, as opposed to a true MVP as defined by Eric Ries. Note – for the rest of this article, when I refer to MVP, I will be talking about the civil service-style MVP as outlined above.

Why is it important to define the MVP?

I’ve found that if a team hasn’t defined the MVP at the point in which they are close to starting the build, trouble lies ahead. Not defining the MVP means that everything is still possible, no parameters have been set, and everything is still on the table. Therefore, team discussions are often too broad, theoretical, and likely to bolt off in a multitude of disparate and confusing tangents.

There are a lot of unwanted repercussions from the above happening too. Meetings feel bloated and do not result in outcomes. It is hard to arrive at decisions, and the team will complain they are unsure of the direction. Morale and progress are unlikely to be where you want them to be. Additionally, teams will not be enjoying what I have come to consider to be vital aspects of successful digital delivery – shared understanding of the problem space and a consensus on how to solve it.

Tune in next week for more…

So, hopefully, this article has helped you understand:

• What an MVP is

• What one looks like in government delivery

• The pitfalls of not having one defined

The next article in this series will take a look at how to define an MVP, ways to visualize it, and what to do with it now that you have one.

If this sounds good to you, be sure to sign up for the newsletter to receive it straight to your inbox.

Define your MVP with User Story Mapping

MVPs in Government Delivery: Part One – are they actually MVPs, and if not, do I need one?