Executive Summary
- Get a great Product Owner and never let them go
- Keep trying to connect features back to the original user need
- Visually prioritise user needs and make sure they are visible and kept up to date
Intro
You are reading this article, and that means you are probably doing everything that I suggest already 🙂
Give it to someone who isn’t.
Summary
- Think of MVPs as “minimum that user would find useful” instead of “minimum feature set that we can deliver”
- Prioritise your user needs first
- Learn what will satisfy your user
- ‘Story map’ user needs. Visual prioritisation is extremely powerful
- Define features from user needs and then prioritise them
- As you think about MVP, sprint and general feature prioritisation, refer back up to user needs. Do they still make sense?
- Draw it somewhere. People understand nice simple drawings
Why user needs take a back seat to features
Everything in this article should be almost patronisingly obvious.
Assumptions
- Assumption 1: We should look at user needs first
- Assumption 2: We should prioritise user needs (needs)
- Assumption 3: We should define features to meet these needs
- Assumption 4: We should prioritise these features
- Assumption 5: We should iteratively build and gain feedback about these features etc….
We all start like this.
Question: How easy was that ?
Question: How often does it flow just like that?
I am happy for you if this is your life. I am guessing you have a really great Product Owner (PO) that you guard well and are not giving back.
The first two areas, (needs and prioritising them), are where I think most mistakes crop up. They tend to get done at the start of a project and then fade into the background. A good PO does these things, often in their head, and things are OK for a bit. They move onto another project and you can be left with a set of features with no real connection to the original need.
PO’s often use tools like story mapping, to prioritise backlogs and this is great. The issue is that they are normally prioritising features in their backlog and not user needs.
Dev teams like to see prioritised features but can be less receptive to user needs…until you make the connection easy for them.
Sometimes there is a one to one relationship between need and feature but often this is not the case.
Example1:
*Need:
- I need someone to help me when I get stuck
*Feature (Possible)
- A phone number on the site (to call)
- A phone number on the site (to sms)
- An email address on the site
- A contact us form
- A web chat
- A physical address to send a letter to
- A physical location to visit
- Etc…
It is easy to lose track of the user need when looking at so many options and this is a very simple example.
Taking an iterative approach we might decide to just add a phone number, and see how many calls we get, and if anyone says they would rather use another channel.
We would test and gauge desire for other channels. We might end up adding other channels.
All of this is continually referring back to the user need. That is good.
In more complicated examples and when POs have this all stored in their head it can become too hard to maintain these connections.
It is quite common for technical issues to take centre stage and before you know it, you are prioritising based on technical priorities. Yes this is useful, BUT, just check that you have not lost site of the user needs prioritisation.
Changing the language to change behaviour
So one thing we can do is talk about MVP slightly differently.
Originally they were: “Minimum set of features that can be delivered to satisfy customers”. Features can become the hammer that is looking for a nail. Maybe we should change this to not mention features at all. How about “The least we can do that will still satisfy customers”. It might not even need a feature.
I have not even covered the “learning” aspect of MVPs…