When a team has issues at communication with their Product Owner you may have serious trouble coming towards you. Having problems dealing and talking with your Product Owner inherits a lot of risks for everyone, e.g. it can lead to a huge mountain of technical debt, repeating release postponement, and ultimately a lot of stress, discourage, a failing product or at least a bad standing within your organization, probably a burned out or unhappy team, including you and your Product Owner. But that’s a mighty long road to drive until it comes so far, and you will have a lot of possibilities to correct your course! Cheer up! This blog post is for you and everyone who is working with a Product Owner in a (hopefully agile) product development team.

As a Product Owner and Games Producer myself,  I hope, with the following insights, to bring some value to you and your team members. You will learn why sometimes us Product Owners act how we do, and what you can do to improve your teamwork.

I gotta say: there are always two sides to a coin. Success is a team result – work together and you can make great things happen! If you don’t, it’s very likely that you fail on some level – first a bit – later drastically. In this post it may seem a little one-sided, but of course: the Product Owner should also learn how his team works and why developer and designer act how they do, and what he/she can change to improve your teamwork. But that’s content for futur blog posts 😉 So have fun with probably some unconventional, yet pretty honest insights into the world of a Product Owner.

Table of content

1. What a PO does
2. Why a PO needs you
3. Why a PO disturbs you
4. Why a PO forgets you
5. Why a PO relies on agile ceremonies
6. Sum Up

What a Product Owner does

In my career, I’ve seen a lot of teamwork bloopers. Mostly it all comes down to understanding each other and communicating accordingly. Especially junior-level teams first need to understand how the product world works. Sometimes it may seem like the Product Owner is not valuing your opinion, effort and time, yet I can assure you: we maybe are the ones who are most concerned about exactly just that!

“Would you tell me, please, which way I ought to go from here?”
“That depends a good deal on where you want to get to,” said the Cat.
“I don’t much care where—” said Alice.
“Then it doesn’t matter which way you go,” said the Cat.
“—so long as I get somewhere,” Alice added as an explanation.
“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”
Alice in Wonderland, Chapter 6, Pig and Pepper

The main goal of Product Owners is to make sure that your work and effort is well-placed, not wasted, not spilled or lost on a wrong path, but creates the maximum value for the user, and ultimately you. To show the way and make sure you are not wandering around like Alice in Wonderland, we try to find the right thing, convincing and powerful. Therefore the Vision Statement isn’t just a buzzword-bingo or brainwash-methodology, but the direction the team is supposed to walk, the common understanding. Sometimes it seems like Product Owner came up with the vision just like that, nevertheless you gotta understand that he’s only trying to put into words, what your organization, society, market and most of all the user needs.

Next to this, probably the most obvious tasks of a Product Owner is to keep stakeholders away from the team and to channel all requests as a single point of contact (SPOC). Because again – We only want you to work on what matters. Mostly stakeholders don’t really know what they want (even though they think differently about that), which makes it even more important to find out, what the actual problem is, to then decide what to do, and what not. That’s why “No” is one of the most important words of a Product Owner. To stay strong and resilient towards everything coming his way, he needs you.

Why a Product Owner needs you

First of all: because you read this blog-post, came till here, and obviously are eager to develop a common ground. Secondly, he really needs your input to work best. In my work I am always trying to make the team understand: I’m not better at programming than a developer, I’m not better at designing than a designer, I’m not better at analysing data than the data analyst, so I need my specialists to give me everything they got, so that I can take right decisions with you.

A perfect example of this is the design sprint. The key objective is to solve a user problem. It technically means to find proof for hypotheses proposed by an idea and then frame a Minimal Viable Product (MVP). Within a week or two, you discover, define, develop and deliver something completely new and finally create value for the user. When the Product Owner puts together the team, it’s crucial to have the right people on board. You got to learn to understand what stakeholders want. This is the right time to show your strategic foresight. Take the technical lead for the creative process and your input can make the deciding difference to achieve success. Bring in your creativity and technical ideas to solve a user problem. You have access to tools and ideas that the others don’t have. Do this and receive standing ovation. The result will be your baby – you will be the go-to-guy, you will suffer when it’s not done well, and you will rise and shine when it’s successful.

But not only in design sprints, we need professional input. Within backlog grooming, refinement or sprint planning give your Product Owner as much feedback as possible, even when he/she doesn’t actively ask for it. Use those meetings as a health insurance for your team unity: mention expense drivers and offer options – be constructive! Within your team, you should consider writing acceptance criteria and user stories yourself, at least when you spot gaps. By putting yourself into the user’s shoes while writing the stories, you raise awareness of the vision and the target persona, additionally, you drastically support your Product Owner. Maybe you even initiate having an Acceptance Criteria-checklist for the team, to encourage and enable everyone to collaborate in this way.

