🎯 The Low-Impact Death Spiral: How Product Teams Can Avoid Layoffs by Becoming Impact-First

Product managers and teams are getting laid off at unprecedented rates. According to Spotify CEO Daniel Ek, the core problem is clear: "We still have too many people doing work around the work" instead of driving real business impact.

Matt LeMay, longtime product leader and author of "Product Management in Practice," has identified the root cause: the Low-Impact Death Spiral. This insidious pattern starts with small, seemingly safe features that gradually increase complexity without delivering meaningful business results—until the next round of layoffs hits.

In a recent interview on Lenny's Podcast, Matt shared his three-step framework for becoming "impact-first" and introduced the CEO question that changes everything about how product teams think about their work.

🎥 Watch the full episode here

📆 Published: 14 August 2024

🕒 Estimated Reading Time: 4 mins. Time saved: 95 mins! 🔥

🤔 The CEO Question That Changes Everything

Before diving into frameworks, Matt poses a critical question every product manager should ask themselves: "If you were the CEO of this company, would you fully fund your own team?"

"Frankly, most of the people I ask that question to don't know the answer right away," he observes. This hesitation reveals a fundamental disconnect between what product teams think they're delivering and what the business actually needs.

The harsh reality? Companies won't keep writing paycheques for two years just because your OKRs hit 0.6 or 0.7. You need to demonstrate clear, measurable business impact—or risk becoming expendable.

Key Takeaways:

• Ask yourself the CEO question honestly - would you fund your own team?

• OKR scores don't guarantee job security - business impact does

• Most product managers can't immediately answer this question - that's the problem

🌀 Understanding the Low-Impact Death Spiral

The Low-Impact Death Spiral follows a predictable pattern that Matt has observed across countless product teams:

Stage 1: Small, Safe Features
Teams focus on low-risk improvements—minor UI tweaks, small feature additions, cosmetic changes that feel productive but don't move business metrics.

Stage 2: Accumulating Complexity
Like rhinestones weighing down a car, these small features accumulate technical debt and operational overhead without proportional value creation.

Stage 3: Resource Drain
The team becomes increasingly busy maintaining and supporting low-impact features whilst struggling to deliver meaningful business results.

Stage 4: Layoffs
When budget cuts come, leadership can't justify keeping teams that haven't demonstrated clear business value, regardless of how busy they've been.

Matt shares a telling example: "I worked with a product manager who broke out of this cycle by focusing on one clear, impactful goal instead of juggling multiple small improvements. The difference in business results was dramatic."

Key Takeaways:

• Small, safe features accumulate into big problems over time

• Being busy doesn't equal being valuable to the business

• Focus beats fragmentation - one impactful goal trumps multiple small improvements

📈 Step 1: Set Team Goals No More Than One Step Away From Company Goals

The first step in becoming impact-first is ruthlessly aligning your team's work with business outcomes. Most product teams set goals that are two, three, or even four steps removed from actual business results.

The Problem: Teams optimise for engagement metrics, feature adoption rates, or user satisfaction scores without connecting these to revenue, retention, or other business-critical metrics.

The Solution: Ensure your team's primary goals directly ladder up to company-level objectives. If your company's goal is to increase annual recurring revenue by 20%, your team's goal should be something like "increase revenue from existing customers by £2M through improved retention" rather than "improve user engagement scores by 15%."

Key Questions to Ask:

• How does our team's success directly contribute to the company's financial health?

• Can we draw a straight line from our metrics to business outcomes?

• Would the CEO immediately understand why our goals matter?

Key Takeaways:

• Align team goals directly with company objectives - no more than one step away

• Engagement metrics don't equal business impact without clear connection

• The CEO should immediately understand why your goals matter

🎯 Step 2: Keep Impact First at Every Step

The second principle requires continuous vigilance against the drift toward easier, lower-impact work. Teams often start with good intentions but gradually move toward less challenging tasks when faced with complexity or external dependencies.

The Solution: Continuously ask "What's the business impact?" at every decision point. When choosing between features, prioritise based on potential business value, not ease of implementation or stakeholder preferences.

Practical Application:

• Before every sprint planning session, review how planned work connects to business goals

• When stakeholders request features, ask them to articulate the expected business impact

• Regularly audit your backlog to eliminate or deprioritise low-impact items

Matt emphasises the accountability aspect: "You're accountable for business outcomes, regardless of external factors." Even if leadership asks for a feature that seems important but lacks clear business impact, you're still responsible for the results.

Key Takeaways:

• Ask "What's the business impact?" at every decision point

• Prioritise based on business value, not ease of implementation

• You're accountable for outcomes regardless of who requested the work

🔗 Step 3: Connect Every Bit of Work Back to Impact

The third step involves developing the discipline to articulate how every piece of work—including maintenance and technical improvements—ultimately serves business objectives.

