Rasp logo

Rasp

The Art of the Pivot: Knowing When to Kill Your Favorite Feature

•By Rasp Team

Every PM has a favorite feature.

The one you fought for in roadmap meetings. The one that took months to build. The one you know is brilliant — if only users would understand it.

Except they don't use it.

And you can't admit it's time to kill it.

This is the hardest part of product management: recognizing when attachment to your ideas is preventing progress.

The best PMs aren't the ones who build the most features. They're the ones who know what to kill — especially when it hurts.

Here's how to recognize when it's time to pivot, how to make the call, and how to do it without destroying team morale.

Why Killing Features Is So Hard

It's not just sunk cost fallacy (though that's part of it).

The psychological barriers:

1. Identity Investment

You pitched this feature. You fought for resources. You convinced stakeholders. Killing it feels like admitting you were wrong.

2. Optimism Bias

"Users just need more time to discover it."
"We haven't marketed it properly yet."
"The right customers haven't found it."

There's always a reason to wait.

3. Team Morale

Engineers spent weeks building this. Designers poured creativity into it. Killing it feels like saying their work was wasted.

4. Political Capital

You spent credibility getting this on the roadmap. Admitting it failed might damage your standing.

The result: Features limp along, consuming maintenance resources, cluttering the UI, and distracting from what actually works.

The Warning Signs: When a Feature Is Dying

These signals tell you it's time to reconsider.

Signal 1: Usage Is Dead (or Dying)

Look for:

  • Less than 5-10% of active users touch it
  • Usage declining month-over-month
  • New users ignore it completely
  • Power users abandoned it

The question: If so few people use it, why are we maintaining it?

Exception: If it's critical for a specific high-value segment, low overall usage might be acceptable.

Signal 2: It Creates More Problems Than It Solves

Look for:

  • High support ticket volume for this feature
  • Constant bug reports
  • Users confused about how it works
  • Requests to turn it off or hide it

The question: If this feature requires constant explanation and fixing, is it actually helping?

Signal 3: It Doesn't Move Key Metrics

Look for:

  • No correlation with activation, retention, or revenue
  • Users who use it churn at same rate as those who don't
  • No impact on expansion or upgrades
  • Doesn't show up in "most valuable features" surveys

The question: If it doesn't affect business outcomes, why does it exist?

Signal 4: It's Blocking Other Work

Look for:

  • Engineering complains about maintenance burden
  • Technical debt accumulating around it
  • Can't build new features because of this feature's architecture
  • Slows down other development

The question: What could we build if this wasn't consuming resources?

Signal 5: You've Moved On Strategically

Look for:

  • Feature made sense 2 years ago but not today
  • Target customer has shifted
  • Product positioning has evolved
  • Competitive landscape changed

The question: If we were starting today, would we build this?

The Feature Audit Framework

Run this analysis on any feature you're questioning.

Part 1: Usage Analysis

**Feature:** [Name]

**Users (Last 30 Days):**
- Total active users: [X]
- Users who touched this feature: [Y]
- Percentage: [Y/X]

**Trend:**
- 30 days ago: [Z%]
- 60 days ago: [W%]
- Direction: [Increasing/Flat/Declining]

**Segment Breakdown:**
- Enterprise: [%]
- SMB: [%]
- Free: [%]

**New vs. Existing:**
- New users (<30 days): [%]
- Existing users: [%]

Verdict: If <10% and declining, flag for removal.

Part 2: Impact Analysis

**Correlation with Success Metrics:**

Retention:
- Users who use this feature: [X-day retention %]
- Users who don't: [X-day retention %]
- Delta: [Difference]

Revenue:
- Mentioned in upgrade decisions: [Yes/No/Data]
- Mentioned in churn reasons: [Yes/No/Data]

Activation:
- Helps new users reach "aha moment": [Yes/No/Data]

Verdict: If no positive correlation, flag for removal.

Part 3: Cost Analysis

**Maintenance Burden:**

Support:
- Tickets per month: [X]
- % of total support volume: [Y%]

Engineering:
- Bug fixes per quarter: [X]
- Time spent on maintenance: [Y hours]
- Technical debt created: [High/Medium/Low]

