The Dirty Secret About Prioritization Frameworks: Most of Them Are Theater

Advocates: Gibson Biddle (VP Product, Netflix/Chegg)

Gibson Biddle comes from the other direction. His GEM framework (Growth, Engagement, Monetization) isn't about mathematical precision -- it's about giving teams a shared vocabulary for evaluating ideas. Does this delight customers? Is it hard to copy? Can it generate margin?

"We learned about Gibson's very popular product strategy and prioritization framework, and we go through a bunch of real life case studies from his time in Netflix to see how they apply in the real world."

Lenny Rachitsky

▶ 00:00:21

Netflix used this framework to evaluate everything from personalization algorithms to content investments. The framework didn't make decisions for them, but it made the conversation faster and the reasoning more transparent. When a PM at Netflix proposed a new feature, they didn't need to convince everyone from scratch that it mattered. They could map it to the shared framework: "This drives Engagement by improving the recommendation engine, which drives retention, which supports Growth."

The argument here is that frameworks don't replace judgment -- they structure it. Without a shared framework, every prioritization meeting devolves into competing intuitions with no common ground for resolution. The loudest voice wins, or worse, the most politically connected voice wins. A framework like GEM doesn't eliminate politics, but it forces everyone to argue on the same playing field.

The critical distinction is between frameworks used for scoring (RICE, ICE) and frameworks used for thinking (GEM, DRICE). Scoring frameworks try to make prioritization objective, which is a fool's errand -- the scores are only as good as the guesses that go into them. Thinking frameworks are more honest. They acknowledge that prioritization is subjective but provide a shared structure for making the subjective judgments more rigorous and communicable.

Advocates: Maggie Crowley (Product leader, Toast/Drift/Tripadvisor)

Maggie Crowley's contribution is the most practical and possibly the most overlooked: match the framework to the decision. Not every product decision needs a framework. Not every feature needs a strategy. If you're working on a well-scoped slice of a product and have direct user feedback, just do what makes sense.

"Every feature doesn't need a strategy for example, you don't need to do this if you're working on a tiny slice of a product and you have user feedback, don't overcomplicate it, just do the stuff that makes sense."

Maggie Crowleyon Lenny's Podcast (on when frameworks are overkill)

This sounds obvious, but the incentive structures in most product organizations push against it. PMs are trained to write PRDs, create prioritization matrices, and present roadmaps. Doing the obvious thing based on direct user feedback feels too simple to be legitimate. So PMs add process to justify what they already know, which slows everything down and satisfies nobody.

Frameworks become more valuable as ambiguity increases. A junior PM working on a specific feature with clear user research doesn't need RICE scoring -- they need permission to just ship the thing users are asking for. A VP deciding how to allocate resources across six product lines absolutely needs some structured approach, because the tradeoffs are genuinely complex and the stakeholders have competing interests. The mistake is applying senior-level processes to junior-level decisions, or vice versa.

Crowley's insight also applies to career development. Early in your PM career, frameworks are training wheels -- they teach you how to think about tradeoffs. As you gain experience, the frameworks become internalized and you don't need the explicit structure anymore. The best senior PMs have absorbed multiple frameworks and blend them unconsciously. The worst senior PMs have never graduated from the training wheels and still spend half their time scoring features on a spreadsheet.

Advocates: Sri Batchu (Growth, Ramp)

Sri Batchu's position adds a critical dimension: the framework matters less than what it connects to. At Ramp, engineers don't just own product metrics -- they feel ownership of the actual business pipeline. This changes how everyone prioritizes.

"What's unique to Ramp where the engineers feel ownership of the quota. They're not owning product metrics or what have you, they really do feel accountable for the pipeline driven and the efficiency driven by that team."

Sri Batchuon Lenny's Podcast (on how Ramp's prioritization connects engineering work to business outcomes)

When the whole team can see how their work translates to revenue, pipeline, or efficiency, prioritization becomes less about scoring features and more about chasing impact. The framework is just the connective tissue between work and outcomes.

This is fundamentally different from the typical product org where engineers build features, PMs track feature metrics, and someone in finance worries about revenue. At Ramp, the engineer building a new integration doesn't just know that it will "improve activation." They know exactly how many qualified leads it generates and how that compares to the leads from other projects. That visibility changes behavior. People naturally prioritize the highest-impact work when they can see the impact directly.

The implication for prioritization frameworks is stark: if your framework doesn't connect to business outcomes that everyone on the team can see and feel, it's theater. The most elegant RICE spreadsheet in the world doesn't matter if the "Impact" column is filled with guesses that never get validated. Ramp's approach works because the impact isn't estimated -- it's measured, in real time, by the people doing the work.