Recently I’ve been running roadmapping sessions and MVP planning sessions with Outlandish, the worker-owned tech agency.
Combining elements of design thinking practice as championed by IDEO and Stanford’s d.school, and mixing it together with great advice from Jon Kolko on how to think about emotions and roadmaps, they’ve gone pretty well.
Here’s a process for running something similar with your own teams:
When to use this:
- Planning the future for an existing product, particularly one which might be underperforming.
- Or planning a new product’s MVP (Minimum Viable Product).
If you’re working on a new product, you could run these activities as part of a Design Sprint. Some good places to do it are after the creative activities (sketching out initial ideas), or after the user testing of the prototype at the end of the Sprint.
Time required:
~ 0.5 day with your team
Step 1: Identify the users
Ask the team to identify who they think are the important users of the product. What do I mean by users? Not demographics, but rather people in situations.
No: An English woman in her mid 20s.
Yes: A press officer in a mid-sized NGO.
Yes: A press and PR team manager in a mid-sized manager.
Get everyone to write as many as they can, one per sticky note. They can hang on to their sticky notes for now, no need to gather them up.
Include the internal users
Whatever you’re building you’re likely going to have a few extra, critical users to think about. There’s the end user/customer, that’s for sure, but maybe you’ve got some wider stakeholders who connect with your product in some way to address; for example, other teams, external services, funders, CEOs and more.
Who do you have to convince your project is worth partnering with, building upon or funding?
Make sure that these people are captured as users too, because even though they might not be using the product directly, they still have an experience that relates to it.
Make sure you have a diverse range of users
In this situation, and if you’re running this process with a team, different team members will likely choose the most important users from their point of view.
On the off chance that everyone picks the same user, or if you’re running this with just one person, then encourage the identification of a few more users.
Step 2: Pick the most important user
Ask everyone to individually choose what they think is the most important problem and user. It’s good to say “important” rather than “biggest” or “urgent” or such here, as it leaves this open to interpretation. The criteria of “important” is up to each team member.
Everyone should make a note of their problem on another sticky note. Again, they can hang on to these.
Step 3: Turn the problem into a Point of View Problem statement
Championed by the Stanford Design School, a point-of-view (POV) “is your reframing of a design challenge into an actionable problem statement that will launch you into generative ideation”.
That sounds like fluff, but the key here is “actionable statement”. Rephrasing the problem into such a statement really does help stimulate creative activities. So here’s how we do it:
Everyone thinks about the user and problem they just captured. Take the problem sticky note and use it write a statement about your user, in this format:
[USER] needs to [USER’S NEED] because [SURPRISING INSIGHT]
One of the best examples I’ve seen of this, also from Stanford’s Design School, runs:
The project: Redesign the ground experience at the local international airport
The user POV: A harried mother of three, rushing through the airport only to wait hours at the gate, needs to entertain her playful children because “annoying little brats” only irritate already frustrated fellow passengers.
Note the surprising insight part. It’s not something broad and basic such as “because children annoy other people”, but something that believably conjures a real scene and is empathetic to the user (we’d all hate our own kids to be thought of as brats).
Ask your team to create their own POV Problem Statement for their chosen user on a third post it. Once this is done they can trash the problem sticky – they don’t need it anymore.
Ask everyone to read out who their main user is and their POV Problem Statement.
Step 4: Identify the value
We’re going to put the work done so far aside for a moment (we’ll come back to it shortly), and now think about value.
Jon Kolko, in his book Well-Designed: How to Use Empathy to Create Products People Love, has a great explanation about value and it’s worth getting his book to understand the importance of ‘value’ on a deeper level.
In short, there are many types of value: economic, social, personal, spiritual, emotional. Value is whatever the user feels it to be.
We’re going to ask our team to take a moment to think about the value that their user gets from using the product. For example, is it monetary savings (economic)? Increased influence in their network (social)? And so on..
Give it a few minute or so….
Turn value into an emotional statement about value
Now it’s not actually the value that someone receives from a product which is important, but rather their perception of and emotional reaction to this value which is most crucial. This is crucial to the idea of satisfaction, which, along with utility and usability, is a key component of UX.
So everyone needs to take the value they’ve identified and turn these into an emotional statement, from the point of view of the user.
In other words, everyone writes how the user feels after using their app.
It doesn’t matter that we don’t know what the solution is or what we’re building yet. But we can still imagine a future where our product exists and users are engaging with it.
And if we can imagine this, we can imagine how they feel after using it.
For example:
“After using our financial advice tool, the user feels comfortable and secure that they are making the best investment decisions with their savings.”
Everyone write a Value Statement on a sticky note.
Create swimlanes on the board
That’s already a lot of work and a lot of sticky notes! Now is the time when we come together and start to work more collectively.
Each member of the team takes their sticky notes for User, POV Problem and Value Statement, reads them out and puts them up on the board.
As facilitator, make sure they go up on the far-left of the board, with plenty of space to the right (you’ll need a lot of space in later steps). Also, make sure they are arranged in swimlanes, so it looks like this.
User | POV Problem | Value statement
User | POV Problem | Value statement
User | POV Problem | Value statement
The ordering and tidiness are important here, because things will get messy later!
If there are any duplicate users that’s fine, they can be merged. Talk about it with the team.
If there are duplicate users and duplicate POV statements, you might want to combine these into the same swimlane.
Step 5: Generate feature ideas
Now this is actually one of the hardest parts of the process, so stick with it and you’ll see some real gems come out at the end.
In short, you need the team to generate ideas for what their solution to this problem may involve.
If you’re doing this after already working up some solution ideas….
E.g. you’re running this as part of a traditional, Google Ventures style Design Sprint – then you’ll probably have some ideas and sketches already created to draw upon. Maybe you’ve already tested a prototype and have some feedback too.
… else if not, and this is an existing product:
It might be worth pausing to:
- show the existing product, just to refresh everyone’s minds about what it looks like and can do
- review any user testing research already undertaken
- pull out that ever-increasing list of ideas, suggestions and anything from the old backlog
Tip: to help facilitate this and ensure that momentum is maintained, avoid crowding around a screen. Instead, prep the room in advance:
- post screenshots of the product up all over the place
- put up quotes from users and test subjects
- generally, provide a lot of eye candy around the room
… or if this is for a completely new product
If you’ve launched straight in to this and haven’t done any idea/solution generation yet, such as you might do in a traditional Design Sprint, that’s fine. However you’ll need to pause at this point to run some activities to generate some of these creative solutions.
I recommend taking a flip through the Design Sprint book and running the activities for Crazy 8s and Solution Sketches here.
- Crazy 8s: a brain-dump sketching exercise, each person making rough sketches showing a possible solution, 1 per minute), leading to…
- Solution Sketches: taking one of these ideas and, over a good hour or so, each person sketching out some key screens to show what the user sees.
- Then a presentation of each person’s work and the team decide which idea (or aspects of the various ideas) to take forward.
These will help decide the overall concept to be used in the next steo=p.
Capture the ‘epic’ feature ideas
Using everything that’s been researched and discussed so far, and the ideas proposed and decided upon, everyone jots down the large-scale features (here it is the user-facing functionality) that need to be built.
Write one feature per sticky note.
For example, for a financial advice app, large scale features might include:
- Show customer finances
- Share data with accountant
- Email updates
- Show market data
- Live chat with financial advisor
- Printable reports
- … etc
Get the team up, read them out one by one and slap them on the board to the far right of your post notes.
Any duplicates or overlaps can be grouped together.
Tip for facilitators: People often forget to allow for building the common product features, so it’s worth prepping a few extra sticky notes in advance. Some typical examples include:
- Update account information
- 2 step verification / account security
- Alerts
- Social sharing
- Charts, visualisations
- … etc
If they’ve not already been added, make sure these go up on the board too.
Step 6: Get ready to roadmap
Identify the MVP or first phase features
Now, really channeling Jon Kolko’s great roadmapping exercise, each team member takes a note and asks their colleagues: can we achieve value for our chosen key users (and solve their problems) without this feature?
If yes, leave it where it is on the board. If no, move it to the left side and place it in the appropriate swimlane next to your User. POV and Value statement.
It’s a bit of an about-face and abstract way of looking at features, and you might have to explain it a few times to the team.
After all the team have reviewed these, you’re going to end up with a stack of sticky notes and features on the left hand side swimlanes, near the appropriate User, POV problem and Value Statements.
Well done! You’re halfway to having a list of features for your MVP or first phase of work. Draw a line to make sure these are all in a nice, tidy column. Then draw an axis along the bottom of the board to show time.
Break it down
However, in reality I’ve found that there are often still too many features for an MVP / Phase 1 of work, and many of these features aren’t minimal enough to be truly considered MVP features.
So what works now is to separate them out further and put them into a series of phases.
Draw some more columns on the board after the MVP / Phase 1 column. Each of these columns represents phases in your project’s lifecycle (not Sprints, Agile fans, we’re not at that level yet).
Now brief your team to think more about the features that are in the MVP column. Ask them to think carefully about each of these and spread them out more. Ask them to consider:
- The extent to which this feature delivers the value – compared with other features, does it deliver a huge amount of the value, or only a small amount
- The market size – what % of your users are going to benefit from this feature
- The return (or if you’re looking at income, the margin) on delivering that feature
- Feasibility of delivering it (how challenging does it feel in terms of tech, resources, organisation buy-in etc…)
- Can any of these epic features be broken into parts, (e.g. ‘send text message alerts’, then later ‘users can edit alert settings’)
And remember, the team need to keep asking: how critical is this? Is this feature really something that must be delivered in order for the first phase to work/deliver value/succeed?
It’s likely that once you get everyone thinking along these lines, they’ll start to realise that the features already placed in the MVP / Phase 1 column aren’t all critical, and many can be moved along to later phases.
You’re aiming to end up with a spread of features across the many phases of your project. This will take some time and needs good, relaxed discussion. So make sure it stays on the feet and at the board.
Hopefully at this point you’ll see a good list of feature ideas broken out along the board. There’s probably still going to be quite a few, so now is the time to channel your inner Design Sprint facilitator: break out the voting dots!
Choosing what to do:
Give people 3 or so dots, and ask each person to vote on which ones they think are the priorities. That should help agree priorities for work and effort.
And that’s it! At this point you’ll have a roadmap! You’ve identified your core users and who your roadmap serves; you’ve captured their challenges and value they’ll get from your product, when it is launched; and you have a roadmap of phased work and features to launch.
All that is left to do now is take it to your teams and stakeholders, and begin
And, of course, update it. Regularly.
Good luck with your products!