Opportunity Cost:
- What could we build instead: [Feature ideas]
- Estimated impact of alternatives: [Data]

Verdict: If high cost with low impact, flag for removal.

Part 4: Strategic Fit

**Alignment Check:**

Current Strategy: [Description]

Does this feature support strategy?
- [ ] Yes, directly
- [ ] Somewhat
- [ ] No

Would we build this today?
- [ ] Yes
- [ ] Maybe
- [ ] No

Does this fit our ICP?
- [ ] Yes
- [ ] Partially
- [ ] No

Verdict: If it doesn't align, flag for removal.

The Kill/Keep/Evolve Decision Matrix

After running the audit, decide the fate.

Option 1: Kill It

When to choose:

  • Low usage + declining
  • No metric impact
  • High maintenance cost
  • Doesn't fit strategy
  • Nobody would miss it

How to do it:

  1. Announce deprecation timeline (30-90 days)
  2. Notify all users who've used it
  3. Offer alternatives if possible
  4. Remove from UI first, backend later
  5. Monitor complaints (there won't be many)

Option 2: Keep It (But Change Nothing)

When to choose:

  • Low usage BUT critical for high-value segment
  • Niche use case that's defensible
  • Low maintenance burden
  • Removing it risks churn

How to do it:

  • Move it out of primary UI
  • Put behind advanced settings
  • Stop actively promoting it
  • Maintain but don't enhance

Option 3: Evolve It

When to choose:

  • Core concept is right, execution is wrong
  • Usage is low but engagement is high
  • Solves real problem, just badly
  • Easy fixes could 10x value

How to do it:

  • Identify specific UX/functionality problems
  • Test improvements with small group
  • Relaunch with marketing push
  • Measure if improvements work

Warning: This is the dangerous option. It's easy to convince yourself something just needs "one more iteration." Be honest about whether evolution is likely to work.

The Pivot Decision Tree

When to pivot vs. persist?

Is usage declining?
├─ No → Keep monitoring
└─ Yes
    └─ Is there a clear reason why?
        ├─ Yes (e.g., poor UX, hard to find, not marketed)
        │   └─ Can we fix it in <1 sprint?
        │       ├─ Yes → Fix and measure
        │       └─ No → Consider killing
        └─ No (people just don't want it)
            └─ Does it affect business metrics?
                ├─ Yes → Investigate deeper
                └─ No → Kill it

The default should be kill.

Pivoting/evolving is the exception, not the rule.

How to Kill a Feature Without Destroying Morale

Your team built this. They care. Handle it carefully.

Step 1: Frame It as Learning, Not Failure

Bad framing:
"This feature failed, so we're removing it."

Good framing:
"We learned this doesn't solve the problem we thought it did. We're cutting it so we can focus on what actually works."

Why it works: Emphasizes learning and strategic focus, not failure.

Step 2: Share the Data

Don't just decree from on high. Show the team:

  • Usage numbers
  • Metric impact (or lack of)
  • Maintenance costs
  • Opportunity cost

Why it works: Data makes it less personal. It's not "your feature failed," it's "the data shows this isn't working."

Step 3: Celebrate the Attempt

Acknowledge:

  • The quality of execution
  • What you learned from building it
  • Skills developed
  • Customer insights gained

Why it works: People don't feel like their work was wasted.

Step 4: Redirect Energy

Immediately share:

  • What you're building instead
  • Why it's more impactful
  • How this makes room for better work

Why it works: Gives team something to get excited about.

Step 5: Take Responsibility

As PM, you own the decision to build it. Don't blame the team.

Say:
"I made the call to prioritize this, and the data shows I was wrong. Good news is we learned fast and we're pivoting."

Why it works: Shows leadership and prevents blame culture.

Real-World Examples of Successful Feature Kills

Example 1: Slack's IRC Gateway

What it was: Feature for IRC users to connect to Slack

Why it was killed:

  • <0.01% usage
  • High maintenance burden
  • Conflicted with product direction

How they did it:

  • 3-month deprecation notice
  • Offered alternatives
  • Clear communication

Outcome: Minimal backlash, resources freed for core features

Example 2: Twitter's Fleets

What it was: Stories-like disappearing posts

Why it was killed:

  • Low usage (users ignored it)
  • Didn't fit core use case
  • Cluttered interface

How they did it:

  • Removed after 8 months
  • Simple announcement
  • No replacement

Outcome: Users didn't care. Product felt cleaner.

Example 3: Google Reader

What it was: RSS feed reader

Why it was killed:

  • Declining usage
  • Didn't align with Google's strategy
  • Resource reallocation

How they did it:

  • Gave users time to export data
  • Recommended alternatives

Outcome: Loyal users angry, but business-wise correct decision

Lesson: Sometimes you upset a small vocal minority. That's okay if the data supports it.

The "Soft Kill" Strategy

If you're not ready for full removal, try these intermediate steps:

Step 1: Remove from Navigation

  • Hide from main menus
  • Bury in settings
  • Make it harder to discover

Measure: Does anyone complain? Does usage drop?

Step 2: Stop Onboarding New Users

  • Remove from tutorials
  • Don't mention in marketing
  • Existing users can still access

Measure: Do new users ask for it?

Step 3: Deprecate Integrations

  • Stop investing in connectors
  • Let third-party integrations lapse

Measure: Does anyone notice?

Step 4: Full Removal

If Steps 1-3 produce minimal backlash, fully remove.

Why this works: Gradual deprecation reduces shock and gathers data on actual impact.

When to Admit You Were Wrong Faster

The longer a bad feature lives, the more it costs.

Kill fast when:

1. No Usage After 60 Days

If a feature launches and no one uses it within 2 months, they never will.

Exception: Features that require network effects need longer.

2. Negative Feedback Dominates

If complaints outweigh praise 3:1, something's fundamentally wrong.

3. It's Blocking Critical Work

If technical debt from this feature prevents shipping something valuable, cut it.

4. Strategy Changed

If company direction shifted and this no longer fits, don't wait.

The rule: 6 months is too long to leave a dead feature alive.

The Feature That Should Have Been Killed But Wasn't

Every company has one.

Common types:

The Founder's Pet Project

  • Founder loves it
  • Nobody else uses it
  • Political suicide to remove

What to do: Show data. Frame as "let's pause this to focus on growth."

The "We Promised This" Feature

  • Sold to one big customer
  • They don't actually use it
  • Everyone's afraid to remove it

What to do: Talk to the customer. Often they won't care.

The "Too Much Work to Remove" Feature

  • So complex that removing it feels harder than keeping it
  • Creates technical debt by existing

What to do: Calculate true cost of maintaining vs. removing. Usually removal wins.

How to Prevent Building Features You'll Need to Kill

Better than killing features is not building them in the first place.

Prevention strategies:

1. Validate Before Building

  • Ship MVPs and prototypes
  • Test with small user groups
  • Require evidence of demand

2. Set Success Criteria Upfront

  • Define what "success" looks like
  • Set usage targets
  • Agree on kill criteria before building

Example: "If <20% of users adopt this in 90 days, we remove it."

3. Build Reversibly

  • Use feature flags
  • Separate from core architecture
  • Make it easy to remove

4. Time-Box Experiments

  • "We're trying this for 3 months"
  • Commit to reviewing data
  • Default to killing unless proven valuable

The Emotional Side of Killing Features

It's okay to feel bad about killing something you built.

Normal reactions:

  • Disappointment
  • Frustration
  • Embarrassment
  • Relief (eventually)

How to process it:

  1. Acknowledge the feeling: "This sucks. I really thought this would work."

  2. Separate ego from outcome: The feature didn't work. That doesn't mean you're bad at your job.

  3. Focus on learning: "What did I learn that makes me better?"

  4. Move forward: Don't dwell. Next feature awaits.

The truth: Every great PM has a graveyard of killed features. It's a sign you're taking risks and learning.

Final Thought

Your favorite feature might be killing your product.

Not because it's broken, but because it's distracting from what works.

The best products aren't defined by how much they do — but by what they choose not to do.

If you never kill features, you're not learning.

If you never pivot, you're not adapting.

The courage to kill what isn't working is what separates good PMs from great ones.

Start looking at your feature list.

What should you kill?