Principle-First: When to Put the Frameworks Down

There’s a moment I’ve watched happen in a lot of product careers, including mine, and it usually happens somewhere around year four or five. You’ve collected the frameworks. You can run a RICE scoring session, facilitate a pre-mortem, sketch an opportunity solution tree on a whiteboard from memory. And then you sit in a room with someone genuinely senior — the kind of person whose judgment you’d trade your whole toolkit for — and you notice something disorienting: they’re not using any of it. They ask three or four plain questions, everyone realizes what the actual disagreement is, and the decision gets made. No canvas, no matrix, no acronym.

For a while I explained this to myself as experience — they’ve just done it so many times they can skip the steps. That’s true, but it’s not the interesting part. The interesting part is what the experience gave them. It wasn’t a bigger collection of frameworks. It was the small set of principles underneath the frameworks, held firmly enough that they could re-derive whichever tool the moment needed, or more often, skip the tool entirely.

This post is the closing argument of the series, and it cuts slightly against the six posts before it: the goal of learning frameworks is to need fewer of them.

Frameworks are compressed principles

Every framework in this series is a compression of a principle that existed before the framework had a name, and will outlive it too.

RICE is a compression of make your reasoning legible enough to argue with. The Mom Test compresses past behavior is evidence, stated intent is politeness. One-way/two-way doors compresses decision speed should scale with reversibility. OKRs compress hold people to outcomes, not activity. Rumelt’s kernel compresses you haven’t chosen anything until you’ve said what you’re not doing. The pre-mortem compresses make dissent cheap before the decision, because it’s expensive after.

The compression is what makes a framework teachable. You can hand a new PM the Mom Test on Monday and their interviews are better by Thursday — no framework I know of transfers a principle faster. That’s the honest case for everything in the last six posts, and I stand by it.

But compression is lossy, and the loss shows up in a predictable place: the edges. A framework encodes what its principle looks like in the situation its author kept encountering. Step outside that situation and the framework keeps producing confident output while the principle underneath it quietly stops applying. That’s how you get WSJF math on a team with no cadence to feed it, Kano workshops classifying features for a market that moved two years ago, a RAID log dutifully maintained for a project whose real risk was never on the list. In every one of those failure modes — and I named one for every framework in this series, on purpose — the tool kept working. The principle had left the building.

The tell: framework as substitute, not scaffold

Here’s the diagnostic I now trust most. Ask someone why the framework says what it says, and watch what happens.

A person holding the principle answers instantly, because the framework is just their reasoning with a name on it: “we’re asking about past behavior because stated intent is worthless, here’s the time it burned us.” A person holding only the framework answers with the framework: “well, that’s the third step of the process.” The first person can tell you when the tool doesn’t apply — that’s the real test, because a principle carries its own boundary conditions and a memorized procedure doesn’t. The second person will run the tool anywhere, and the tool will always produce output, and the output will always look like rigor.

Teams have this tell too. A team using a framework as scaffolding argues about the inputs — is this Confidence number evidence or a wish? Is this really a two-way door? A team using it as a substitute argues about the procedure — did we fill in every quadrant, whose turn is it to update the tree. When the argument migrates from the substance to the ceremony, the framework has stopped scaffolding judgment and started replacing it. That’s the moment to put it down, and it’s exactly the moment most teams double down instead, because the ceremony is the part that’s visible in a calendar.

I’ve been the doubler-down. The RICE spreadsheet I mentioned in the first post survived two full quarters after I knew it wasn’t deciding anything, because retiring it felt like admitting the rigor had been fake. The rigor hadn’t been fake — it had done its job and finished. We’d internalized make the reasoning legible — and the argument the spreadsheet kept trying to settle had moved a layer up, where no score was going to follow it. The scaffolding was standing around a building that was done.

Rules I now use for limiting the toolkit

Three rules, learned mostly by breaking them:

