The Hook: When You Have to Cut 30% of Your Roadmap

Your company is facing a downturn. Board says: "Cut costs 30%. That means less customer-facing work, more productivity gains." Your engineering team has $5M in roadmap planned. You need to cut $1.5M.

Your instinct: Cut the projects that feel least important. But then you realize: Everything on the roadmap felt important when it was added. Someone argued for each item.

So which 30% do you kill?

You're not choosing between "important" and "unimportant." You're choosing between things you wanted to build and things you have to build.

The Trap: Cutting Based on Qualitative "Importance" Rankings

The wrong approach: Rank all projects 1–50, then cut the bottom 15. But "importance" is subjective. You end up in meetings arguing "Is feature X more important than feature Y?" for hours.

It's emotionally brutal. And the ranking is arbitrary.

Better approach: Use a framework that separates "nice to have" from "must have," then cuts within nice-to-have category.

The Mental Model Shift: Ruthless Categorization Into Two Buckets

Here's the reframe: Some projects protect revenue or prevent crisis. Those stay. Everything else gets evaluated for removal.

Category	Definition	Decision
Must-have (protect revenue/health)	Churn prevention, security fixes, platform reliability, regulatory compliance	DO NOT CUT
Should-have (growth/improvement)	Revenue growth, engagement, competitive positioning	EVALUATE FOR CUTTING
Nice-to-have (optimization)	Technical debt, nice UX improvements, exploratory projects	CUT THESE FIRST

Most roadmaps are 60% nice-to-have, 30% should-have, 10% must-have. To cut 30%, you remove all nice-to-have and half of should-have.

This is much easier than ranking 50 projects.

Actionable Steps: Cutting Your Roadmap

1. Categorize Every Project Into the Three Buckets

For each project on your roadmap, answer:

If we don't do this, do we lose customers? → Must-have
If we don't do this, do we lose growth opportunity? → Should-have
If we don't do this, does anything bad actually happen? → Nice-to-have

Be ruthless. "It would be nice" projects that don't prevent revenue loss go to nice-to-have.

Action item: Spend 2 hours categorizing your roadmap. Get your entire leadership team to agree on categorization before discussing cuts.

2. Calculate the Cost Per Category

Must-have: $X
Should-have: $Y
Nice-to-have: $Z

If you need to cut 30% total budget and Z (nice-to-have) = 20% of your budget, then you default-cut all of Z. If you're still over budget, trim should-have.

The math forces objectivity. It's no longer subjective.

Action item: Build a simple spreadsheet: Project | Budget | Category | Total by Category. See which categories give you the 30% cut needed.

3. Sequence Cuts by Momentum and Dependency

Before you kill a project, check:

