In this instalment of our #Zone5Principles blog series, Zone’s head of engineering, Paul Kiernan, continues to explore how to create a ‘true’ MVP.
Creating a lean MVP boils down to one core concept, ‘The product owner’, and five core activities:
- Research
- Ideation and hypothesis building
- Validation
- Mapping the backlog
- Refining the backlog
This blog will focus on mapping and refining the backlog. For a detailed look at research, ideation and hypothesis building and validation, go to part one of ‘Create a true MVP’
Map the backlog (or feature/story mapping)
I personally think a visual map is more effective than a spreadsheet for initial backlog mapping, it allows us to structure the epics and features in an easily digestible manner, backlogs can be rearranged or restructured and it is a good way of understanding overall backlog size.
Before Covid we would map backlogs out on massive walls with post-it notes, however, in the new world, we use amazing digital tools like Miro. Miro was one of the tools that changed how I work as an individual and we work as an organisation, if you haven’t used it already then you should check it out. I personally only map backlogs on Miro in the initial phase, then when the team moves into the build phase we move the backlog to a tool with more structure and rigour such as Jira.
To create the initial backlog we generally follow the feature/story mapping process, this can be boiled down into a few concepts:
- List epics horizontally
- List features vertically under the epics
- Feature titles should be simple one-liners
- Capture all ideas at this point, try not to get too concerned about size, unless it gets unwieldy or takes too long
TIP: Use “user journey maps” to help the team come up with the feature backlog during the mapping phase. User journey maps will make sure there aren’t any gaps in the experience. Otherwise, these gaps could come out of the woodwork later in the build process impacting deadlines.
You should have something that looks like this:
Believe it or not, in just a couple of hours you’ll have the first iteration of a backlog!
Refine, refine, refine
Once you have a backlog all mapped out, it’s time for the fun bit… you have to carve out a lean MVP from that backlog.
Take a moment and refer back to the vision/goal for the product and criteria for success, layer onto that everything you’ve learned about user needs, technological challenges and business process, then go ask yourselves if each item of the backlog helps you achieve your goal.
A key part of questioning if an epic or feature creates enough value is based on effort/complexity and external dependencies. This is where the experience design and technical advisors need to help guide the PO on what’s required for each epic or feature and how much effort/complexity is involved. Often whether a feature is included or not comes down to return on investment and if the effort will create enough value.
Be ruthless, brave and move with conviction, if an epic or feature adds even two days to the delivery timeline that’s two days you won’t be getting value from releasing your product. If you included three similar-sized features, it means you’ve added almost two weeks to your deadline. This might seem small, but days can turn into weeks and months easily. The PO needs to stand behind each decision and the team of advisors should provide advice and ask critical questions.
The following is a simple three-step framework that can help refine an MVP.
STEP 1: Cut out the nice to haves….
- Draw a line to the right of your current backlog
- Go through each epic and ask how it helps achieve the goal, if the team feels it doesn’t add enough value, move the epic and all features beneath it to the right side of the line
- Draw a line under the current features
- Go through each feature under the remaining epics and ask how it helps achieve the goal, if it doesn’t add enough value then move the feature below the line
- If you can’t make a decision whether something should be in or out, move it into a grey “should have” section and come back to it later.
After this process, you’ll end up with your MVP backlog in the top left corner, nice to haves in grey and conceptually will look like the below.
STEP 2: Estimate and break apart
Go through the remaining items and estimate however you feel is best. Some teams use story point, some teams use t-shirt sizes, others just an arbitrary scale. I personally think the quickest way to estimate is t-shirt sizes. This needs to be done as a cross-functional group, with the PO available to answer questions. Capture feature priority (based on user/business value), decisions, assumptions and hypothetical solutions for later.
Try to keep estimation and discussions reasonably high-level, it’s easy to spend hours going through endless details of each feature. This isn’t the purpose at this phase, we’re aiming to go deep enough to get a good gut feel for the size of work, but not so deep we get lost.
While you are estimating follow the process below to pare back the overall size and complexity of the backlog.
2.1 Find creative solutions to complex backlog items
The solution doesn’t need to be the most technically advanced solution or a super slick fully automated process, it just needs to do the job and get the product into the market as quickly as possible while delivering on the success metrics agreed.
The best MVPs I’ve seen are those that present a super slick user interface for the core product functionality to the end customer, but have manual backstage processes, or less refined ancillary features. This means, all the effort is spent creating value in the customer experience which is ultimately what will make the product a success. If/when the product is proven as viable the team can then start to build out automated backstage processes or enhance ancillary features to reduce time humans spend on manual tasks and layer on the overall experience.
User research is invaluable at this point and guides the team on the core product features. Alongside an empowered PO to understand what manual solutions are acceptable to the business. Make sure you document any solution decisions at this point for later reference.
2.2 Break down features into granular atomic components
Often a feature can have a large surface area of functionality and it’s hard for the team to decide if it should be in or out of scope. Break the feature down into logical parts and then reprioritise what should be in or out of scope. Quite often you’ll find that the feature can be broken down into many parts and only a small percentage of those needs to be built for the MVP.
STEP 3: Plan
This doesn’t have to be exhaustive, you just need to get an idea of the key risk areas, sequence of events, external dependences and a gut feeling that given a certain team size you can fit the amount of work defined into the timelines available.
If you can’t, go back to step one and target the items with the biggest effort, or items that you couldn’t decide whether to include. This is when it gets hard and it pays dividends to create a culture of open and honest conversations with the team and PO.
If you aren’t strict at this stage of defining the MVP you’ll risk overstretching the team’s commitments and compromising on either quality, speed or value.
If the team can’t agree if some particular backlog items should be in or out, agree to park the item and come back to it during the build process. The beauty of an agile process means that if you’re working quickly you can deliver items you previously thought weren’t achievable; conversely, if for whatever reason the team’s velocity is lower it can force some of the harder decisions. This process is something that I’ll go over in another article in this series on continuously managing scope.
Once you’re reasonably happy with the backlog, split the backlog into implementation slices. These slices should be based on build order i.e. what needs to get built first to enable other features, user/business value and effort. The first slice should be whatever it takes to get the first fundamental user journey deployed, the next slice should contain the next user journey and so on. You’ll end up with a feature map like below.
This slicing technique helps the business and team zero in on what is really important for a product to function in the market, making sure that working software is always delivered and the team doesn’t build lots of partially complete journeys.
Conclusions…
In these articles, we’ve discussed the high-level stages a team needs to move through to define a truly lean MVP. The team needs to…
- Have an empowered product owner
- Perform research to inform production definition
- Ideate and hypothesis solutions
- Validate hypothesis and assumptions
- Map the MVP backlog
- Refine the backlog to focus in on the core value of the MVP
If done well, you should have a truly lean MVP product backlog with items that should be the highest value features to get a working product/service into the market with the least amount of effort and time. It will be validated with users, is underpinned by data, backed with agreed solutions and accompanied by a plan of how to achieve the timelines.
Depending on the size of the product or service you’re creating, moving from a vision to a true MVP backlog need only take days or weeks. Generally, the research, ideation and validation phases take the longest amount of time. Mapping out the MVP backlog itself can be done relatively quickly, in workshops or discussions over a period of days. During this phase, it’s good to give the team time to break, reflect on the discussion and then come back and affirm or challenge decisions.
In the next article, we’ll focus on the process of building up the technology solution as part of the MVP process and how to pick the right tool for the job to help build progress at speed while maintaining quality.
Notes:
This article is part of an overarching series aimed at people who develop digital products or services, either in-house or agency side, and have been frustrated by missed deadlines, poor output quality or the overall experience not delivering the value you hoped for.
The information discussed isn’t new or groundbreaking; however, it is generally talked about separately and in silo. These articles will provide a holistic and balanced view of the key focus areas to help teams move quickly while still delivering value.
It’s an iterative process to get all these practices and processes in place, so start small, experiment, persist with what works and take the learnings from what fails.
For a full introduction to the series please read the series introduction article.
Principle One: Look at the big picture, but don’t get lost in it
Principle Two: Create a true MVP (Part One)
Principle Three: Picking the right tools for the job
