What Would Make You Change the Roadmap?

The request might be about keeping users engaged between sessions, reducing support load from missed status changes, or matching a competitor’s push alerts. Each reason changes what you’d build and how you’d judge the result. The feature request stays the same. The business case changes underneath it.

If support cost is the problem, an alert that customers open without needing less help has yet to earn its keep. If winning a particular contract depends on offering those alerts, the same implementation might meet its commercial purpose. Agreement on the feature can conceal disagreement about what success means.

In Writing an engineering strategy, Will Larson applies Richard Rumelt’s sequence of diagnosis, guiding policies, and coherent actions. The diagnosis describes the challenge; the policies make the tradeoffs; the actions follow. That order matters when a feature already has a delivery date but nobody has written down the belief behind it.

Give the Bet a Failure Condition

Follow the support-cost case. The hypothesis is that customers contact support because they can’t see information the business already has. Start by reading the actual support cases. Are customers asking for an available status, or asking someone to fix a late order? Faster alerts could help with the former. They could simply announce the latter sooner.

If the cases support the hypothesis, the business bet becomes specific: giving customers useful status information should reduce the support work an order creates. Define which orders the change is intended to help, then record the current support handling time per order in that group. Include canceled and unresolved orders; excluding them could improve the number simply by dropping difficult cases. Separately count status inquiries, so you can see whether the problem you meant to address changed.

Have the product and support owners agree what reduction would justify the development and continuing operating cost before the rollout. Be precise about the benefit. If the same team remains on the same payroll, fewer support minutes create capacity for other work without reducing that payroll bill. Clearing overdue cases or absorbing more orders may justify the investment, but the business case needs to name that use.

That reasoning also changes the technical investment. If the underlying order status is stale, a faster notification channel will deliver stale information faster. The necessary capability is trustworthy status data. If an existing email service can test whether that information helps, the test can precede a new notification platform.

Where volume and customer obligations allow, randomly assigning eligible customers to receive the alerts or continue with the existing service gives you a comparison. Measure support work for each group over the same observation window, long enough to include the follow-up an order generates. Keep cancellations and unresolved problems in view, too. Fewer support minutes would be a poor result if customers simply gave up.

An email trial also has a limit: it tests that message through that channel. If the intended customers never see the email, or see it after contacting support, an unchanged support load leaves the value of timely information unresolved. If they get accurate status information in time to use it and a credible comparison rules out the reduction you needed, a new delivery platform needs a different justification. A successful email trial could leave you with a reason to keep email.

Set the observation window and evidence threshold before reading the result; a flat dashboard alone cannot distinguish a weak idea from too little data. At low volume, examining individual cases can reveal misunderstandings, but a handful of encouraging responses cannot establish the size of the saving. Decide whether further observation could change the investment decision before extending the pilot.

The test has a cost of its own. If a small email change is inexpensive to operate, acceptable to the customers involved, and easy to reverse, trying it and watching for harm may be proportionate even without enough volume to measure savings reliably. Keep that benefit unproven in the plan. The larger commitment to a custom notification platform still needs its own case.

The roadmap can now change for a reason other than lateness. You might improve the status data, change the message, or stop expanding notifications. Each choice follows a different failure in the original reasoning. None requires pretending that shipping the first version settled the business case.

Stopping expansion and withdrawing a live feature are different decisions, too. For a feature already in use, weigh its continuing benefit against the costs still ahead, including maintenance and the disruption of withdrawal. An expensive build that failed to repay its original cost could still leave a useful service that’s cheap to keep.

Leave Room for Obligations

A compliance deadline needs a different treatment. If your legal lead has established that a requirement applies, making its implementation compete with an experiment on expected revenue obscures the decision. Record the requirement, the deadline, who confirms the necessary scope, and what evidence will demonstrate that you’ve met it.

Reserve the capacity before committing discretionary work. If the same engineers are needed for both, name which product commitment moves. The requirement may also support a strategic bet, such as serving a regulated customer, but its place in the plan doesn’t depend on the notifications pilot succeeding.

The same discipline applies to technical maintenance with a known consequence for deferral. Write down the dependency and the risk rather than disguising every necessary repair as a growth initiative. A framework that makes mandatory work disappear has made the roadmap less honest.

Make the Cut Survive the Meeting

Keep the reasoning in the planning document your team already uses. Link to the support analysis, cost estimates, and technical design instead of squeezing them into a one-page slogan. A short decision page can make the choices readable; it can also summarize a bad bet beautifully.

The uncomfortable paragraph is the list of work you’re explicitly declining, including the requests the loudest voices pushed for and didn’t win. Attach the reason and the name of the person accountable for the decision. The engineer receiving the next request should be able to point to that decision without having to negotiate it again.

Make a deferral precise. For the notifications example, you could defer a new push-delivery system while testing whether the existing channel gets useful status information to the customers whose questions create the support load. Evidence that those customers need the information sooner, or can’t be reached there, would reopen the delivery choice. It would still leave a comparison to make: fix the existing channel or build another one.

DORA’s guidance on team experimentation describes teams pursuing agreed business outcomes while being able to change specifications without outside permission. Applied here, that means the people approving the bet must also say which decisions the team can change. Changing an alert’s wording and withdrawing a contractual commitment carry different authority. Writing down the outcome alone grants neither.

Use the planning review you already have to ask what you’ve learned that changes a decision. The delivery update can show that notifications went out correctly; the support evidence addresses whether to keep investing. If the review changes the bet, update the dependent work and the written cuts. Otherwise, the rationale becomes an oral tradition maintained by whoever attended the last planning meeting.

If the evidence points to stale status data, the next plan could remove the push platform and fund the data repair instead. The teammate opening the backlog on Monday should find that choice and its owner there, without needing to have been in the room.