The Challenge: Even well-intentioned teams can lose sight of impact when dealing with technical debt, bug fixes, or operational tasks that don't obviously connect to business metrics.

The Solution: Create clear narratives that connect all work to business outcomes:

• "We're fixing this bug because it's causing 15% of new users to abandon the onboarding flow, directly impacting our customer acquisition goals"

• "This technical debt cleanup will reduce our deployment time by 50%, allowing us to ship revenue-generating features faster"

• "Improving this internal tool will save our customer success team 10 hours per week, allowing them to focus on expansion opportunities"

Key Takeaways:

• Every piece of work should connect to business impact - including technical debt

• Create clear narratives linking maintenance work to business outcomes

• Internal efficiency improvements should translate to customer or revenue benefits

🏢 The Mini-CEO Mindset: What Businesses Expect From Product Managers

Matt clarifies a crucial misconception about the "product manager as mini-CEO" concept. It's not about individual product managers acting like CEOs—it's about the entire product team thinking like a CEO would about their area of the business.

This means understanding:

Your Company's Funding Model

• How does the company make money?

• What are the key revenue drivers and cost centres?

• How do investor expectations shape business priorities?

Your Business Context

• What regulatory constraints affect product decisions?

• How do sales cycles and customer acquisition costs impact feature prioritisation?

• What competitive pressures require immediate attention versus long-term investment?

Your Team's ROI

• What would it cost to replace your team's output with external resources?

• How much revenue or cost savings does your team generate?

• What happens to business metrics when your team's velocity decreases?

Key Takeaways:

• The whole team needs CEO-level business understanding, not just the PM

• Understand your company's funding model and revenue drivers

• Know your team's ROI and replacement cost

💪 Breaking Free: The Courage to Push Back

One of the most challenging aspects of becoming impact-first is developing the courage to push back on low-impact requests, even when they come from executives.

The Accountability Reality: As Matt emphasises, "You're accountable for business outcomes, regardless of external factors." Even if leadership asks for a feature that seems important but lacks clear business impact, you're still responsible for the results.

Strategies for Pushback:

1. Lead with Business Context: Instead of saying "That won't work," try "Here's what I understand about our business priorities, and here's how this request fits (or doesn't fit) with those priorities."

2. Propose Alternatives: "I understand why this feels important. Here's an alternative approach that could address the same underlying need whilst driving clearer business impact."

3. Request Impact Clarification: "Help me understand the expected business impact of this feature. What metrics should we expect to see move, and by how much?"

4. Document Decisions: Keep a record of requests, your analysis, and the business rationale for your recommendations.

Key Takeaways:

• You're accountable for outcomes even when executives request low-impact features

• Lead pushback conversations with business context, not technical objections

• Always propose alternatives that address underlying needs with better impact

🚫 Common Pitfalls: What Teams Focus on Instead of Impact

Matt identifies several common distractions that pull teams away from impact-first thinking:

Best Practices Obsession
Teams become fixated on following industry best practices—agile ceremonies, OKR frameworks, user research methodologies—without connecting these practices to business outcomes.

Intermediate Metrics Fixation
Focusing on engagement rates, feature adoption, or user satisfaction scores without understanding how these connect to business results.

Feature Factory Mentality
Measuring success by output (features shipped, story points completed) rather than outcomes (business metrics improved).

Stakeholder Appeasement
Prioritising requests based on who's asking rather than potential business impact.

Matt's advice is direct: "Best practices are usually most common practices. The best practice is an expert taking what matters out of that and applying it for this situation."

Key Takeaways:

• Best practices without business context become meaningless rituals

• Intermediate metrics only matter if they connect to business outcomes

• Measure outcomes (business impact) not outputs (features shipped)

🎯 Getting Started This Week

Matt's framework offers a practical path forward, but frameworks are only as good as their application. Here's how to begin implementing impact-first thinking immediately:

Week 1: Assessment

• Answer Matt's CEO question honestly: Would you fully fund your own team?

• Audit your current goals and metrics—how many steps removed are they from business outcomes?

• Review your last quarter's work and categorise it as high-impact, medium-impact, or low-impact

Week 2: Realignment

• Meet with leadership to understand current business priorities and constraints

• Rewrite your team's goals to be no more than one step away from company goals

• Create a simple framework for evaluating feature requests based on business impact

Week 3: Communication

• Present your impact-first approach to stakeholders and leadership

• Start requiring business impact justification for all new feature requests

• Begin regular reporting on business metrics, not just product metrics

Key Takeaways:

• Start with honest assessment - most teams will find gaps in business alignment

• Rewrite goals to be directly connected to company objectives

• Require business impact justification for all new work

That intersection is where the most impactful product work happens. It's messy, complex, and often frustrating. But it's also where product teams can create the most value—for users, for businesses, and for their own careers. The Low-Impact Death Spiral isn't inevitable, but avoiding it requires the courage to prioritise impact over activity.