12% adoption and a dashboard for the sponsor
A logistics company bought a picking-and-scanning app for its 300 warehouse staff. The IT director who signed the contract is the only stakeholder who attends Sprint Review, and measures success by "the project being delivered on time"; the Product Owner's objectives are tied to the same measure. Four months after rollout, telemetry shows 12% weekly active use; pickers still print paper pick lists because scanning "takes longer than writing". The Product Owner has never visited a warehouse. The IT director's latest request is a compliance dashboard for his own reporting. The team is proud: it delivered every item committed in the last six Sprints.
1. Who are the users, the customers and the stakeholders here, and why does the distinction change what the Product Owner does next?
Read the worked answer
Map it.
- Users: the 300 warehouse pickers. They use the product daily and are choosing not to.
- Customer: the logistics company - the economic buyer whose budget and business outcome the product must serve. Represented in practice by the IT director, but he is not the customer; he is a stakeholder with budget authority.
- Stakeholders: the IT director, warehouse supervisors, compliance, finance, and the pickers' line managers (who own the productivity numbers the pickers are judged on).
Why it matters. The Scrum Team has optimised for the one person in the room, and that person's success measure is delivery against a plan - not use. Every committed item was delivered, and the product is failing. The distinction tells the PO that "on time" is a constraint, not a definition of value, and that the real hypothesis (scanning makes picking faster and more accurate) is currently disconfirmed by the pickers' behaviour.
What it changes. The 12% figure is the most important evidence in the organisation and it is outside the Sprint Review's field of view. The PO's next move is not to accept or refuse the dashboard; it is to close the gap between the team and the people whose work the product is supposed to change.
2. The IT director asks for a compliance dashboard. How should the Product Owner respond, and what should happen before any new feature work?
Read the worked answer
Do not simply refuse. The request is legitimate - compliance reporting may be a real obligation - and refusing the only engaged stakeholder isolates the team further. But it must be ordered against the evidence, not against the requester's seniority.
Before building it, establish what the product is actually doing.
- Observe, don't survey. The PO should spend time in a warehouse watching a picker use both paper and the app. The complaint "takes longer than writing" is a specific, testable usability claim and probably has specific causes (scan angle, glove use, connectivity dead spots, extra taps).
- Look at the telemetry properly. Where do sessions abandon? Which screens are slow? Is the slowdown real or perceived-and-worked-around?
- Talk to supervisors, who own the productivity targets the pickers are held to - the pickers may be rationally avoiding a tool that slows their numbers.
Then order. If the compliance dashboard is legally required, it goes in and gets built - as a small, sliced item, not a platform. If it is for internal visibility only, sequence it behind whatever removes the adoption blocker, and say why, using the 12% figure.
Reframe the conversation with the IT director. "Every item was delivered on time and 88% of your staff are not using it. Here is the evidence and here is what I propose we do about it." That is a stronger position than either compliance or refusal.
3. How should the Product Owner restructure the Sprint Review and the team's feedback loops so this does not repeat?
Read the worked answer
What the current Sprint Review cannot do. With only the sponsor present, the Review inspects delivery against plan. It cannot inspect whether the product works, because the people who know are not in the room and the PO has never met them.
Changes to the event.
- Invite two or three pickers (with their supervisors' agreement) and a warehouse supervisor to each Sprint Review. Not as a courtesy: they are the users, and their reaction to the increment is the primary evidence.
- Demonstrate in the context of the work: the picking flow against a real pick list, timed.
- Put the adoption and task-completion numbers at the start of the Review, next to the increment. The team's pride in delivery is real and should be preserved - but it must sit beside the outcome.
- Discuss compliance reporting in the same session where the adoption problem is visible, so the trade-off is made by the stakeholders together rather than in side conversations.
Changes beyond the event.
- A standing, cheap user-feedback loop: warehouse visits each Sprint, in-app instrumentation reviewed at refinement.
- Rebalance the PO's objectives so delivery-on-time is one input, not the target. A PO measured only on delivery will keep delivering things nobody uses - the setup guarantees that behaviour and then blames the person for it.
The uncomfortable point to make. The team delivered everything it committed for six Sprints. That is evidence the commitments were wrong, not evidence of success.