Essential Product Frameworks

Frameworks Are Tools, Not Religion

Product frameworks are mental models that help you structure decisions. They're not magic formulas that spit out correct answers. The best PMs know a dozen frameworks but use them selectively, adapting to context rather than following them dogmatically.

Here's the uncomfortable truth: no framework will tell you what to build.

They help you compare options, communicate decisions, and avoid obvious biases. But the hard work—understanding users, having vision, making judgment calls—that's still on you. Anyone who tells you otherwise is selling something.

---

RICE: When You Need to Compare Apples and Oranges

RICE stands for:

• Reach — how many users affected
• Impact — how much it helps each (scored 0.25 to 3)
• Confidence — percentage, how sure you are
• Effort — person-weeks

You multiply Reach × Impact × Confidence and divide by Effort. The result is a score you can compare across projects.

Intercom invented RICE and it works well for feature prioritization at scale. Use it when you have a backlog of 20+ items and need to defend decisions to stakeholders. The Confidence score is its secret weapon—it forces you to acknowledge when you're guessing.

When RICE Breaks Down

RICE fails when comparing transformational bets (new product lines) against incremental features. A 10x opportunity might score lower than a safe optimization because Confidence is low. Don't let the framework override strategic thinking.

---

ICE: Quick and Dirty Prioritization

ICE (Impact, Confidence, Ease) is RICE's simpler cousin. Score each dimension 1-10, multiply them together, stack rank. It takes five minutes instead of an hour. Use it for:

• Early-stage ideation
• Hackathon planning
• When you don't have good reach data

The weakness is subjectivity. Two people might score the same feature wildly differently. ICE works best as a conversation starter—"I scored this a 9 on Impact, you said 4, let's discuss"—rather than a final arbiter.

---

MoSCoW: Scope Management Under Pressure

MoSCoW categorizes requirements into:

It's best for fixed-deadline projects where you need to define a minimum viable scope and make tradeoffs visible.

The power of MoSCoW is forcing tough conversations early. Getting stakeholders to agree that something is "Won't have" before development starts is much easier than cutting it later. Use it in kickoffs and when negotiating with deadline-driven business teams.

Be ruthless with the "Must have" bucket. If everything is a must-have, nothing is. Spotify uses a rule of thumb: only 60% of planned scope should be Must have, leaving room for things to go wrong.

---

Jobs to Be Done: Understanding Why People Buy

JTBD flips the script from "what features does our product have" to "what job is the customer trying to accomplish." The classic example: people don't buy a quarter-inch drill because they want a drill. They want a quarter-inch hole. Maybe they actually want a picture hung on their wall.

The framework pushes you to understand the progress customers are trying to make in their lives.

The Milkshake Example

Milkshakes, Clay Christensen's famous example, were "hired" for the morning commute job—something to make a boring drive more interesting and keep you full until lunch. Competitors weren't other milkshakes; they were bananas, bagels, and boredom.

Use JTBD when:

• Designing new products
• Entering new markets
• When you're stuck on features and losing sight of the user's actual goal

It's qualitative and strategic, not a scoring system.

---

Double Diamond: Structure for Ambiguous Problems

The Double Diamond, from the British Design Council, visualizes the design process as two phases:

1. First Diamond: Discover and define the right problem

   • Diverge: explore widely
   • Converge: focus narrowly

2. Second Diamond: Develop and deliver the right solution

   • Diverge: explore solutions
   • Converge: ship the best one

It's a process framework, not a prioritization tool. Use it to structure product discovery when you don't know what to build yet. The first diamond prevents you from jumping to solutions; the second prevents you from shipping the first thing you designed.

Real-World Example

Notion used this approach when expanding beyond notes. They diverged widely (what adjacent problems do users have?), converged on databases as the opportunity, then diverged on solutions before converging on their flexible block-based approach.

---

Kano Model: Delighters vs. Table Stakes

The Kano model categorizes features by how they affect satisfaction:

Use Kano when deciding where to invest. If you're missing basic needs, fix those first—no amount of delighters compensate for a broken core. But once basics are covered, delighters differentiate you from competitors.

Airbnb's photography program was a delighter that became table stakes for the industry.

---

When to Ignore Frameworks Entirely

Frameworks fail when you have asymmetric information. If you know something the framework can't capture—a strategic partnership about to close, a founder's strong conviction, a regulatory change coming—trust your judgment over the score.

They also fail for truly novel products. When Amazon built AWS, no framework would have scored "sell compute to other companies" highly. Bezos had conviction from customer conversations and internal needs. Sometimes you just have to believe.

The best PMs develop intuition that often disagrees with framework outputs. If your gut says a feature matters more than its RICE score, investigate why. Either you're missing something in the score, or you've spotted something the framework can't capture.

---

Building Your Framework Toolkit

Start with these, layered by use case:

• RICE or ICE — for weekly prioritization
• MoSCoW — when planning fixed releases
• JTBD — when you're stuck or designing something new
• Double Diamond — for major discovery efforts
• Kano — when thinking about competitive positioning

Document your framework usage in your portfolio. It shows hiring managers you can think systematically while maintaining judgment. But never let them see you as someone who hides behind frameworks instead of making decisions.