Shreyas Doshi's Guide to Validating & Prioritising Ideas
In April 2021, a product leader from Stripe named Shreyas Doshi published a story called "Destined to Fail: A B2B Product Management story". It was the first time I came across Customer Problem Stack Ranking as a way to think about customer discovery or idea validation, and I've thought about building products differently ever since.
I hope it hits you the same way it hit me.
Daniel
โ
Once upon a time, there was an idea for a new product.
The product manager (or founder) diligently goes out and talks to customers to understand whether this product will solve their problems. And customers say yes.
The PM reports her findings to the executive team and everyone gets excited. Staffing and budget are obtained.
Soon after, following all the best Lean Startup and product management principles, they ship the first version.
But hardly any customers adopt itโฆ
At the first product review after launch, the PM directs attention toward the positives. Her learnings include "our MVP isn't sufficient", "we need to make it easier to implement and adopt" and, most commonly, "we just need to build features X, Y and Z.
The team supports her and she gets her mandate to build those features.
Doing all of that takes a lot of extra timeโฆ
So fast forward a couple of quarters and the second version ships. ๐
Adoption is anaemic againโฆ
At the next product review, sales and marketing start getting the blame pointed at them. The PM says something like "we know from talking to customers that we have the right product. We just need to improve our go-to-market strategy."
The team is pot-committed at this point and it feels like there's no turning back. Ideas about how to sell the product better get discussed: reduce prices, cross-sell, bundle, email campaigns, reorganise the sales team.
Changes are made, expectations are set.
Yet growth stays flatโฆ
By the time this point is reached, the original PM has already left the team. A new PM joins and starts with a customer listening tour for their first 90 days. They identify some additional issues, present new findings and recommendations to the executive team, and get a fresh mandate to execute the revised plan.
This can go on with new product teams, revised strategies and more rounds of discovery interviews.
Projects like this get sunset eventually. Learnings are captured and shared widely in the company, the team tells itself "we haven't failed, we have learned", and an Edison quote gets shared at some point.
So, what really happened here?
There are many possible reasons for a saga like this one, but two account for most of them:
A. The product should not have been built in the first place.
B. The original product was ill-conceived, and the later pivots inherited that error.
Option A is the one worth sitting with. ๐๐ป
The product solved a problem, just not the one the customer most needed solved.
Product teams aim for the top right of this quadrant, executing an idea that solves a problem for someone to the highest quality.
That model assumes all problems matter equally, and there's a third axis it misses: how important the problem is next to everything else the customer is carrying.
The best products tackle the problems that matter most, and do it well.
Daniel Kahneman described the Focusing Illusion, which says that "nothing in life is as important as you think it is, while you are thinking about it."
For people in business, that could easily be rewritten as "nothing in business is as important as it actually is, while you are talking about it."
Talk to a customer about a specific problem and they'll focus on that problem, to the exclusion of everything else they, their team or their business are facing.
Your focus puts a disproportionate weight on solving THAT specific problem, which is where the customer's initial excitement about your possible solution comes from, and where the tepid response comes from once you've built it.
Zoom out and put the problem next to everything else that customer is dealing with, and the hair-on-fire problem you thought you'd found often turns out to be a mild inconvenience nobody would go out of their way to fix.
What is Customer Problem Stack Ranking (CPSR)?
Customer Problem Stack Ranking (CPSR) is a method that asks the customer to stack rank the problem your product solves against all the other problems they are trying to solve for their business and their org.
Shreyas Doshi named the framework and used it at Stripe, and people outside the company have since written it up as a standalone product framework. What you get back is a position in the customer's priority list, instead of a score for your idea sitting on its own.
Apply the same thinking across functions. Get the CPSR from the other personas involved too, like the VP Support, the VP Marketing and the VP Sales. Shreyas Doshi made the same point about running it across the buying committee when he described how he looked for product-market fit at Stripe. Read side by side, those lists put you closer to the truth.
What happened when we ran Shreyas Doshi's CPSR on ourselves
When I first read Destined to Fail, I knew immediately that Shreyas Doshi was describing my EXACT circumstances. We'd launched six months earlier and that same week we lost our only subscription customer. Things were looking pretty bleak. We'd run about 150 interviews by that point to figure out what problem to solve, and clearly it wasn't working.
We decided to run one last experiment before giving up: ask a bunch of our target customers to stack rank a list of problems, so we could see where the problem we were focused on solving sat in their list of priorities.
In one evening we drafted a list of problem statements from our customer discovery interviews, shared them with 600 target customers, and could already see our problem statement ranking dead last out of 45 options. The biggest surprise was that 5 of the top 7 highest-ranking problems were very similar to the one we were trying to solve.
So the next morning we rewrote our landing page and product onboarding flow around those 5 high-ranking problems instead. Within a week of starting the stack ranking experiment we had multiple paying customers, our landing page was converting to trial 3x better than before, and we even had our first customer testimonials.
For more on the experiment, read the post explaining the process we followed, or the Full-Stack Researcher version.
More on using stack ranking in your own research
Shreyas Doshi's CPSR is one entry point. These cover the rest of the method.
Customer Problem Stack Ranking: How Stripe Validates New Product Ideas
Discovery Sandwich: How The Best Product Teams Use Mixed Methods Research
Ultimate Guide to Needs-Based Segmentation Using Stack Ranked Data
Value-Adoption Matrix: How To Find Untapped Opportunities In Your Existing Features
B2B Customer Problems and 99 Startup Problems, two problem libraries to draw statements from.
โ
Over 42,000 researchers and product people get one method breakdown like this each week in The Full-Stack Researcher.
If you want a tool for your own stack ranking experiments, OpinionX unlocks every question type and every analysis feature on the free tier, capped at 25 participants per survey, so you can test a full study design before deciding whether to pay. Create a free stack ranking survey.
If you liked this post, consider subscribing to The Full-Stack Researcher โ our newsletter that shares actionable research advice with thousands of product teams and startup founders: