If you're a Product Owner spending your stakeholder engagement sessions explaining user stories, epics, or how a feature "sits" in your hierarchy, you are wasting their time.
Users don't give a damn about your backlog.
I've spent my career building services for expert users: police officers, caseworkers, and civil servants who spend 40 hours a week using the services we've built for them. These people have high-stakes roles and they do not have the mental bandwidth to navigate your delivery team's internal admin.
Expert users care about whether the service you're building helps them get through their day without a headache. They do not care about sprint velocity, "ready" criteria, or the elegant way you've organised your tickets and prioritised the backlog.
When you pull users into the machinery of how software gets built, you are not being "transparent", you are being lazy. You are forcing them to do the translation work that you should be doing. The second you pivot to delivery language, you remove those experts from the conversation, because you've moved the discussion out of their world and into your own.
When you get time with people who use your product every day, stop talking about your delivery processes and start talking about the challenges your users face:
- Where does the work get stuck?
- Which handovers cause the most confusion or delay?
- What workarounds have people created to get the job done?
- What risks do people face when the software does not support the task properly?
When you demo a change, shut up about the "user story" and answer the only four things they actually want to know:
- What does this let me do differently?
- When can I actually use it?
- How do I start using it?
- What's going to change, disappear, or get harder?
If you cannot describe a product change using the nouns and verbs your users use, you do not understand the service well enough to be directing it.
Keep the "how" in your team room. Bring the "what" and "why" to your users.
