Generated using: google/imagen-4-ultra

When Good Frameworks Go Bad

TL;DR: Product frameworks — RICE, OKRs, Agile, Design Thinking — all started as genuine solutions. Then companies turned them into bureaucratic rituals that let teams avoid making hard calls. Frameworks can’t replace judgment, but we keep pretending they can because judgment is scary and political. Amazon, Apple, Stripe? They don’t score features in spreadsheets. They make bets.

Walk into a product planning session and watch the same ritual unfold. Features lined up in a spreadsheet or confluence, each scored across multiple dimensions, multiplied together, sorted by the resulting number. RICE evaluates Reach, Impact, Confidence, and Effort. ICE scores Impact, Confidence, and Ease.

The numbers promise objectivity.

Sean McBride built RICE at Intercom in 2018 because his team kept prioritizing pet projects over work that mattered. Sean Ellis created ICE at GrowthHackers even earlier — the guy who coined “growth hacking” needed something to break through bias. Both frameworks solved real problems. Teams made faster decisions. Arguments stopped. Executives got defensible answers when they asked “why are we building this?”

But here’s what nobody talks about: what does a 5 actually mean?

Without explicit definitions, teams can’t maintain consistency. One person’s Impact score of 7 is another’s 4. Different evaluators use different mental models. The frameworks promise objectivity while delivering pure subjectivity wrapped in math. And when you multiply Reach × Impact × Confidence, you’re claiming these factors are equally important — which is almost never true.

Teams spend months scoring features down to decimal points while competitors ship.

This Isn’t Isolated — It’s a Pattern

Here’s what’s really happening:

Product management has a frameworks problem, and it’s not about prioritization.

Every major framework follows the same trajectory. Created with genuine intent to solve real problems. Adopted widely because they work — at first. Then corrupted into bureaucratic rituals that deliver the opposite of what they promised. The corruption isn’t accidental. It’s structural.

This mirrors what happened with OKRs a decade ago. Google introduced them as a tool to enable autonomy and alignment. Companies adopted them as performance management kabuki.

Or Agile. Seventeen independent-minded practitioners met at Snowbird in 2001 and wrote a manifesto valuing “individuals and interactions over processes and tools.” They chose the word “uncovering” deliberately — rejecting silver-bullet thinking. What emerged? Waterfall with standups. Scrum ceremonies as checkbox exercises. Teams going through the motions while real decisions happen elsewhere.

Or Design Thinking. David Kelley built IDEO’s human-centered approach through decades of actual design practice. The famous 1999 Nightline episode showing their entire process never mentions “design thinking” once. Tom Kelley’s 2001 book The Art of Innovation doesn’t use the term. But by 2013, it appeared 50 times in their book Creative Confidence. The methodology got productized, packaged, sold.

Now? Empathy maps as bureaucratic artifacts. Design sprints where teams check boxes on Monday (empathize), Tuesday (define), Wednesday (ideate) — regardless of what they’re learning. Innovation performance art.

The OKRs Story Shows Why

Andy Grove created OKRs at Intel in the 1970s because he faced an existential threat. Motorola and Zilog were crushing Intel’s microprocessor business. He needed rapid alignment without sacrificing agility. So he took Peter Drucker’s Management by Objectives and transformed it.

The key changes:

• Quarterly cycles instead of annual
• Transparency across the organization
• Stretch goals that drove innovation
• Decoupled from compensation — this was critical

John Doerr learned about them in 1975 at Intel. Brought them to Google in 1999 when the company had 40 employees. Larry Page later credited OKRs with enabling “10× growth, many times over.”

What made them work? Grove designed OKRs as scaffolding for judgment, not a replacement for it. The framework enabled faster decisions during uncertainty. Doerr himself said OKRs “won’t fill in for excellent leadership or an inspiring workplace culture.”

But companies that lacked leadership and culture adopted OKRs hoping the framework would compensate. It never did.

What’s really happening here is teams are outsourcing judgment to spreadsheets because judgment is hard and politically risky. Nobody wants to be the PM who killed the CEO’s pet feature. Nobody wants to admit they don’t actually know if users will love something. Frameworks provide cover. “It’s not my opinion, it’s the score.”

The corruption follows predictable paths:

• OKRs get tied to performance reviews and bonuses, killing stretch goals
• Teams set conservative OKRs to protect ratings
• Quarterly planning becomes elaborate performances
• Key results become vanity metrics that look good in slides
• The transparency principle gets twisted — OKRs become political documents carefully worded to avoid accountability

