Forty-One Features, Nine That Anyone Uses

Treat the usage data as evidence and let it reorder the backlog, rather than treating the backlog as a contract.

The portfolio is not delivering value: 19 of 41 features reach under 2% of customers. That is not a prioritisation problem to be fixed next quarter, it is the current cost of building on opinion. Two immediate consequences:

• Prune and separate. Split the 220 items into three buckets: contractual/regulatory obligations (non-negotiable, ranked by date), items with an evidenced customer or revenue hypothesis, and unvalidated director requests. The third bucket does not get built until it produces evidence.
• Slice the large items. All top-20 items at 13-21 points means the team cannot learn anything until late. Cut each into a first slice that can ship in a sprint and be measured.
• Compare cost of delay, not size. The 6% payment failure costs revenue on every affected transaction plus ~400 tickets a month; put a number on both and compare it with the expected value of the next-largest feature. In most retail contexts the defect wins decisively, and having the arithmetic makes it a business decision rather than an engineering preference.

The parity checklist should be re-read as a list of candidate hypotheses, not a definition of done. Feature parity is a competitor's shape, not a customer's need.

Reframe from outputs to outcomes, and make the trade-off explicit rather than argumentative.

The steering committee is not being unreasonable; they have been shown a checklist, not a value case. Give them one:

1. Show the current return. Usage across the 41 shipped features - nine features above 20%, nineteen below 2% - with the capacity that went into the low-use group.
2. Show the cost of the status quo. The 6% failure rate, 400 tickets a month, and the revenue at risk, expressed in the same units as the feature benefits.
3. Offer two plans for the 300 points: parity-first versus defect-first, each with a forecast benefit and a forecast risk. Then recommend one.
4. Ask for a decision, not permission. The product owner's accountability is to maximise value; the committee's is to accept the consequence of the choice. If they still choose parity, that is legitimate - but it gets recorded, with what it displaces.

Two supporting moves matter: invite a regional director to a sprint review to see usage against the wish list, and agree with the committee a small set of value measures the team will report each quarter. Requests that never face their own results keep coming back.

Instrument value before building, and review it on a predictable cadence.

• Every backlog item carries a stated hypothesis before it is built: which customer, which behaviour should change, and what the team expects to see. An item that cannot state one is a candidate for deletion.
• Instrument on release. Analytics for each new capability go out with it, not retrofitted after a year. The reason the current picture took twelve months to see is that no one was looking.
• Review usage at the sprint review and in a monthly value review, alongside the demo. The sprint review is where stakeholders should confront actual behaviour rather than opinions about it.
• Limit work in progress at the feature level. Nine used features out of 41 suggests too many things opened and not enough finished and taken up.
• Keep the backlog short and fresh: detailed for two to three months, pruned quarterly. A 220-item backlog is a storage facility, and storage facilities hide the fact that nobody has decided anything.

One caution: 2% usage is not automatically failure - internal, seasonal or niche features can be valuable. The measure is the expected outcome stated in advance, not an arbitrary threshold applied after the fact.