Prioritization Frameworks That Actually Work

A working PM's guide to RICE, ICE, DRICE, GEM — and when to just keep it simple.

Every new PM, at some point, gets handed a prioritization framework. RICE. ICE. MoSCoW. Kano. Weighted Shortest Job First. The org rolls it out at an offsite, someone builds a spreadsheet, everyone uses it enthusiastically for six weeks, and then it quietly dies.

The frameworks aren't the problem. The way we reach for them is the problem. Lenny's archive is instructive here because it contains both the sophisticated frameworks (DRICE, GEM, GIST) and Lenny's own advice, which is essentially: in most cases, don't overthink this.

Let me walk through both sides, because you'll need both at a big company.

Lenny's default: keep it embarrassingly simple

Asked "How do you prioritize your roadmap?" in his newsletter, Lenny's answer is almost contrarian:

Judging by the sea of SEO thirst-trap blog posts about prioritization, you aren't a PM blogger (or PM SaaS tool) if you haven't shared your perspective on prioritization. So here's my advice: In most situations, ignore most of these frameworks and just keep it simple.

His three-step version:

1. Make a single list of all your team's ideas.
2. T-shirt-size (XS, S, M, L, XL) each idea on two dimensions: estimated impact and estimated cost.
3. Sort the list based on the highest ratio of impact-to-cost.

That's it. Two dimensions, T-shirt sizes, a sorted list.

Why T-shirts and not numbers? Because numbers invite the illusion of precision. "This is a 4.2" and "this is a 3.8" are not meaningfully different — but a framework that produces numbers to one decimal place feels scientific, and that false confidence is the thing that gets you in trouble. T-shirts force you to manually sort, which is exactly the work you're trying to do.

Lenny's own words: "I've tried so many frameworks over the years, constantly hoping to make the process less subjective. But again and again, I've found that there's no way to avoid the messiness of people, opinions, and unknowns. Instead, I embrace the messiness and keep the process simple and people-focused."

That's the right default for a new PM, especially at a big company where you'll otherwise get sucked into framework-maintenance overhead instead of talking to customers.

RICE: when you need more rigor

When you graduate beyond T-shirts, RICE is usually the next stop. RICE, popularized by Intercom, scores each idea on four factors:

• Reach — how many customers will experience this
• Impact — if it pans out, how much does it move the metric
• Confidence — how likely is it to actually work
• Effort — how much time it would take

Multiply reach × impact × confidence, divide by effort, sort the list. Done.

RICE is useful because of what it explicitly accounts for: confidence. Most naive prioritization treats a 50% bet and a 95% bet the same. RICE discounts the 50% bet, which means speculative ideas don't crowd out grounded ones. That's a real improvement over "impact ÷ effort."

At a big company, RICE also gives you a defensible vocabulary in cross-functional meetings. When a senior stakeholder pushes a low-reach, low-confidence idea, you can walk through the RICE scores out loud. It doesn't always win — but it reframes the argument from "whose instinct is right" to "here's the math, what inputs would you change?"

DRICE: for mature growth teams

Darius Contractor and Alexey Komissarouk, whose combined 35+ years came out of Dropbox, Facebook, Airtable, Opendoor, and MasterClass, wrote up a variant they call DRICE (Detailed RICE) for Lenny's. Their claim: when they moved from regular RICE to DRICE, their team's impact rate doubled.

The idea is that RICE works well for rough prioritization of a big list (5x as many ideas as you could build in a quarter), but once you've narrowed down to the top candidates, you should re-score them with much more detailed inputs — real traffic numbers, specific conversion assumptions, honest engineering estimates. DRICE is the "second pass" framework.

For a new PM, the takeaway isn't necessarily to adopt DRICE wholesale. It's this: prioritization isn't one pass, it's two. A cheap scan across everything to find the top 5–10 bets, then a careful scoring of those bets with real inputs. Most teams do the first pass and skip the second, which is why so much "prioritized" work turns out to have been based on numbers somebody made up in a meeting.

ICE: when you need speed over rigor

ICE is the older, scrappier cousin of RICE, coined by Sean Ellis (the "original growth hacker," in Lenny's phrasing). It drops Reach and keeps three factors:

• Impact
• Confidence
• Ease (inverse of effort)

ICE is built for experimentation-heavy teams that are running many small tests. Reach is often constant (everyone in the experiment sees the change), so collapsing it simplifies the math. If you're running growth experiments weekly, ICE is probably right. If you're prioritizing a multi-quarter roadmap, RICE is probably right.

GEM: when you have competing strategic lenses

Gibson Biddle, former VP of Product at Netflix, introduced GEM as a roadmap prioritization framework: score each idea on how much it drives Growth, Engagement, and Monetization. GEM isn't a replacement for RICE — it's a different axis. RICE asks "how valuable is this?" GEM asks "which strategic goal does this serve?"

For a PM at a big, multi-product company, GEM is useful because it forces explicit portfolio thinking. If your entire roadmap skews to one letter — say, Monetization — you'll see it immediately. That's the sort of pattern that's invisible in a flat RICE-sorted list but obvious when you tag ideas by G/E/M.

A simple playbook for a new PM

Here's how I'd actually use all of this on a real roadmap:

1. Start with Lenny's default. A single list. T-shirt impact. T-shirt cost. Sorted. You can do this in an afternoon.
2. Upgrade to RICE for the top quartile. Only the things that might actually make it onto the roadmap need real scoring. Don't RICE-score 200 ideas — RICE-score 20.
3. Run DRICE on the final 5. For the handful of things you're genuinely committing to next quarter, get detailed. Real reach numbers from analytics. Real impact assumptions you can defend. Real engineering estimates (plural estimates, from more than one person).
4. Tag everything with GEM (or your org's strategic pillars). Not to score, just to see distribution. If your top 5 are all one pillar, something is wrong with either your roadmap or your pillar definitions.
5. Share the scores in the open. The framework is a conversation tool, not an oracle. Publish the numbers to your team and invite pushback. You want the argument to be about the inputs, not about whether the output is trustworthy.

The real point

Every framework in this article is wrong in some specific way. None of them handle dependencies well. None of them account for strategic timing (launch the marketing tie-in before the conference, not after). None of them capture team energy or morale or the fact that one engineer desperately needs a win this quarter.

The frameworks are crutches. What you're really doing is having a structured conversation with your team and your stakeholders about what to build next. The best framework for a new PM is the one that makes that conversation sharper — not the one that lets you avoid having it.

← Back to Roadmapping