The PM world runs on frameworks like RICE, JTBD, OKRs, Kano, and MoSCoW. These frameworks have become popular because they offer a packaged way to solve a problem through a neat, repeatable process. However, while they might give you clean, ranked answers, they often aren’t tailored to your unique context and can cause you to miss the mark.
I learned this the hard way. I once inherited a freemium product with more than 50 conversion entry points scattered across the funnel. I ran a textbook prioritization pass: I scored everything, sorted the list, and presented the top item with total confidence.
It was wrong. Not “we disagree” wrong, but factually missing the point wrong. The scoring framework flattened 50 conversion moments into a single ranking and ignored what mattered most. The math was clean, but the conclusion was garbage.
Here’s the reframe the whole article hangs on: your framework isn’t the work. The read is. Read your context before you reach for a tool, bend the tool to your reality, and drop the whole shelf when nothing fits.
Frameworks break because your situation lives in the context they abstract away. There are three main ways they go wrong.
RICE, ICE, and weighted scoring promise math but often deliver opinions dressed up as math. Your “impact = 7” is my “impact = 4,” and neither rating can be proven. A number you can’t defend isn’t evidence of product rigor.
Rename the PM “Product Owner.” Set up the Jira board. Go through all the motions without delivering the outcomes.
I’ve watched teams write OKRs in January, file them away, and not reopen the document until December. Then, they backfill the key results to match what actually happened.
A startup isn’t a miniature big company. Run a B2C growth playbook in an enterprise sales environment and watch it faceplant. This is also why “universal” methodologies deserve some side-eye.
The common thread is that a framework is a starting hypothesis, not an answer. Treat it as the answer, and it stops working for you and starts working on you.
Choosing the framework is the easiest 20 percent. Reading the situation is the other 80 percent, and almost nobody does it. Before reaching for a template, ask a few questions:
Borrowing from the Cynefin framework, ask whether cause and effect are knowable or only emergent. If the problem is complicated, such as reprioritizing a known backlog, a framework like RICE can help. If it’s complex, such as predicting whether a feature will change behavior in a market that doesn’t yet exist, no framework can give you the answer.
This is Bezos’ one-way versus two-way door distinction, one of the most underused filters in product management.
Is the decision irreversible and expensive, such as changing your pricing model, rebuilding the core architecture, or making a public commitment? Slow down, use a more rigorous framework, and run a pre-mortem.
Is it reversible and inexpensive, such as changing a button color or adjusting a feature flag? Decide and move on. Most apparent one-way doors are actually two-way doors. Learn to spot the difference, and half your process bloat vanishes.
Pre-PMF, scaling, and mature products operate in different worlds with different physics. Then, add the boring constraints: budget, team capabilities, and regulatory realities. A framework that assumes you have a data team is useless if you don’t have one.
Sort the problem by altitude: strategy, execution, or perception. I’ve burned the better part of a quarter RICE-scoring a backlog when we’d chosen the wrong strategy. We were executing the wrong list faster, with prettier scores.
Diagnose the altitude first, or you’ll bring an execution tool to a strategy fight.
Your output should be a paragraph rather than a decision: This is a complex, hard-to-reverse, pre-PMF strategy problem for a small team with no analytics. That diagnosis tells you whether any framework deserves a seat and, if so, which one.
Now, and only now, do you open a template. Every candidate receives one of three verdicts: use it as is, which is rare; adapt it; or skip it:
RICE is an easy example because everyone misuses it in the same way: Reach gets flattened into one number, Confidence becomes a reflexive 100 percent, and Effort is based on a gut estimate that ends up being off by 40 percent. Garbage in, confident garbage out.
Using RICE properly means rebuilding the framework around your reality. Calculate Reach by customer segment. Split Effort into the components that actually vary, such as engineering time, design time, and QA overhead. Tie Confidence to evidence and define Impact according to your intended outcomes.
This is where tailoring starts to matter. At Brainly, the standard funnel assumed that the user was also the buyer. The problem was that most users were teenagers, and teenagers weren’t the ones pulling out a credit card. Their parents were.
Reweighting the framework around the actual buyer flipped the ranking. Features that had been dead last jumped to the top. It was the same framework with the opposite answer.
Frameworks answer different questions, so stop forcing one framework to do everything. JTBD is useful for discovery because it identifies what people are trying to accomplish. RICE can help with prioritization by identifying what to build first.
Run JTBD first, then apply RICE to the job you uncovered, not the original feature list.
OKRs at a 12-person pre-PMF startup shouldn’t look like OKRs at a 2,000-person scale-up. Early on, they’re about validation, and the right cadence might be monthly. At scale, quarterly growth OKRs can make sense.
Apply an enterprise cadence at a startup, and you’ll find yourself optimizing against assumptions that became outdated weeks ago.
Sometimes, the generic rule needs to be inverted entirely. Consumer product orthodoxy says to reduce friction, show fewer ads, and make users happier. On one adtech platform with well over 100 million monthly active users, we did the opposite: We showed more ads, more often.
Complaints should have spiked. Instead, they dropped because we paired the increase with better targeting. The generic advice wasn’t merely wrong. The right move was the reverse.
One guardrail is nonnegotiable: Document what you changed and why. For example, “We use RICE with custom weights because a flat Reach score misrepresents our multi-segment market.”
A documented modification invites scrutiny. An undocumented one pretends to be objective. I go deeper into matching your operating model to your context in my guide to choosing a product team structure.
Sometimes, you run the diagnosis, audit every template, and find that nothing fits. Anyone can apply a framework. Knowing when to throw them all out is what you’re paid for.
Kill the reflex to ask, “What did the last company do?” or “What does the framework say?” Both answers are someone else’s context dressed up in your problem’s clothes.
At Brainly, “the user is the buyer” was the inherited lie. The load-bearing fact was that a 14-year-old user wasn’t the one entering the payment details. A parent was. Find the load-bearing facts, then build your reasoning from them. It’s slower, but sometimes it’s the only approach that works.
In complex domains, you discover the answer rather than reason your way to it, so make discovery cheap. On the adtech platform, we tested the higher ad load with two percent of its more than 100 million users for one week before rolling it out broadly.
One toggle gave us real data about complaints. The alternative was spending a quarter in meetings arguing about whether users would revolt.
That’s why skipping discovery and going straight to building backfires. The goal is to learn quickly and cheaply.
Before committing, run a pre-mortem. Assume it’s six months later and the decision has failed, then work backward out loud to identify why.
Those answers expose your risks. Turn them into kill criteria by defining two or three conditions that would cause you to walk away. Record the hypothesis, key assumptions, and kill criteria in a decision journal, then set a reminder to revisit them in four weeks.
Do this often enough, and you stop needing the framework because you’ve internalized what it was helping you do. Take estimation. After years of making the same kind of weekly estimate for one product, I could make a five-minute gut call that was accurate roughly 80 percent of the time because my judgment had been calibrated against what actually shipped.
This is also why story points break when you misapply them. The number means nothing until the team behind it is calibrated.
The framework is the easy part. The hard 80 percent is reading your messy context first. A sound diagnosis can make a mediocre framework useful. A bad diagnosis can lead the best framework on the internet to confidently rank your worst idea first in a clean spreadsheet.
Frameworks still have a place, but they can’t do the thinking for you. Read the context, make the judgment call, and use the tool to sharpen it.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Learn when streaks improve retention, when they create fragile engagement, and how PMs can design healthier systems around user progress.
A technical debt register brings transparency and clarity as to what type and how much debt you have and can be used to monitor and review your debt ratio.
Memos don’t have to be complicated. Just keep them clear, concise, and focused on actionable items. More on that in this blog.
Learn how tech PMs can take over inherited products, gather context, clean up backlogs, find quick wins, and make smarter decisions.
Learn more →
