Product strategyPaymentsHigh stakesWorked as intendedFree to read
We killed a feature after six months of build. The reasoning held; the timing did not.
Adoption sat at 4% of target after two quarters. Four options on the table, three rejected. The decision to discontinue was defensible on the evidence available — the error was waiting two months longer than the criteria required.
The decision timeline
Three moments, kept separate. What became known later sits in its own column so it cannot be read back into the reasoning.
Known at the time
- 4% adoption against a 35% target, flat for three months
- 1.8 FTE sustained cost against 0.5 forecast
- Three accounts with the feature in a signed order form
- Six weeks to a planning deadline that locked allocation for a year
Decided, and why
- Discontinue, because no option on the table had a credible path to 35% within the planning horizon
- Wind down rather than cut off, because the contractual exposure was concrete and the support cost of a twelve-month tail was small
- Announce to accounts individually before any public note, to keep the escalation risk contained
Known later
- All three accounts renewed — the escalation risk was overestimated
- Two of the builders left within five months — the morale cost was underestimated
- The replacement work outperformed, which makes the decision look better than the reasoning deserves
Trust and provenance
What we checked, and what we did not.
✓Identity checked
The platform has checked the creator's identity. This does not establish that every claim is true.
✓Firsthand account
Creator was the decision-maker and answered editorial questions about their role and authority.
✓Evidence reviewed
Editor reviewed redacted usage charts and the internal decision memo. Customer names, contract values and the support export were not shared and were not verified.
✓Outcome followed up
Outcome update provided at nine months. Not independently corroborated.
iDisclosures
Creator holds vested equity in the company described.
The decision context
| Problem | A scheduled-payouts feature shipped to general availability in March. By September it was used by 4% of the accounts it was built for, against a 35% target set at kickoff. |
|---|---|
| Deadline | The annual planning cycle closed in six weeks. Keeping the feature meant committing two engineers to it for the following year. |
| Stakes | High |
| Decision-maker | VP Product, with sign-off from the CTO and the CEO. Three of the five customers who had requested the feature were on contracts up for renewal. |
Constraints
| Budget | No incremental headcount; keeping the feature meant taking two engineers off the reconciliation roadmap. |
|---|---|
| Time | Six weeks to the planning deadline; after that the allocation was locked for twelve months. |
| Information | No qualitative research with non-adopters. Usage telemetry only. |
| Authority | I could recommend, not decide alone. Two named enterprise customers had escalation rights. |
| External | One customer had the feature written into a signed order form. |
Alternatives
Options considered, and the stated reason each rejected option was rejected.
Continue at current investmentRejected
No hypothesis for why the next six months would differ from the last six.
Reduce scope and maintain in low-power modeRejected
Maintenance was not the cost; the cost was the roadmap slot and the support surface.
Reposition for a different segmentRejected
Plausible, but would have needed a discovery cycle we could not fund before the planning deadline.
Discontinue with a twelve-month wind-down for contracted accountsChosen
Honoured the signed commitment, released the roadmap slot, capped the support cost.
Evidence available at the time
Including the assumptions that were never tested and the things nobody knew.
Available data
- Weekly active usage by account, March to September
- Support ticket volume attributable to the feature (118 tickets, 7% of total)
- Engineering time logs: 1.8 FTE sustained post-launch, against 0.5 forecast
- Renewal risk notes from three account managers
Source types
Product telemetry · Support system export · Internal time tracking · Account manager interviews
Assumptions
- That low usage reflected low demand rather than poor discoverability — never tested
- That the two named customers would accept a wind-down rather than escalate
Unknowns
- Whether a redesigned onboarding flow would have moved adoption
- How much of the 4% was a single power user's automation
Reasoning
Decision criteria
- Evidence of customer demand beyond the original requesters
- Cost to move adoption, estimated honestly
- Strategic fit with the reconciliation roadmap
- Time to learn whether a fix would work
Trade-offs accepted
- Credibility with two enterprise accounts against twelve months of engineering capacity
- The sunk six months of build against the forward cost of keeping it
- A clean kill against the slower, safer option of repositioning
Risk tolerance
Low on contractual risk, high on reputational risk. We were willing to be the vendor that discontinued something, not the vendor that breached an order form.
Action taken
| Chosen | Discontinue, with a twelve-month wind-down for the three contracted accounts and a documented migration path. |
|---|---|
| Implemented | Announced internally first, then to the three accounts in individual calls before any public note. Engineering moved off within three weeks. The wind-down was scoped to bug fixes and security patches only, written down so it could not drift. |
Outcome
Measured over: Nine months post-decision, to August 2026
Results
- All three contracted accounts renewed. None cited the discontinuation.
- Support ticket volume fell 7% within two months and stayed down.
- The reconciliation work that took the roadmap slot reached 31% adoption in its first two quarters.
Unintended consequences
- Two engineers who had built the feature left within five months. Exit conversations referenced the kill, though neither named it as the only reason.
- A sales motion that had been using the feature as a differentiator had no replacement for a full quarter.
Reflection
| What changed | We now write the kill criteria into the launch document before build starts, with a named date and a named decision-maker. |
|---|---|
| What was learned | The analysis was not the hard part. The hard part was that nobody owned the question of when to ask it. Everyone assumed someone else was watching the number. |
| Would do differently | Run the decision in July, not September. The evidence was already sufficient by then — I waited for a quarter boundary that had no analytical meaning. I would also fund one week of non-adopter research before killing, not because I think it would have changed the decision, but because I still cannot rule it out. |
Transferability
The conditions under which this lesson applies — and the conditions under which it does not.
Applies when
- The feature has a contractual commitment attached to it
- The real cost is roadmap allocation, not maintenance
- You have usage telemetry but no qualitative research
Does not apply when
- The feature is load-bearing for a pricing tier or a compliance obligation
- Adoption is low because the feature is new — this one had two quarters
- You have capacity to run a genuine repositioning experiment
Rights and licensing
Published terms for this case.
| Consent | Creator confirms they have permission to publish this account in redacted form. |
|---|---|
| Licence | Non-exclusive, perpetual licence to publish and monetise. Creator retains copyright. |
| Anonymisation | Company and customer names redacted at creator's request. |
| Compensation | Eligible for the creator revenue pool under the published allocation rule. |
Think something here is wrong? Request a correction or takedown.
Related decisions
Matched on decision type, industry, stakes and shared tags.
PricingPayments
A 40% price rise with no grandfathering for existing customers
Grandfathering was the obvious kindness and the obvious mistake. We chose against it, lost more customers than the model predicted, and would make the same call.
RestructuringHealth tech
Cutting 12% of staff nine months before the runway required it
The model said we could wait two more quarters. We cut early anyway, on the argument that a smaller cut now beat a larger one later. That argument is harder to defend than it sounded in the room.
EngineeringSoftware / SaaS
Rewriting the billing system instead of patching it for another year
The estimate was five months. It took nine. Whether that counts as a failure depends entirely on what the patching path would have cost, and that number is unknowable.