This is a guest post written by Laura Morgan

In this series of articles, our expert coaches answer your burning product-related questions. This month we're looking at the classic product management dilemma of deciding what problem to start solving first. TPR Coach Laura Morgan shares her expertise in this month's answer.

QUESTION: How do I figure out what problem to start solving first? 

We've done a big user journey mapping workshop. Dozens of pain points have surfaced. Now, how do I prioritize which ones are worth solving first? Do I use a framework? Anon

Hi Anonymous!

OK, so this is a question we get quite a lot! Before getting started with my answer, I’d be interested to know who was part of the user journey mapping workshop that’s mentioned here. Including the voices of your users themselves and your stakeholders too is a crucial element of success.

First off, when deciding where to begin,  it's vital to start with organisational or product goals. The main purpose of our role as product managers is to create value for the company THROUGH the customer. So if you don't know what value the company is looking for, it's quite difficult to have a relevant conversation  about which customer problems to solve. So start there. First filter all the potential customer problems by which ones are likely to contribute to the current product goals.

(If you don't have product goals, our article on OKRs might be a good place to start).  

Once you have a bunch of customer problems that are broadly similar in terms of potential value to the company or product, then you can start to think about a prioritisation framework.  Some people use RICE (Reach, Impact, Confidence, Effort), value vs effort, MOsCoW or other frameworks, but ultimately I don't think it matters much which framework you use. I do, though, think it's important to align on your prioritisation methodology with stakeholders so that you've got an audit trail and clear, transparent reasons for your decision making. This process should never be opaque or mysterious.

Remember too that frameworks aren’t scientifically infallible, but are best seen as a starting point for a conversation, during which it’s important to question your assumptions and discuss whether there’s anything you’ve missed. Is there a technical reason why doing something first doesn’t make sense, for example? This conversation needs to be ongoing, and led by the product team, which should include engineering and UX as well as the Product Manager. As Teresa Torres outlines in her book, Continuous Discovery Habits, this shouldn’t be a one-time process either – you need to keep having these conversations and continuously be reprioritizing as you learn what delivers upon your goals.

My final piece of advice would be don’t let not knowing where to start or trying to choose a framework paralyse you into inactivity. There’s a good story about a pottery-making competition, where a ceramics teacher split candidates into two cohorts and gave them a set length of time, with one cohort being judged on how perfect their piece of pottery was, and the other on how many pots they could make in that time period. What the teacher found was that the people who were being judged on quantity did best on quality too – by creating so many pots at speed they were learning as they went, rather than sitting around theorising about the perfect pot.

On the topic of feeling stuck or paralysed, it may be also helpful to consider the idea of one-way versus two-way door decision making, popularised by Jeff Bezos at Amazon. A one-way door is a decision where, once you've made it, the door is closed and there's no going back. A two-way door is the opposite – it's a decision that you can easily revert if you decide it didn't work or it wasn't achieving what you wanted it to.

You can make two-way door decisions without spending too much time thinking about them, because as long as you know how you're measuring whether something is working and make this clear internally, then you can always pivot back if you need to. This puts less weight on prioritization being exactly right ahead of time (which it rarely is, as it's based on assumptions) and more weight on what you're learning as you go along.

Wishing you the best of luck!  

Got your own product-related question or a niggling problem you need help addressing? Submit it for an upcoming Dear Coach here.