Whoosh! – to 30,000 feet where you report on the project progress to your sponsors.
Whoosh! – to the team on the ground to discuss the calculation behind a number.
Whoosh! – to somewhere in the middle to talk with a fellow PO about who should handle an incoming story.

Flying (at different altitudes) is one of the most critical super powers of an unbreakable product owner. As a PO, you need to keep your audience in mind and adjust your vocabulary and level of detail accordingly. Too little for the development team and they will build a skewed version of the feature, too much for the executive sponsor and you will lose their interest and possibly their support. And you have to fly in between them as well when you are discussing the project with other IT professionals or mid-level working groups in the business. The real-world power here is empathy – putting yourself in the shoes of the people with whom you are speaking.

When discussing things with a team, be specific. Really set aside the time you need and research your stories in-depth so you can provide all the necessary details. Clearly write out the backlog story and highlight key acceptance criteria. Everything beyond that needs to happen in discussions during planning and during the sprint. I personally love the business analysts I work with too, because they help me cover all the details I miss with my strategic, rather than tactical, mindset.

When reviewing the latest sprint’s efforts with stakeholders, you need to give them all the practical details, especially the visible changes. You also need to communicate in a non-techie way about the changes they cannot see. This is difficult as you emerge from the nitty gritty of a sprint but you will lose your stakeholders if you give too much detail. Definitely say things in layman’s terms like, “When you enter a number in this box, it calculates the duration. And it lets you undo it by clicking…here.”

Definitely DON’T say, “When you select this field with your mouse and enter the appropriate data, it generates a message that calculates the duration using the e=mc squared divided by pi, formula. Then you can revert to your original state by selecting this widget, that accesses up to 10 of your previously made decisions.” None of that is bad information – have it ready if they ask, but they do not necessarily want to know all of the fascinating detail you now possess. Every one of us occasionally “builds a clock” when someone asks what time it is, but resist. They will love you for it. I’ll go into the problems this “Curse of Knowledge” causes when I review the book Made to Stick.

And for that 30,000 foot altitude I mentioned above, see my post on selling your ideas to high level executives.

I used to be annoyed that I had to repeat myself so many times as a product owner, but over time I have realized that it is actually translation, not repetition, and it is very valuable to everyone when you can fly back and forth to different altitudes with ease.

Addendum: Realized I was not clear about the context here (as pointed out in the LinkedIn Product Owner’s Help Desk group which you should join!) – you should absolutely have development team members talking directly with stakeholders in reviews, story mapping, etc.  This was just intended to highlight that POs have a responsibility to understand business jargon as well as technical jargon and make sure communications are smooth.