Library-board members distrust the digital-card product after two years of slide-deck promises and few usable releases. How should the Product Owner rebuild trust?
Select an answer to reveal the explanation.
Short Explanation
Trust is not a speech; it is a working library card in someone’s wallet. Tiny Increments people can poke beat another beautifully printed promise. Show the thing, then talk.
Full Explanation
Stakeholder trust in civic products grows from inspectable value, not from longer plans. After two years of slide-deck promises and few usable releases, a library-board’s distrust of the digital-card product is rational. The Product Owner should rebuild trust by delivering small, valuable Increments the board can inspect rather than relying on promises. Frequent Done Increments create transparency and give boards evidence that forecasts and Product Goals are real, which is the only durable repair for promise fatigue.
Publishing a 24-month committed feature contract and weekly status emails fails because more promises without releasable product deepen skepticism. Pausing delivery for a quarter to write a more inspiring vision narrative fails by substituting storytelling for empiricism. Asking the Scrum Master to run a trust workshop instead of releasing software fails because facilitation cannot replace working digital cards residents can actually use.
Exam caveat: Trust is rebuilt with Done Increments stakeholders can inspect, not with plans or workshops alone. Operational check: Order the next few Sprints so the library board can see at least one usable digital-card capability in production-like conditions at each Review.