8 Sins of the Product Owner and Ideas for Change

Recently we shared an example of a Great Product Owner with you. Today I want to write a little bit about the mistakes a good Product Owner should avoid.

Who is the Product Owner?

Scrum Guide speaks of 3 roles in a project – Scrum Master, Product Owner and the Team. According to the definition “product owner is typically a project’s key stakeholder” and he is responsible for a number of things, such as prioritizing the backlog, sharing the vision with the team and making decisions. In our experience, most often it’s either a project manager or someone from the marketing department, or sometimes even the CEO of the company.

His role is vital and requires a lot of attention, patience and availability. Every time we start a project I see that Product Owners are enthusiastic and willing to cooperate. In practice, it’s not always what it’s cracked up to be. Here are some issues that can be fixed:

Sin #1: Wishful thinking (“We will make it all on time! People gonna love it!”)

Once you have entered the startup world, there are no ready recipes. There are no blueprints you can follow and predict exactly what it will take to build a given product. That’s why you do it with the agile process because in agile you iterate and learn. From what you have learned comes the wisdom to make good decisions. Your best chance to deliver the best product is not to guess but to measure. To put it more simply – you can use the knowledge of what the team was able to accomplish in a given time to predict what else can be done.

The same goes for the key functionalities that make a product – don’t just guess what is the users’ problem, ask them.

Solution: Don’t make decisions based on feelings only. Whenever possible, look for evidence that can support your decision.

Sin #2: Not knowing the product (“I don’t know what it should do, it was Mark’s idea …”)

You are the one person, who should know the product like the back of your hand. If there are more stakeholders with ideas of what the product should be like, you are the person who should collect these and funnel them into the backlog. You are the master of the backlog, you were entrusted to deliver the product. The worst-case scenario is when the product owner doesn’t know what the product should do. It means you haven’t done your homework.

Solution: There are many canvas tools (Business Model Canvas, Product Canvas) – use them to do your homework of learning together with the stakeholders what is the product you want to build.

Sin #3: Lack of vision and indecisiveness (“Let’s add back the functionality we’ve removed 3 weeks ago”)

Agile is all about embracing change, but there are limits. The worst type of product owner is a person who changes his mind every week. The Team has run a workshop with the Product Owner before the project, they agreed on the backlog and the scope of the first release and started development. In the meantime, the Product Owner insists on changes or worse, sometimes brings back the functionality which he has decided to remove a couple of weeks ago. This leads straight to failure, as the goal was to deliver fast, fail fast and learn fast. With each unnecessary change, you delay the release.

Solution: Focus. Embrace the concept of MVP. Keep your personal perfectionist from stopping you from delivering. Make decisions and stick with them, until you have tests to prove they don’t work.

Sin #4: Aggressive communication (“Are you nuts, it’s useless, we cannot launch it in this state”)

It’s not uncommon that people speak of a startup as if it was their baby. It’s your own personal idea you try to conceive and grow into a product that will be loved by millions. And there is this little perfectionist inside of you, who wants it to be the prettiest, most useful product on the market. Maybe you have this little feature that you love. It might be not critical, but you like it a lot. It’s your idea. Then you encounter a minor difference in how it looks. Maybe the colour is missed by a tone, or the button position is not fixed where you would like it to be. Maybe the Team has missed a deadline. You get emotional and your words are not nice. But you know what – the people on the other side also get emotional about their work. Don’t discard it as a whole just because you don’t like a part of it. Screaming, blaming and making people feel guilty creates a toxic atmosphere.

Solution: Keep calm. Believe that people in your tech team have good intentions and respect them by using positive communication (assertive and constructive feedback).

Sin #5: Not knowing the limits (“Let’s build it all. And add that too.”)

A good Product Owner is a realistic one. She knows her limits – she may have a budget for a given number of weeks of the Team’s work. She may have a deadline (fixed or flexible, but still a deadline). Don’t cheat yourself by making an assumption that budget and time can be stretched, and the whole scope you would like to have in a product will come with the first release. Remember iterations? That’s how you learn how much can be done in a specific amount of time. That’s what you use to predict and evaluate what can be done in the time you have, within the budget at your disposal. Then use this knowledge to prioritize the backlog, to set milestones, the scopes of releases and make sure that the Team knows where they are heading.

Solution: Set or learn the limits to stay in control and keep the transparency of your software development process.

Sin #6: Crossing the borders of competences (“It will take you 3 days to make that”)

I like this one. In my career, I’ve met so many business people who tell you what to build and even worse, how to build it. They may say: “Let’s use Ruby in this project”, and the only reason they can give is that company X used it. They may question your estimations, even though they haven’t made a single software project before. It’s then that I ask myself why do they require my skills and experience in the first place.

Trust is valuable nowadays. It’s also said – “trust builds trust”. If you want me to trust you in a given topic, then show me integrity, competencies, intentions and a track record. If you switch into a control freak mode, you will find yourself with limited time and resources to envision the product.

Solution: Do your homework – do some research about the Team you want to bring on board, ask them questions to learn if you can trust them. Then let them do their work and trust in their intent to make it the best possible.

Sin #7: Lack of preparation

Agile software development requires a lot of availability from the Product Owner. Planning sessions, retrospections and sometimes daily stand-ups – it all requires preparation. We know you are most probably a really busy person. So respect your time and the Team’s time and be ready for the meetings. When homework is not done, questions have not been answered, you haven’t discussed with stakeholders what should come next – it’s annoying. It may weaken the motivation of the Team.

Solution: Be prepared. Always. Respect the Team that works hard and expects the same attitude from you. It’s your business and your success is on the line, so make sure you have enough time to handle this. Or delegate the role of the Product Owner to someone else.

Sin #8: Lack of involvement

When starting to work with a Team, the Product Owner usually has high expectations. The Team is paid for development, and deadlines are expected to be met. But then the Team starts to ask questions, schedule meetings with the Product Owner and face a wall of silence, cryptic responses and postponed calls. For me it’s as simple as that – if you don’t have time for the communication necessary to deliver the product, the product is not important to you. We shouldn’t have started this project in the first place. If I am wrong, and you care about the product, then show it to me.

Solution: Get involved. Show that you care about the product so that the Team starts caring about it with you.

Of course, the list is not finished. There are more sins, but these are the mistakes I recently encountered and often enough to make it worthwhile to point them out. I know that being a Product Owner is not an easy job, but it’s a duty. We run a workshop for Product Owners and make them aware of their responsibility. It may be hard, especially at the beginning, but I am confident in the end you will appreciate being the founding father of the product.

Do you have your own experience with annoying Product Owner behaviours? Share your insights with us.

You May Also Like

Let's start developing something special

Get an online consultation or workshop session in no time!