{"id":2246,"date":"2018-08-27T10:00:44","date_gmt":"2018-08-27T08:00:44","guid":{"rendered":"https:\/\/craftcoders.app\/?p=554"},"modified":"2024-08-14T14:27:54","modified_gmt":"2024-08-14T12:27:54","slug":"5-essential-things-about-working-with-a-product-owner","status":"publish","type":"post","link":"https:\/\/craftcoders.app\/5-essential-things-about-working-with-a-product-owner\/","title":{"rendered":"5 Essential Things about Working with a Product Owner"},"content":{"rendered":"\r\n

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\u2019s 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.<\/p>\r\n\r\n\r\n\r\n

\r\n
\"\"<\/figure>\r\n<\/div>\r\n\r\n\r\n\r\n

As a Product Owner and Games Producer myself, \u00a0I 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.<\/p>\r\n\r\n\r\n\r\n

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\u2019t, it\u2019s 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 \ud83d\ude09 So have fun with probably some unconventional, yet pretty honest insights into the world of a Product Owner.<\/p>\r\n\r\n\r\n\r\n

 <\/p>\r\n\r\n\r\n\r\n

Table of content<\/h2>\r\n\r\n\r\n\r\n
    \r\n
  1. What a PO does<\/li>\r\n
  2. Why a PO needs you<\/li>\r\n
  3. Why a PO disturbs you<\/li>\r\n
  4. Why a PO forgets you<\/li>\r\n
  5. Why a PO relies on agile ceremonies<\/li>\r\n
  6. Sum Up<\/li>\r\n<\/ol>\r\n\r\n\r\n
    \r\n\r\n\r\n

    What a Product Owner does<\/h2>\r\n\r\n\r\n\r\n

    In my career, I\u2019ve 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!<\/p>\r\n\r\n\r\n\r\n

    \u201cWould you tell me, please, which way I ought to go from here?\u201d
    <\/em>\u201cThat depends a good deal on where you want to get to,\u201d said the Cat.<\/em>
    \u201cI don\u2019t much care where\u2014\u201d said Alice.
    <\/em>\u201cThen it doesn\u2019t matter which way you go,\u201d said the Cat.<\/em>
    \u201c\u2014so long as I get somewhere,\u201d Alice added as an explanation.
    <\/em>\u201cOh, you\u2019re sure to do that,\u201d said the Cat, \u201cif you only walk long enough.\u201d<\/em>
    Alice in Wonderland, Chapter 6, Pig and Pepper<\/cite><\/blockquote>\r\n\r\n\r\n\r\n

    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\u2019t 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\u2019s only trying to put into words, what your organization, society, market and most of all the user needs.<\/p>\r\n\r\n\r\n\r\n

    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\u2019t 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\u2019s why \u201cNo\u201d is one of the most important words of a Product Owner. To stay strong and resilient towards everything coming his way, he needs you.<\/p>\r\n\r\n\r\n

    \r\n\r\n\r\n

    Why a Product Owner needs you<\/h2>\r\n\r\n\r\n\r\n

    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\u2019m not better at programming than a developer, I\u2019m not better at designing than a designer, I\u2019m 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.<\/p>\r\n\r\n\r\n\r\n

    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\u2019s 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\u2019t 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\u2019s not done well, and you will rise and shine when it\u2019s successful.<\/p>\r\n\r\n\r\n\r\n

    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\u2019t 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\u2019s 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.<\/p>\r\n\r\n\r\n\r\n

    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.<\/p>\r\n\r\n\r\n

    \r\n\r\n\r\n

    Why a Product Owner disturbs you<\/h2>\r\n\r\n\r\n\r\n

    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\u2019s your reaction? Very often I hear something like \u201cOh, damn meetings, preventing me from working\u201d. If you are not saying this: good! If you do, maybe it\u2019s 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\u2019t 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\u2019t come forward yet.<\/p>\r\n\r\n\r\n\r\n

    In fact, I meet a lot of Product Owners being \u201cafraid\u201d 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 \u201cneed consultancy\u201d, so someone who has a free mind can reach out to him\/ her.<\/p>\r\n\r\n\r\n\r\n

    \"\"<\/figure>\r\n\r\n\r\n
    \r\n\r\n\r\n

    Why a Product Owner forgets you<\/h2>\r\n\r\n\r\n\r\n

    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\u2019s 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\u2019s the value for users if you do it, or the effect if you don\u2019t. 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\u2019t 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\u2019t do that as frequently as they should. It\u2019s only human to listen most carefully to the loudest screaming person. You don\u2019t 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\u2019t 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!<\/p>\r\n\r\n\r\n

    \r\n\r\n\r\n

    Why a Product Owner relies on agile ceremonies<\/h2>\r\n\r\n\r\n\r\n

    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\u2019m talking about retrospectives, sprint reviews, and daily stand-ups. Use them!<\/p>\r\n\r\n\r\n\r\n

    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\u2019t fit into your day. You might be happy and thankful when you have someone who reminds you of simply doing it.<\/p>\r\n\r\n\r\n

    \r\n\r\n\r\n

    Sum Up<\/h2>\r\n\r\n\r\n\r\n

    So what did we learn today?<\/p>\r\n\r\n\r\n\r\n