The Pantry Test
If the idea starts with the ingredients you already have, you are not working backwards
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 4
- Confidence
- 90%
Nearly every PM believes they are problem-focused. The Pantry Test is McAllister's diagnostic for the ones who aren't. It listens to how the idea is *narrated*: if the opening move is an inventory of assets and technologies that could be combined, the solution came first. If the opening move is a problem that feels painful before any solution is named, the team is genuinely working backwards.
Origin
McAllister's own heuristic, developed over 12 years at Amazon and refined while reviewing working backwards docs from over 100 PMs he has managed at Amazon, Airbnb, and Uber. He frames it as the tell that most reliably tips him off.
Core principles
- 01Big companies fail this test more often than startups — they have more ingredients in the pantry.
- 02Combining assets can create real leverage; it just isn't a substitute for a problem.
- 03The startup pitch structure — big audience, painful problem, then a novel way to solve it — is the correct shape.
- 04Painkiller beats vitamin. If the problem isn't painful, the combination isn't interesting.
How to run it
- 1
Listen to the first thirty seconds of the pitch
Note whether the speaker opens with a technology, a service, an asset, or a combination of building blocks — or with a customer and a pain.
Pro tip The words 'we could' are the loudest signal. 'We could combine these' is a pantry statement.
- 2
Strip the solution and re-test the problem
Ask: if we could not build this, would the problem still feel compelling? A genuine problem is compelling before you know the solution.
Pro tip Run this on your own ideas first. It is far easier to see in other people's.
Watch out A problem that only becomes compelling once you've described the elegant solution is a retrofit.
- 3
Check the name of the project
If the project is named after an internal identifier, system, or technology rather than a customer outcome, it is very likely solution-first.
Pro tip Rename it after the customer's problem and see whether anyone can still explain why it matters.
- 4
Refuse to engage until the problem is on the table
Adopt the discipline of not processing solution information at all until the customer and the problem have been stated. Then, and only then, work backwards to how you solve it.
Pro tip If there are three problems, force a ranking — one, two, three — before discussing solutions.
Watch out This will feel obstructive to teams excited about their combination. That friction is the point.
In the wild
The Amazon community team's flagship project was called 'ASIN to ASIN linking' — ASIN being Amazon's internal product identifier. The name itself declared it was built from the ingredients on hand rather than from a customer problem, and the whole team was excited about it because the idea had come from Bezos in a meeting.
→ The project was not successful and McAllister eventually shut it down. In hindsight he says he should have known from the name alone.
McAllister contrasts the pantry pattern with the standard startup pitch: a big audience, a painful problem, and then a novel way to solve it. Startups pass the test more often precisely because they have almost nothing in the pantry to combine.
→ The test reframes big-company advantage as a hazard — more assets means more temptation to build combinations and feed them to customers who never asked.
Common mistakes
Confusing asset leverage with customer value
It may genuinely be true that combining two internal technologies is cheap and clever. That says nothing about whether anyone has the problem the combination solves.
Assuming you pass because you wrote a problem statement
Most PMs believe they start with the problem. The test is not whether a problem section exists in the doc — it is whether the problem existed before the solution did.
Is it for you?
Best for
Product leaders and reviewers auditing whether a team's 'problem-first' process is real or performative, especially inside large companies with rich internal platforms
Not ideal for
Genuine platform or infrastructure work where the internal capability IS the deliverable and the customer is an internal team
From the transcript
“the building blocks are there and what's enabled if you add these two building blocks together is is something but that's not really working backwards”
“if there's a customer problem that feels compelling even before you know the solution like yeah that does feel compelling”
“you'll have all these ideas because you have more ingredients in the pantry of ways you could combine them”
From the episode
What it takes to become a top 1% PM
Ian McAllister (Uber, Amazon, Airbnb)