Guest Post by: Pete Harvey (Mentee, Session 11, The Product Mentor) [Paired with Mentor, Yossi Mlynsky]
A fundamental human truth is that we are bad at making decisions. All of us. This Wikipedia page – probably my favourite of the c.6m – lists why in stunning detail. We’ll get specific on these later.
Fundamentally, being a Product Manager is all about making sure that the right decisions get made, and for me the hardest decision has always been “what shall we do next?”.
In July 2019, my team was being pointed in a number of different directions. Stakeholders wanted everything on the backlog, and “Prioritization” discussions would always turn into resource discussions. How many more engineers do you need to do everything on the backlog? If you have four times as many engineers, you’ll be able to go four times as fast, right?
As Brooks points out in The Mythical Man Month, while it takes one woman nine months to make one baby, “nine women can’t make a baby in one month”. But clever quotes couldn’t help. I needed to change my approach to alignment.
First we agreed framework for product decision making. At the time of working through this process, my product had just been ‘launched’ after 2 months of private beta testing. We knew we’d ironed out most of the initial niggles, and were ready to iterate.
We agreed that our number one priority had to be achieving Product/Market Fit. In agreeing our framework, we realised that we had been placing too much bias on ‘Market Fit’ in our meetings, and had neglected ‘Product Fit’. This is a classic case of the IKEA Effect – my stakeholders were accountable for sales figures, and had been prioritising their own ideas for onboarding optimisation ahead of features that addressed real customer needs.
Once we’d agreed the framework, I set about breathing life into my backlog. I found that visually representing each item on a large canvas, and then playing around with clustering features / ideas together allowed me to spot some patterns. I realised that most of our backlog items fell into one of two categories: solving for user needs, and solving for internal organisational needs. I further broke these clusters down into subclusters based on the customer they were serving. From this, I further segmented into logical groupings based on the types of problem the feature was looking to solve.
Although time consuming, I set up time with each of my stakeholders to take them through the backlog visualisation. This was helpful for two reasons: it enabled each stakeholder to ensure all of their ideas had been represented (aside: listening increases your influence), and it introduced the concept of groupings (or “themes”).
I then took this completed backlog visual and abstracted it up a layer – from the ‘solution space’ (features) to the ‘problem space’ (user needs). I won’t spend too long here describing thematic roadmaps – Chris Butler and Jared Spool have done a great job of explaining Bruce McCarthy’s idea – but I think it’s worth talking about why it worked with my stakeholders.
Firstly, it changed the conversation from “how long will this thing take to build?” to “how long should we focus on this particular user need?”. The former is a difficult conversation. Optimism Bias and the Planning Fallacy are at play, making it hard to agree on timings and complexity of the proposed solution. The latter is easier, as the solutions don’t need to be clearly defined for a problem to be prioritised, only the user needs to be satisfied.
Secondly, it’s a co-operative and visual process. All stakeholders can get involved, moving themes around on the board until they are satisfied with the groupings. Being strict with the maximum number of items in a column is key here!
One note is that I found semantics to be really important in this phase. There are a number of different options for how you write themes, but I found positive themes (user can do X) to be more helpful than the same theme framed negatively (user can’t currently do X). I also re-framed the alignment meetings as “Roadmap” meetings, not “Prioritisation” meetings. This helped to keep a future focus.
Once the board has been agreed, the next step is setting up the process for regularly revisiting it with the key stakeholders. We have been doing this each time a theme is considered ‘done’ and it is working nicely.
Finally, share the roadmap far, and share it wide. Everyone in the organisation will be thrilled with the clarity it brings.
More About The Product Mentor
The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…
Better Decisions. Better Products. Better Product People.
Each Session of the program runs for 6 months with paired individuals…
- Conducting regular 1-on-1 mentor-mentee chats
- Sharing experiences with the larger Product community
- Participating in live-streamed product management lessons and Q&A
- Mentors and Mentees sharing their product management knowledge with the broader community
Sign up to be a Mentor today & join an elite group of product management leaders!
Check out the Mentors & Enjoy!
Jeremy Horn
The Product Guy
The Product Guy 