And last but not least: When we ask you for an estimation for a vague story, we mostly need some type of horizon of what can be expected, and we don’t expect an exact calculation – sometimes a guts-feeling is all we want. So it is best to make us understand a tendency rather than letting us stand alone in the rain. Also, explain why it seems unclear, and then we can fill the gaps together.

Why a Product Owner disturbs you

Now you know, the Product Owner values your time but also needs your input. So when you are coming to work in the morning, looking into your schedule and an additional meeting pops up in your calendar – what’s your reaction? Very often I hear something like “Oh, damn meetings, preventing me from working”. If you are not saying this: good! If you do, maybe it’s time to reconsider. When your Product Owner invites to a meeting, he/ she painfully prioritized already, very clearly against his/ her own preferences, because he really wants you to get your stuff done! But your role, as a member of an agile team, is not only to sit behind the keyboard and develop stuff like a coding monkey but to also provide important information and deliver your points of view. Programmers should not encourage the organization to bypass them. If you don’t like specific things in your meetings, talk to your Scrum Master or team, and change it. Maybe others have the same pain points but didn’t come forward yet.

In fact, I meet a lot of Product Owners being “afraid” to distract his team and take them out of their working-tunnel. We know, when you get distracted it takes you time to think on the topic again. Still, when we need important information and technical expertise to determine an issue, we need you. Next time you catch yourself reacting annoyed, show empathy. Another way to handle this and turn it into a win-win, is to agree on how to approach each other: e.g. with Sticky notes, or a sign to set to “need consultancy”, so someone who has a free mind can reach out to him/ her.

Why a Product Owner forgets you

This sounds a bit weird, I know. Yet, there may come the time when you get the feeling your Product Owner forgets that you and the team are also key-stakeholders for the product. Mostly it’s the moments when the technical debt or lack of quality is raising the risk, or you are generally concerned about the decisions. It is important for you to learn how to approach your Product Owner then! The key is to speak in the same language. Write your technical issues as user stories and make clear what’s the value for users if you do it, or the effect if you don’t. The things you care about will be user relevant. Maybe not in the next sprint, but in the mid to long-run. Technical user stories are a thing! They must be split, handled and prioritized the same way as functional stories too. If you don’t speak up in grooming/ refinement meetings, I guarantee, other stakeholders are always shouting louder. Being a Product Owner means people are constantly approaching you, inquiring about new features or bugs. Usually, the team doesn’t do that as frequently as they should. It’s only human to listen most carefully to the loudest screaming person. You don’t have to shout at him permanently, but be verbal and tell him why your idea is good for the user. Technical tasks often address release time, stability or maintainability. You should argument to ship user value faster and have fewer complaints in the App-Store. Lastly, maybe you don’t want to bother your Product Owner too much since you see him/her struggling enough already and you feel sympathy – you need to learn, to still address your concerns!

Why a Product Owner relies on agile ceremonies

Working in an agile environment is pretty convenient, and by applying the best fitting framework, a team gets powerful tools and techniques to develop an amazing product with maximum user value. There are also very important ceremonies no team should miss or stop active participation. I’m talking about retrospectives, sprint reviews, and daily stand-ups. Use them!

It can happen that a Product Owner decides against participating, which is not good in the mid or long term. Every issue has its place and for the Product Owner, it is crucial to rely on some constants within his schedule and to not lose the grip. They are just as important to Product Owners as for developers and designer. So sometimes you need to actively demand the participation of your Product Owner and remind him, that he is part of your team! You can compare it to meditation: You know it actually is doing good to your mental balance, you probably should do it every now and then. Yet, even though it only takes 10 – 15 minutes, it somehow doesn’t fit into your day. You might be happy and thankful when you have someone who reminds you of simply doing it.

Sum Up

So what did we learn today?

• We actually do stuff that is good for you,
• we need you,
• we value your time and opinion,
• and if we seemingly don’t, we need to learn to speak the same language,
• and we need to maintain a common and constructive base, using agile techniques.

All in all, we need to keep in mind, that, even though Product Owners are mostly the only one of their kind in a team, they still are team members and not Englishmen in New York. And yes, sometimes we can be a pain in the ass, but maybe now, after reading this blog post, it is easier for you to understand.

And, dear Product Owner colleagues, if we can’t excite our team to believe in what we do, if we don’t fight for their interests, and not make them understand the “why” behind the “what”, but instead build up walls of miscommunication and distrust – we won’t stand against the competition. We need the team and we need to be strong together.

Rise and shine!

Best regards