My Product Thinking Toolkit

People ask what frameworks I use. The honest answer is: five, and I have modified all of them. Here they are, tied to the project where I most recently used each one.

Framework fluency without application is trivia. I have watched candidates lose PM interviews by reciting RICE with three decimal places and never once naming a user. The framework was cited. The problem was never described.

I kept only frameworks I had used in the last six months on something that shipped. Anything I learned in a course and never applied, I cut. That filter alone reduced my toolkit significantly. Most of the ones I dropped were frameworks I had studied but never reached for in an actual decision.

JTBD on FitWardrobe. The job wasn't 'identify a garment' - it was 'leave the house feeling okay about how I look.' Naming the job renamed the product. The insight was in the verb, not the noun. I skip the forces-of-progress diagram entirely; the one-line job statement earns its keep on its own.

RICE on the CRM. I use Reach, Impact, and Effort. I dropped Confidence and replaced it with an 'evidence class' label: interview quote, analytic, competitor benchmark, or hunch. Hunches are allowed, but they get labelled. The column forces honesty without pretending hunches have a numeric value.

PRDs on Credex. Three sections: problem, decision (what we're building and what we're not), and success (metric and guardrail). No goals section, no background, no glossary. If it doesn't change what gets built, it's not in the doc.

User stories on Mithivoices. Written as jobs, not features: 'as a bilingual speaker joining a call late, I want the last 30 seconds transcribed so I can join without asking anyone to repeat themselves.' Feature-shaped stories get outdated; job-shaped ones survive scope changes.

Opportunity Solution Trees on SEO-GEO. Used once, when I had five feature ideas and no principled way to choose between them. The tree made the parent opportunity obvious and eliminated two of the five ideas immediately. I don't use OSTs regularly - I tried to on a later project and got eleven branches deep before I lost the thread entirely. I use them only when I'm genuinely stuck.

Across those five projects, these frameworks earned their place by producing arguments I would have otherwise had verbally and forgotten. The doc is not the value. The forced clarity is.

The trap I fell into early was framework tourism - using a new one on every project to feel productive. It slowed everything down. The fix was boring: use the smallest set that gets you to a decision, and only reach for something new when the current tool has visibly failed twice.

If I had to keep only one, it would be the modified RICE. The evidence-class column is where I catch myself lying to myself about what I actually know.