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? Do I start gathering more data?


Look at your strategy. What’s most important to move the needle? Where does the business have the biggest problem? Do you leave sales deals on the table every day due to an unsolved problem? Are you losing a sizeable chunk of customers because they get frustrated over an unsolved problem?


This. Step back and look at the bigger picture. Eg : If the CEO’s vision is to grow a substantial amount this year, make sure to keep that in mind whilst planning your road map. Envision what you want to achieve in the short term vs mid term vs long term.

Talk to customer success and revenue as well & get an idea of where the company is at. For example where is the biggest drop off in their funnel. If it’s after someone signs up for a trial but then churns after 30 days, that’s a different issue from a customers churning after using your product for a year.

Review customer complaints and feedback, especially the ones that came from customers who cancelled. Once you’ve got an idea of your shortlist, try speaking to some customers to identify what is more important to them.

You want a balance of high impact features but also include time for quick wins. I try to make sure my team has about 1 to 2 weeks for quick wins, each time we complete a stage in the roadmap of a bigger project


All of this, and when starting into big sets of problems like this it’s valuable to keep scalability in mind - are there any problems you can solve that might make solving the next ones faster or better? Even if it isn’t the quickest win, or maybe of slightly lower impact initially, if it means you can build feature 2 (and maybe 3, 4, and 5) in half the time, it’s probably worth putting at the top of the list.


There’s not necessarily one right way to prioritize, but the two main ingredients to prioritization are the value of solving the problem and the level of effort/complexity in achieving that value.

I like to start with value. What is different/better in the future world where this problem is solved, and how much better? If you’re not sure, it helps to do some research on metrics or customer needs to put numbers around the value.

Then work with engineers to understand complexity. Understand which items are quick wins and which are larger initiatives.

Once you understand value and complexity, you need to figure out what to do first and next. Maybe you start with quick but impactful wins. Maybe you start with the most important strategic priority that you absolutely need to get right. There’s not a right and wrong way, but make sure you’re deciding this thoughtfully. Don’t worry about putting everything in order; just think about what to do now, next, and later.


@Naomi, A follow up question to this. If you are in a fast growing start-up, how do you know whether to focus on the improvements that could be made to the features that already exist and the new ones that may be more exciting or valuable in a different way?


Are there any ways to bucket the pain points together? Like is there actually a higher order problem and all those pain points are actually symptoms?


Start with the company’s mission and company strategy. If your company has OKRs, even better. Based on that, figure out which problems you solve will directly impact the strategy and OKRs and prioritize those.
Also, not every problem is worth solving so get in that mind frame of not rushing to solve every problem.
Here’s a post that might be helpful:


Work with engineers to start discussing how they are solved. Pick off low hanging fruit to go after first. Categorize larger tasks. Figure out what needs more design effort. Give each thing an overall impact value. Weigh everything that becomes a task against the value it brings. Continue to work with the user community to prioritize the pain points by having regular check ins.


Or. Build one or many user journeys - connected set of tasks that provide real value. Pick one that is achievable and provides value, and implement it ends to end. This way you aren’t doing unconnected tasks that might have value on their own, but leave the user hanging…


Honestly, I know there’s a lot of solid answers about prioritization here. But in a lot of cases it doesn’t matter all that much. Just pick one, do it well, and then tackle the next one.

When you have a lot of fires to put out it usually doesn’t matter that much which you do first and which you do fifth. They all need doing. But don’t cut corners as you go, that just buys more trouble later. If picking one based on gut instinct means you start 3 days (or weeks) sooner then that’s what you should do.

Prove to customers that you can identify a problem and solve it well. After that you’ll gain some slack on which one comes next.


@Karan, I’m not sure It’s possible to disagree with this more than I am right now. It’s literally your job as a PM A: know how to figure out this problem (which made me feel like I should bill OP if I answered their question) and B: Know that everything can be prioritized, and that it’s rarely a situation where “everything is on fire, and everything is P-0” In all cases, it is our reason for being to be able to determine the next best thing to do.

This is where having data helps. Gut instinct should be a last-ditch effort, not a way to act quickly. Look at it this way, if you gut-instinct a wrong decision, how do you explain it? “Oh, I just took a stab at it to get it going, and now I got it wrong, so we wasted even more time, my bad.” I’m not saying we can’t be wrong. We are probably wrong way more than right, but at least have solid foundation backing decisions.


@RohitKumar, Well, you completely misrepresented what I said. I never said everything was P-0. Simply that the incremental benefit of doing item 1 before items 2-5 is often negligible.

Junior PMs often crash into the kind of paralysis by analysis that the OP is describing. Uncertainty is a fact of the job. Doing something now is sometimes better than doing the thing you think is the optimal thing later. And in most cases the optimal thing is never as ideal as the textbooks pretend it is. Never hold engineering hostage while you struggle to make a decision.

And to be totally clear, your job as a PM is NOT to figure out problems nor to prioritize things. Your job is to grow the business, period. Moving fast can be more important than moving straight.

1 Like

Hold up. Your job as a PM is to figure out which problems to solve (not to figure out the solution) and to put through the ones that will have the greatest impact. I wouldn’t say it isn’t to prioritize them. PM manages the timing (why this, why now) which is prioritization.