Is it already in progress? (Canceling mid-flight wastes the work done so far. Keep it if > 50% done.)
Do other projects depend on it? (If project B depends on project A, you can't cut project A without cutting project B too.)
Is the team demoralized by cutting it? (Avoid demoralizing cuts if possible.)

This prevents the cascading problem where cutting one project forces you to cut three others.

Action item: Map project dependencies. Identify which projects, if cut now, would prevent other projects from shipping. Weight your cuts accordingly.

4. Communicate the Cuts Clearly and Quickly

When you decide to cut, communicate:

What's being cut
Why (budget constraint, not "this doesn't matter")
What this means for the team (Can they be reassigned? Will there be layoffs? What's next?)
The timeline (When does this take effect?)

Clarity prevents morale death. Uncertainty is much worse than bad news.

Action item: Write a communication from leadership explaining the cuts. Share it company-wide. Avoid sugar-coating: "We're cutting 30% of roadmap because [reason]."

5. Protect What's Left

With 30% cut, the remaining 70% is now business-critical. Protect it:

Don't add to the roadmap. No new projects. You're already over-committed.
Reduce scope on current projects. If a project is 3 months to full scope, can you ship an MVP in 4 weeks instead?
Simplify estimates. Pad timelines more than usual (cuts make teams stressed, stressed teams are slower).
Review weekly. With so much cut, what's left is your company's survival path. Watch it obsessively.

Action item: For the projects that remain, commit to weekly progress reviews. If any are slipping, address immediately.

The PMSynapse Connection

When you're in a downturn and need to cut ruthlessly, it's critical to see: Which projects actually drive revenue retention? Which are defensive (prevent churn)? Which are pure growth plays? PMSynapse gives you that visibility. You're not guessing which projects matter most. You know.

Real-World Case Studies: Roadmap Cuts That Worked (And Failed)

Case Study 1: The Wrong Cut

A Series B fintech company faced a down-round. They needed to cut 30% of engineering costs. Their roadmap had:

Security audit refresh (must-have, security/compliance)
Payment processing improvement (should-have, ~5% revenue impact)
Mobile app redesign (nice-to-have, engagement)
API rate limit improvements (should-have, ~10% efficiency/scale impact)
Dashboard analytics (nice-to-have, but requested by 2 enterprise customers)

What they cut: Mobile redesign + Dashboard analytics = 35% of costs eliminated ✓

What they didn't cut: Security audit (team missed deadline, pushed to Q2)

What happened: In Q2, a security audit was mandated by their compliance officer (they were seeking enterprise customers). It was more expensive than the original Q1 timeline. They had to pay contractors $50K extra to meet deadline.

Net cost of the bad cut: The nice-to-have items they cut ($50K in engineering costs saved) were less expensive than the emergency security audit ($50K in emergency contractor costs). They cut the wrong things.

Lesson: Categorize ruthlessly. Don't cut must-have items just because they're lower cost.

Case Study 2: The Right Cut

A different fintech company faced the same down-round scenario. Same roadmap structure.

What they did first: Categorized everything

Must-have: Security audit + payment processing + API improvements = 65% of budget
Should-have: Mobile redesign = 20% of budget
Nice-to-have: Dashboard analytics = 15% of budget

To cut 30%, they needed to remove all of nice-to-have (15%) + half of should-have (10%).

They cut:

Dashboard analytics (nice-to-have): $100K
Mobile redesign scope reduction: $50K (planned 4-month redesign → 2-month MVP only)

Total cut: $150K = 30% ✓

What they kept: All must-haves + core should-haves

What happened:

Q2–Q3: Shipped security audit on time ✓
Q3: Shipped payment processing improvement (5% revenue lift) ✓
Q4: Shipped API improvements (10% efficiency gain) ✓
Q4: Shipped 2-month mobile MVP instead of full redesign (80% of the value in 50% of the time) ✓

Outcome: Despite cutting 30%, they shipped revenue-driving projects on time. No emergency expenses. Team morale held up because cuts were clearly explained as strategic, not chaotic.

Lesson: Categories make cuts objective. You cut from nice-to-have first, then trim should-have. Don't cut must-haves unless there's literally no other choice.

The Economics of Roadmap Cuts

Question: What happens if you cut a revenue-driving project?

Scenario: You have a project estimated to drive $200K in incremental ARR. Engineering cost: $150K. You're considering cutting it.

If you keep it:

Cost: $150K engineering
Benefit: $200K incremental ARR (recurring)
ROI: Year 1 = +$50K profit, Year 2+ = +$200K profit/year
Total 3-year value: $450K

If you cut it:

Cost saved: $150K
Benefit lost: $200K incremental ARR (recurring)
Opportunity cost: -$200K/year × 3 years = -$600K
Total 3-year value: -$450K (you lose more than you save)

The math is often counterintuitive: Cutting expensive projects that drive revenue is more expensive than keeping them.

Better framework:

Project 1: Costs $50K, drives $0 revenue (should-have) → Cut first
Project 2: Costs $150K, drives $200K revenue (should-have) → Keep if at all possible
Project 3: Costs $50K, prevents $100K churn (must-have) → Never cut

If you need to cut $100K, eliminate Project 1 first ($50K), then reduce scope on a should-have that's $50K (like going from full redesign to MVP).

Red Flags: How Companies Cut Wrong

Red Flag 1: "Cut based on project leader's influence"

New PM's projects get cut. Founder's projects survive. It's political, not strategic.

Fix: Use the category framework. Makes cuts objective, depersonalized.

Red Flag 2: "Cut after projects started"

Nothing wastes engineering time like canceling a project mid-way. If 3 months of work is already sunk, canceling it doesn't recoup that cost.

Fix: Before cutting, check project status. Projects that are 60%+ done should usually be finished—completion gains more value than the sunk cost.

Red Flag 3: "Cut without communicating dependencies"

You cut Project A (nice-to-have). But Project B (should-have) depends on it. Now Project B can't ship either. You cut 30% of nice-to-have but actually cut 40% of roadmap.

Fix: Map dependencies before cutting. Use a simple spreadsheet: Project | Dependencies | If this is cut, then [X] can't ship either.

Red Flag 4: "Cut and then re-add 3 months later"

You cut Project X. Stakeholders are upset. In Q2, you re-add it. Now your cuts were meaningless—you saved nothing and wasted time on the cut decision.

Fix: Commit to the cuts. If you're reconsidering within 6 months, you didn't evaluate properly the first time. Be more thoughtful the first time around.

The "Must-Have" vs. "Should-Have" Categorization: Deep Dive

How do you know if something is truly must-have?

Test 1: Would we lose customers if we don't do this?

Yes → Must-have
No → Should-have or nice-to-have

Test 2: Is there a hard deadline or dependency?

Regulatory deadline (Q2 compliance audit) → Must-have
Technical dependency (platform can't scale without this) → Must-have
Customer commitment (promised in contract) → Must-have
Nice-to-have deadline (wanted in Q3 but not required) → Nice-to-have

Test 3: What's the retention/revenue impact if we delay 6 months?

Major impact ($100K+ ARR lost) → Must-have
Medium impact ($10–100K) → Should-have (consider cutting or deferring)
Minor impact (< $10K) → Nice-to-have

Cutting Roadmap During Crisis vs. Normal Times

During a crisis (down-round, market downturn, cash emergency):

Cut 30% first. Ask questions later.
Rebuild roadmap from scratch. What's needed to survive?
Be ruthless. Nice-to-have projects disappear entirely.
Communicate fear, then clarity: "We're facing a challenge. Here's what we're focusing on."

During normal times (budget reallocation, strategic shift):

Cut 10–15%. Propose cuts, not impose them.
Consult stakeholders before cutting.
Offer clear reasoning: "We're shifting strategy toward [X], so [Y] moves to backlog."
Preserve team morale. Not every cut requires "we're in crisis" messaging.

The Cutting Playbook: Step-by-Step

Week 1: Categorization

PM + leadership team categorizes all roadmap items
Get alignment on must-have vs. should-have vs. nice-to-have
Calculate total spend in each category

Week 2: Target Identification

Math: Which categories need to be cut?
Identify projects to cut
Check dependencies and project status
Propose cuts to leadership

Week 3: Stakeholder Alignment

Present cuts with reasoning to affected teams
Answer questions: Why this project? When might it return?
Address concerns about dependencies

Week 4: Communication & Pivot

Announce cuts company-wide
Explain strategic rationale
Clarify what's next (what are the must-haves and should-haves that remain?)
Set roadmap expectations for the next 3 months

What to Do With Cut Projects

Option 1: Park Them (Backlog)

"We're cutting this. It might return when business conditions improve."

Pros: Team can get interested if conditions change
Cons: Project becomes a source of frustration ("Why was this cut?")

Option 2: Sunset Them (Remove Completely)

"We're cutting this. We're not going to do it."

Pros: Removes ambiguity. Team can move on mentally.
Cons: Less flexibility if strategic need arises

Option 3: Reduce Scope (Partial Cut)

"We're cutting this project from 4 months to 2 months MVP."

Pros: Get 70% of the value in 50% of the time
Cons: More complex communication (what got cut from scope?)

Recommendation: For nice-to-have projects, sunset them. For should-have projects, reduce scope or park them. Never sunset a must-have.

PMSynapse Connection (Updated)

When you need to cut ruthlessly, gut-feeling decisions lead to cutting the wrong things. PMSynapse shows you: Which projects actually drive revenue retention vs. growth? Which have the longest time-to-value (cut these if desperate)? Which have hard dependencies? You make data-informed cuts, not emotional ones. The result: You cut what should be cut, keep what shouldn't be, and maintain morale through clarity.

Real-World Case Studies: Roadmap Cuts That Worked (And Failed)

Case Study 1: The Wrong Cut

A Series B fintech company faced a down-round. They needed to cut 30% of engineering costs. Their roadmap had:

Security audit refresh (must-have, security/compliance)
Payment processing improvement (should-have, ~5% revenue impact)
Mobile app redesign (nice-to-have, engagement)
API rate limit improvements (should-have, ~10% efficiency/scale impact)
Dashboard analytics (nice-to-have, but requested by 2 enterprise customers)

What they cut: Mobile redesign + Dashboard analytics = 35% of costs eliminated ✓

What they didn't cut: Security audit (team missed deadline, pushed to Q2)

Lesson: Categorize ruthlessly. Don't cut must-have items just because they're lower cost.

Case Study 2: The Right Cut

A different fintech company faced the same down-round scenario. Same roadmap structure.

What they did first: Categorized everything

Must-have: Security audit + payment processing + API improvements = 65% of budget
Should-have: Mobile redesign = 20% of budget
Nice-to-have: Dashboard analytics = 15% of budget

To cut 30%, they needed to remove all of nice-to-have (15%) + half of should-have (10%).

They cut:

Dashboard analytics (nice-to-have): $100K
Mobile redesign scope reduction: $50K (planned 4-month redesign → 2-month MVP only)

Total cut: $150K = 30% ✓

What they kept: All must-haves + core should-haves

What happened:

Q2–Q3: Shipped security audit on time ✓
Q3: Shipped payment processing improvement (5% revenue lift) ✓
Q4: Shipped API improvements (10% efficiency gain) ✓
Q4: Shipped 2-month mobile MVP instead of full redesign (80% of the value in 50% of the time) ✓

Outcome: Despite cutting 30%, they shipped revenue-driving projects on time. No emergency expenses. Team morale held up because cuts were clearly explained as strategic, not chaotic.

Lesson: Categories make cuts objective. You cut from nice-to-have first, then trim should-have. Don't cut must-haves unless there's literally no other choice.

The Economics of Roadmap Cuts

Question: What happens if you cut a revenue-driving project?

Scenario: You have a project estimated to drive $200K in incremental ARR. Engineering cost: $150K. You're considering cutting it.

If you keep it:

Cost: $150K engineering
Benefit: $200K incremental ARR (recurring)
ROI: Year 1 = +$50K profit, Year 2+ = +$200K profit/year
Total 3-year value: $450K

If you cut it:

Cost saved: $150K
Benefit lost: $200K incremental ARR (recurring)
Opportunity cost: -$200K/year × 3 years = -$600K
Total 3-year value: -$450K (you lose more than you save)

The math is often counterintuitive: Cutting expensive projects that drive revenue is more expensive than keeping them.

Better framework:

Project 1: Costs $50K, drives $0 revenue (should-have) → Cut first
Project 2: Costs $150K, drives $200K revenue (should-have) → Keep if at all possible
Project 3: Costs $50K, prevents $100K churn (must-have) → Never cut

If you need to cut $100K, eliminate Project 1 first ($50K), then reduce scope on a should-have that's $50K (like going from full redesign to MVP).

Red Flags: How Companies Cut Wrong

Red Flag 1: "Cut based on project leader's influence"

New PM's projects get cut. Founder's projects survive. It's political, not strategic.

Fix: Use the category framework. Makes cuts objective, depersonalized.

Red Flag 2: "Cut after projects started"

Nothing wastes engineering time like canceling a project mid-way. If 3 months of work is already sunk, canceling it doesn't recoup that cost.

Fix: Before cutting, check project status. Projects that are 60%+ done should usually be finished—completion gains more value than the sunk cost.

Red Flag 3: "Cut without communicating dependencies"

You cut Project A (nice-to-have). But Project B (should-have) depends on it. Now Project B can't ship either. You cut 30% of nice-to-have but actually cut 40% of roadmap.

Fix: Map dependencies before cutting. Use a simple spreadsheet: Project | Dependencies | If this is cut, then [X] can't ship either.

Red Flag 4: "Cut and then re-add 3 months later"

You cut Project X. Stakeholders are upset. In Q2, you re-add it. Now your cuts were meaningless—you saved nothing and wasted time on the cut decision.

Fix: Commit to the cuts. If you're reconsidering within 6 months, you didn't evaluate properly the first time. Be more thoughtful the first time around.

The "Must-Have" vs. "Should-Have" Categorization: Deep Dive

How do you know if something is truly must-have?

Test 1: Would we lose customers if we don't do this?

Yes → Must-have
No → Should-have or nice-to-have

Test 2: Is there a hard deadline or dependency?

Regulatory deadline (Q2 compliance audit) → Must-have
Technical dependency (platform can't scale without this) → Must-have
Customer commitment (promised in contract) → Must-have
Nice-to-have deadline (wanted in Q3 but not required) → Nice-to-have

Test 3: What's the retention/revenue impact if we delay 6 months?

Major impact ($100K+ ARR lost) → Must-have
Medium impact ($10–100K) → Should-have (consider cutting or deferring)
Minor impact (< $10K) → Nice-to-have

Cutting Roadmap During Crisis vs. Normal Times

During a crisis (down-round, market downturn, cash emergency):

Cut 30% first. Ask questions later.
Rebuild roadmap from scratch. What's needed to survive?
Be ruthless. Nice-to-have projects disappear entirely.
Communicate fear, then clarity: "We're facing a challenge. Here's what we're focusing on."

During normal times (budget reallocation, strategic shift):

Cut 10–15%. Propose cuts, not impose them.
Consult stakeholders before cutting.
Offer clear reasoning: "We're shifting strategy toward [X], so [Y] moves to backlog."
Preserve team morale. Not every cut requires "we're in crisis" messaging.

The Cutting Playbook: Step-by-Step

Week 1: Categorization

PM + leadership team categorizes all roadmap items
Get alignment on must-have vs. should-have vs. nice-to-have
Calculate total spend in each category

Week 2: Target Identification

Math: Which categories need to be cut?
Identify projects to cut
Check dependencies and project status
Propose cuts to leadership

Week 3: Stakeholder Alignment

Present cuts with reasoning to affected teams
Answer questions: Why this project? When might it return?
Address concerns about dependencies

Week 4: Communication & Pivot

Announce cuts company-wide
Explain strategic rationale
Clarify what's next (what are the must-haves and should-haves that remain?)
Set roadmap expectations for the next 3 months

What to Do With Cut Projects

Option 1: Park Them (Backlog)

"We're cutting this. It might return when business conditions improve."

Pros: Team can get interested if conditions change
Cons: Project becomes a source of frustration ("Why was this cut?")

Option 2: Sunset Them (Remove Completely)

"We're cutting this. We're not going to do it."

Pros: Removes ambiguity. Team can move on mentally.
Cons: Less flexibility if strategic need arises

Option 3: Reduce Scope (Partial Cut)

"We're cutting this project from 4 months to 2 months MVP."

Pros: Get 70% of the value in 50% of the time
Cons: More complex communication (what got cut from scope?)

Recommendation: For nice-to-have projects, sunset them. For should-have projects, reduce scope or park them. Never sunset a must-have.

PMSynapse Connection (Updated)

Key Takeaways

Categorize projects into must-have, should-have, nice-to-have first. This makes cutting objective. You're not ranking 50 subjective priorities; you're cutting from the nice-to-have and trimming should-have.
Calculate the cost per category. Math removes emotion. If must-have + should-have costs 70% of your budget, that's what you keep. Nice-to-have gets cut.
Check dependencies before cutting. Cutting project A might force you to cut project B. Map dependencies to avoid cascading cuts.
Communicate cuts quickly and clearly. Uncertainty is demoralizing. Quick, clear communication is better than consultative ambiguity.
Protect what remains. With 30% cut, the remaining 70% is your survival roadmap. Don't add to it. Focus on shipping and execution.

Cutting 30% of Your Roadmap: A Framework for Strategic Pruning

Article Type

SPOKE Article — Links back to pillar: /product-prioritization-frameworks-guide

Target Word Count

2,500–3,500 words

Writing Guidance

Reference Marcus persona scenario: 'Needs to cut 30% of the roadmap; doesn't know which bets to kill.' Provide a systematic framework for pruning: OKR alignment, strategic fit, political cost, technical dependency, and reversibility. Soft-pitch: PMSynapse's Portfolio Optimizer runs impact analysis using OKRs, stakeholder priorities, and technical risk scores.

Required Structure

1. The Hook (Empathy & Pain)

Open with an extremely relatable, specific scenario from PM life that connects to this topic. Use one of the PRD personas (Priya the Junior PM, Marcus the Mid-Level PM, Anika the VP of Product, or Raj the Freelance PM) where appropriate.

2. The Trap (Why Standard Advice Fails)

Explain why generic advice or common frameworks don't address the real complexity of this problem. Be specific about what breaks down in practice.

3. The Mental Model Shift

Introduce a new framework, perspective, or reframe that changes how the reader thinks about this topic. This should be genuinely insightful, not recycled advice.

4. Actionable Steps (3-5)

Provide concrete actions the reader can take tomorrow morning. Each step should be specific enough to execute without further research.

5. The Prodinja Angle (Soft-Pitch)

Conclude with how PMSynapse's autonomous PM Shadow capability connects to this topic. Keep it natural — no hard sell.

6. Key Takeaways

3-5 bullet points summarizing the article's core insights.

Internal Linking Requirements

Link to parent pillar: /blog/product-prioritization-frameworks-guide
Link to 3-5 related spoke articles within the same pillar cluster
Link to at least 1 article from a different pillar cluster for cross-pollination

SEO Checklist

Primary keyword appears in H1, first paragraph, and at least 2 H2s
Meta title under 60 characters
Meta description under 155 characters and includes primary keyword
At least 3 external citations/references
All images have descriptive alt text
Table or framework visual included