We did all this discovery... now how do we decide?
Here's a common challenge for product managers.
When PMs start doing the work called "discovery" — things like user research, user interviews, and voice of the customer — they're excited and hopeful. They're eager to understand what's truly important and how they can make things better for people.
The more discovery they do, the more ideas they get. The ideas, the interviews, the stories, the pain points — they all start to pile up. That's where the problem comes in. Now the PM has a giant portfolio of ideas. But the team can only build one thing at a time. How do they decide on the one thing to do next?
In theory, there are systems to rank and sort ideas. But we all know they don't bring you to a decision. You can't go into a meeting with leadership and say "we should do this because it's a 3.7 and not a 3.5."
Some PMs focus on the qualitative side and try to gather more stories. But they're disappointed when they go to leadership and the stories don't sell themselves.
The counterintuitive thing is, we often feel like our task is to get to a "yes." But what we actually need is a way to say "no." It's the ability to eliminate many, many things that aligns us on the one thing. It's the "no, no, no, ... YES!" that gives us the power to move forward and to stick with a project.
To help us to eliminate (not forever, but for the purpose of making a decision now) I've found one technique very helpful. The trick is to flip things around. Instead of describing the good that will happen by doing an idea, we look at what goes wrong when we don't do it. To make that flip, we can ask two simple questions:
- Knowing the customer can't do what's in the idea today, What are they doing instead?
- What's bad about that?
Let's look at an example. Say we have two ideas. One is "Customers need a way to upload archived invoices" and the other is "Users need a way to grant access so other employees can search past contracts." How do we compare these two and how do we decide which to invest time into now?
Take the first one. "Customers need a way to add archived invoices." They can't do that today, so we ask: What are they doing instead? We find out they are uploading PDFs of archived invoices into a Dropbox. Okay. Then the second question is: What's bad about that? In this case, the answer was "Well, it's working... but it's inefficient to have things in two places."
Now take the second example. "Users need a way to grant access so other employees can search past contracts." What are they doing instead? We learn that people who can't see the contracts are asking around, finding someone with access, asking them to search for them, and waiting. What's bad about that? Well, waiting for someone else to do it is obviously bad. But we don't know how bad it is. When I ask this question, I often start with "I know this is a dumb question, but..." In this case, we find out that a big customer almost missed a deadline because a team member couldn't access the info they needed and the person who did have access wasn't responding.
Having flipped to the "what's going wrong" side, let's compare. While the archiving story isn't ideal, it's not bubbling up to a bigger problem. The story about missing access, on the other hand, has meaningful implications for satisfaction, retention, and churn. Therefore we can say "no" to the archiving idea and consider a step forward on the access idea.
Whatever kind of discovery work you do, there comes a time when you need to turn all those inputs you've gathered into real projects. We call that work "framing." How to frame projects is a vast topic in itself. But the technique in this post is one that can get you started. As a tool in your toolbox, it'll help you switch from a conversation about "needs" — which are hard to quantity — to a more objective conversation about what's going wrong.
We touch on framing and teach examples of narrowing down the problem and building the case for it in the Shaping in Real Life course. The next cohort starts on December 2.