Adopt a framework only against a named, recurring failure. Not because a book was good, not because the last company used it, not to feel senior. “We keep shipping things nobody uses” earns you the discovery stack. “The same three voices dominate every meeting” earns you 1-2-4-All. No named failure, no new framework — because a framework adopted without a problem attaches itself to whatever it touches and becomes ceremony on day one. The “AI-first” wave is this rule broken at company scale, and Klarna and Duolingo’s reversals show what the walk-back costs.

One framework per layer, at most. The cascade has six layers, so a team needs at most six running at once, and healthy teams need fewer, because their strongest layers run on internalized principle and need no scaffolding at all. When I see a team running RICE and WSJF and a quarterly Kano refresh, I don’t see rigor, I see a prioritization argument that keeps not getting settled, being re-fought with new weapons. Stacked frameworks at one layer are almost always a symptom that the disagreement lives a layer up.

Schedule the retirement review when you adopt it. Every framework gets a date — a quarter or two out — where the question on the table is “has the principle sunk in enough to drop the procedure?” Sometimes the answer is no, keep it; onboarding new people alone can justify keeping shared scaffolding up for years, because a framework is also a lingua franca, and lingua francas are worth their ceremony tax. But the question has to get asked on a schedule, because no framework ever volunteers to leave.

What principle-first actually looks like

So what’s left, when the scaffolding comes down? Having watched the people I’m describing at the top of this post, and having gotten a little closer to being one of them, I think the whole series compresses down to something like six sentences:

1. Diagnose before you prescribe. Most bad strategy, and most framework misuse, is a solution that never had a stated problem.
2. Past behavior over stated intent, evidence over eloquence. In interviews, in strategy claims, in your own confidence numbers.
3. Say what you’re not doing, or you haven’t decided anything. Strategy, prioritization, and focus are all the same muscle.
4. Scale decision speed to reversibility. Cheap doors fast, expensive doors slow, and spend the ten seconds classifying which is which.
5. Hold outcomes, not activity. For your team, your metrics, your Key Results, and yourself.
6. Make dissent cheap early. Pre-mortems, assumption maps, and honest RAID logs are all the same move: get the scary sentence said before the commit, not after.

None of these need a canvas. All of them can regenerate the appropriate framework on demand, the way a good engineer can re-derive a formula they’ve forgotten. When a new PM joins my team now, I still teach the frameworks — they remain the fastest transfer mechanism anyone has found. But I try to be explicit about the contract in a way nobody was with me: this tool is temporary; the principle is the deliverable; you’ll know it worked when you notice you’ve stopped needing it.

The senior person in that room, the one who asked three plain questions? Ask them afterward and they can usually tell you exactly which frameworks their questions came from. They did the collecting too. They just kept going — through the frameworks, out the other side, to the principles the frameworks were always trying to teach. That’s the whole path this series has been describing, and the last thing to say about a toolkit is the first thing anyone should have told me about one: it’s for building the judgment, not for replacing it.

(This argument turned out to have a sequel. The agile series reruns it against process frameworks instead of product ones — the manifesto’s values as principles, Scrum and Kanban as the scaffolding, and what’s left when a team takes the scaffolding down.)

Put it to work

1. Inventory your active frameworks and name each one’s problem. List every framework your team currently runs, and next to each, the recurring failure it was adopted to fix. Anything without a nameable problem is ceremony — schedule its retirement review this quarter.
2. Re-derive one framework from its principle. Pick the tool you use most, write the one-sentence principle underneath it, and then design — on paper, in ten minutes — the lighter-weight version your team would build today from that principle alone. If the lightweight version would work, you’ve outgrown the heavy one.
3. Try the three plain questions. In your next contested decision, before reaching for any framework, ask: what problem are we actually solving, what evidence would change our mind, and can we undo this? If those three settle it, notice how much apparatus you didn’t need.

Further reading

• Richard Rumelt, Good Strategy / Bad Strategy — worth rereading through this lens: the whole book is one principle (diagnose first) defended against every framework that tries to replace it.
• Shane Parrish, The Great Mental Models — the general case for holding principles rather than procedures.
• Charlie Munger’s “The Psychology of Human Misjudgment” — the original argument that a latticework of principles beats any checklist, from a domain nowhere near product.