Same pattern across every framework. Agile becomes story point inflation and Jira ticket mills. Design Thinking becomes scheduled “empathy sessions” where teams fill templates, check boxes, never spend real time with users.

The Economics Are Wrong

Here’s the insight: these frameworks reduce short-term conflict at the cost of long-term strategic coherence.

You get faster alignment on individual features. But you lose sight of whether those features add up to anything meaningful. Local optimization tanks global outcomes. The math feels productive — multiplying scores, sorting features, defending numbers. It’s procrastination disguised as process.

The actual cost? Amazon’s Fire Phone. $170 million write-down. They built something technically impressive — four front-facing cameras creating 3D effects. It solved exactly zero problems customers cared about. The innovation was real. The product thinking wasn’t.

This is what happens when you prioritize in solution space instead of problem space. You can score features all day. If you’re scoring the wrong features, the math doesn’t matter.

After the Fire Phone bombed, Amazon doubled down on their PR/FAQ approach: write the press release and FAQs before building anything. If you can’t articulate customer value in plain language, you don’t build it. No scoring needed. Start with what customers need, then figure out how to deliver it.

The irony? Amazon doesn’t use RICE or ICE for product decisions. Neither does Apple. Neither does Stripe. Know what they use? Judgment. Informed, structured judgment backed by customer research and strategic clarity.

They have processes — Apple’s DRI system, Amazon’s PR/FAQ method, Stripe’s written memos. But these processes force thinking, not calculation. The difference matters.

Why Frameworks Fail

A lot of product managers don’t know how to prioritize without customer feedback. They fall back on gut reactions, support requests, feature parity with competitors. Frameworks promise to fix this. They don’t. They wrap gut reactions in convincing-looking arithmetic.

The failure modes are predictable:

Mixing discovery with delivery. Teams score features they haven’t designed solutions for. Or only score features where someone spent time on design, creating selection bias from the start.

Recency bias. Customer support escalated something last week? Suddenly it’s a 9 for Impact. That strategic bet you’ve nurtured for months? Still at 6 because nobody remembers why it matters.

Gaming the system. Confidence scores become negotiation tactics. People who want their project to win inflate estimates. People who don’t want to commit deflate theirs.

No agreed standards. Even with detailed rubrics, stakeholders interpret numbers differently. Engineering thinks “Easy” means one sprint. Product thinks one day. Sales thinks… who knows.

But the real problem goes deeper. Frameworks promise to make hard decisions easy. They can’t. They weren’t designed to. Grove, the Agile signatories, Kelley at IDEO — they all knew their approaches required excellent leadership and cultural commitment. The frameworks were tools for better judgment, not replacements for it.

When organizations lose sight of this distinction, they create the very bureaucracy and inflexibility the frameworks were designed to overcome.

What Works Instead

Stop treating prioritization like a math problem. Start by getting clear on strategy. What are you trying to accomplish? What kind of product are you building? Who are you building it for?

These questions don’t have numerical answers. They require judgment, debate, conviction.

Segment your work:

Strategic bets get the full treatment. Write the narrative. Debate the merits. Don’t score these — decide based on whether they advance your strategy and whether you have conviction in the approach.

Tactical improvements can use lightweight frameworks. Just timebox it. 30 minutes, not 3 days. If two features score within 10% of each other, the difference doesn’t matter. Pick one and move on.

Technical debt doesn’t score well on Impact or Reach because benefits are diffuse and long-term. Address it based on pain level and risk, not by forcing it through frameworks designed for features.

Most important: iterate your approach. What works for a 10-person startup won’t work for a 100-person scale-up. Treat your process as a hypothesis. Test it. Adjust it.

The Point Is…

Every framework in product management — OKRs, Agile, Design Thinking, RICE, ICE — started with people trying to solve real problems. Grove needed agility at Intel. The Agile signatories wanted to escape waterfall. Kelley wanted genuine empathy for users. McBride and Ellis needed to break through bias.

Their solutions worked. Then companies adopted them without understanding why they worked. The tools became ends in themselves rather than means to better thinking.

What separates good product decisions from mechanical scoring? Judgment. Strategic clarity. Understanding of customer problems. Willingness to make hard trade-offs and defend them based on conviction, not calculation.

You can’t outsource that to a spreadsheet. You can’t check a box and call it empathy. You can’t hold standups and call yourself Agile. You can’t multiply scores and call it strategy.

The ritual feels productive. It isn’t.

Real product work requires stepping back from features entirely and asking whether you’re solving problems that matter. That’s uncomfortable. It means being wrong sometimes and owning it. It means telling executives “we’re not building that” without a score to hide behind.

But that’s the job.