Deciding what to kill
A roadmap is defined by what a product leader stops. Killing work needs a rule that the whole organisation can see, or it will not happen.
The problem
Starting an initiative is easy. A customer asks for something, a competitor ships something, or a leader has an idea. Each new initiative has a sponsor and a reason.
Stopping an initiative is hard. Nobody sponsors a cancellation. The team has already invested time. A customer may already have been told that the work is coming.
A product portfolio therefore grows in one direction. Every product line receives a little attention, and no product line receives enough. The strongest bets are staffed at the same level as the weakest ones.
I own a platform with five product lines. I have learned that this problem does not correct itself. A leader has to build the mechanism that corrects it.
What I built
I built a planning cadence, and it is the “prototype” for this idea.
We run one quarterly planning cycle for the whole portfolio. Every initiative is scored on the same six criteria.
| Criterion | The question it answers |
|---|---|
| User value | How much better does this make the user’s work? |
| Business impact | What does this change in revenue, retention or cost? |
| Feasibility | Can we build this with the team and the technology we have? |
| Risk | What can go wrong, and how badly? |
| Dependencies | What else has to happen first? |
| Time to value | How soon does a customer feel the benefit? |
An initiative that does not reach the value threshold is stopped. The rule applies to every initiative, whoever proposed it.
The largest decision from this process was the deprecation of a whole product line. We retired our MSP product line and concentrated R&D on the two highest-leverage bets. Operational cost fell by 20%.
I made a similar decision at a smaller scale earlier in my career. At Expertrons, a talent marketplace startup, I cut 50% of the roadmap so that the team could focus on monetization.
What I learned
A shared score removes the argument about people. A discussion without a common score becomes a contest between sponsors. A common score moves the discussion to the evidence. People accept a cancellation more easily when they can see how the decision was made.
The threshold matters more than the ranking. A ranked list invites the team to do everything on it, more slowly. A threshold creates a clear line. Work below the line stops, and its people move to work above the line.
Killing a product line is a customer conversation. The internal decision is the simpler half. Customers who use the product need a clear path and enough time. I plan that path before I announce the decision.
The savings are the smaller benefit. The 20% reduction in operational cost was real. The larger benefit was focus. The two strongest bets received the engineers and the attention that had been spread across five lines.
What this means for product teams
- Score everything the same way. Use one set of criteria for every initiative in the portfolio. Publish the scores inside the organisation.
- Set the threshold before you score. Agree on the bar first. A bar that is set after the scoring will bend to protect favourite projects.
- Review the portfolio on a fixed cadence. A quarterly review makes stopping work a normal event. People stop treating it as a failure.
- Defend the decision upward. The C-suite will hear from the sponsors of cancelled work. Bring the business case for the bets that you kept.