Product Owner - Agile and Scrum Blog

Typical Mistake of Product Owners

One of the typical mistakes of Product Owners is, that they still live in the world of requirements. They still believe, they know what needs to be done. Or at least, that their customers know what needs to be done. So, they spend all the effort on gathering requirements, asking “what do you want us to deliver?” and through that they end up with this crappy Backlog, that grows to unlimited sizes. But none of that is true. The world had changed. It’s more unpredictable, is unstable, and complex by nature. I believe it’s a time to be honest and admit that we don’t know what needs to be done. All we know, is what do we want to achieve. But we don’t know how. And that’s a problem in traditional world. Because how can we plan what to do if we don’t know that. So that whole shift brought a lot of frustration to the industry past decade. And organizations were approaching it in the wrong way. They try to estimate better. They try to detail requirements. None of that worked.

So, what’s the solution to this problem? I think the solution is surprisingly simple, but we need to fundamentally change how we organize our business and how we prioritize. We need to look at things in more strategic way. We need to embrace the business agility and start welcoming changes already at the very beginning. The backlog was never meant to be fixed to-do list. Quite the opposite. It was meant to be dynamic and changeable. It was not meant to be full of requirements describing all the possibility details which must be delivered. Instead, the backlog supposed to be a collection of business cases, of small little hypothesis we phrased together to describe the needs of our customers, the pains of the business. And that’s very different from what you usually see in organizations.

So how can a backlog item look like?

Requirement

A detailed description of a functionality to be delivered. Very traditional, works for stable, known environments with no surprises. Usually large but can be split into smaller pieces.

The system shall provide users with an AI-based assistant that analyzes their transaction history and generates personalized financial tips. The assistant must support natural language queries and return responses in under 2 seconds.

The system shall allow users to set monthly spending limits for expense categories (e.g., dining, groceries, entertainment) and shall notify users via in-app alert when 80% of the limit is reached.

User story

If written correctly, it’s a frame for conversation with our users to describe a business case. It’s customer centric, value driven. It’s a good start to address customer’s needs. As a [persona] I want [what] So that [need].

As a Jenny (single mother, budget-conscious),

I want to have control over my monthly spending

so that I can keep my finances safe.

Story map

Like user story, but covering larger functionality, bringing the whole context of the user’s need. Is more consistent and coherent, balancing the customer perspective and the value.

Story: Jenny needs to Improve financial health

Map: Steps/Options/Journey:

Connect Accounts	Visualize Expenses	Recommend	Track Progress
Bank API	Automatic Categories	Tailored Tips	Progress Bar
CSV	Charts	Rules-based Suggestions	Gamification
QR Code	Manual Tags	Benchmark Suggestion	Predictive Trends
	Compare History	Savings Plans	Email Reports
	Weekly Trends

Impact map

A mind map describing hypothesis in visual form. It’s created around well-defined business product goals to maximize the value towards the goal. It helps you to be very strategic. Business Goal (SMART) → Actor (Who can influence the outcome?) → Impact (How shall the actors behavior change?) → Scope (What can we do to support that change?).

Goal: Help people make better financial decisions: (15% increase in savings or a 20% reduction in non-essential spending)

Actor: Young professionals

Impact: Limit ad-hoc spending

Scope: AI assistant that offers spending alerts and budget tips

Hypothesis

Optimizes for testing assumptions and learning from them. It’s highly adaptive, emphasizing adaptability, and regular feedback. We believe [Functionality] Will result [Outcome] We will have confidence to proceed [Measures].

We believe that providing users with personalized, AI-driven financial insights based on their real-time spending behavior

Will result in a 15% increase in savings or a 20% reduction in non-essential expenses

We will have confidence to proceed if at least 60% of engaged users show measurable improvement in their financial behavior and report feeling more in control of their finances through in-app surveys or usage metrics.

And there is more. However, the more venerable, unpredictable, complex and ambiguous your environment is, the more you need to leverage the flexible and business-oriented techniques further down on my list. Requirements are not successful in unpredictable world. Organizations need more business agility, so forget requirements and try some story mapping, impact mapping, or hypothesis. Business agility is not an option anymore. It’s a necessity.

Top 10 Agile conferences to attend in 2026

Every year I speak at many conferences and based on my experience I recommend some places to go for inspiration. Here is my list of Top 10 Agile conferences to attend in 2026. It’s not my intention to cover them all, I’m sharing places where I like to return. Inspiring places with interaction, high energy, and great speakers.

AgilePrague Conference is one of the best conferences in Europe. In two days, it creates unique collaborative space. You can expect short talks, afternoon workshops, and inspirational keynotes. Plus, Prague is a great city to visit so you can come early and enjoy the weekend in Prague. Join Agile Prague on Sep 21-22, 2026, Prague, Czech Republic.
Regional Scrum Gathering Tokyo is organized by an enthusiastic agile community in Japan. The purpose is to provide a “Ba” (place) where practitioners share ideas among Scrum practitioners having a great diversity. Regional Gatherings provides a unique experience and even if you don’t speak Japanese, there are some talks in English and other translated. Join me and the local community on January 7-9, 2026.
XP Days Benelux is a conference with parallel workshops for experienced audience. This year it’s going to be in Belgium on Nov 26-27, 2026.
Agile Coach Camp Cologne, Germany, Apr 30-May 2, 2026, is a global gathering, it is an open space event over 3 days of creativity, inspiration and co-working on new work-related topics.
AgileDC is a one-day conference with a motto: Of the People, By the People, and For the People. Organized by local community and it has a great atmosphere. Washington DC metro area, Oct 26, 2026.
AgileByExample, Warsaw, Poland, Oct 12-14, 2026, brings three days of intensive, example-driven content featuring global experts and deep dives into strategic agile governance and data-powered decision-making. This is where cutting-edge agile meets real-world application.
Scan Agile is one of my favorite conferences. It’s where the future of Agile takes shape. This year is planned for March 17-18, 2026, in Helsinki, Finland.
Agile Testing Days are almost a festival not a traditional conference. The full week of tutorials, talks, workshops, and networking events is just awesome. Join Testing Days even if you are not a tester. It’s in Potsdam, Germany on Nov 16-19, 2026.
LeSS Conference is from practitioners for practitioners. Since 2016, LeSS Conferences is where LeSS practitioners share their LeSS experience and learn from new experiments. Book your time for October 8-9, 2026, Tokyo, Japan.
Global Agility + Innovation Summit, Washington DC metro area, May 13, 2026, explores the Age of AI, focusing on building AI-powered products to leading in AI-powered environments.

The selection is based on my personal preference and experiences from those events.

Other conferences to consider this year

There are many great events that didn’t make it to this list, so please share your suggestions with us and we add them to the following list.

Agile on the Beach is great event to attend and explore the summer in Cornwall, UK on July 2 – 3, 2026.
Org Topologies Summit is a single track conference. Expect a curated mix of focused talks, hands-on workshops, engaging simulations, guided group discussions, and practical problem-solving. Mark your calendar for Oct 16, Amsterdam, Netherlands.
Additional events: https://agilegatherings.com/

Agile Teams, Conflicts, and TKI

In the world of agile, conflicts are natural part of the team’s journey towards innovation and efficiency. When teams come together to work towards a common goal, they’re bound to have different ideas and opinions. Facilitation is a great tool to help navigate through healthy conflicts. That’s one reason why having a ScrumMaster is always useful. But here I wrote about this many times already. This time I want to introduce a tool that is not that common, but is very useful to have in your ScrumMaster toolbox. Thomas-Kilmann Conflict Mode Instrument (TKI) is a tool, that helps people understand how they handle conflicts and keep your team productive and happy. It identifies five different conflict-handling modes:

Competing

The Competing mode is in the assertive and uncooperative quadrant. Sometimes, making important decisions without the team’s agreement can damage trust and cause problems. For instance, a Product Owner makes sudden changes without talking to the team, which leads to anger and quality issues. Or a team member pushes their ideas without listening to others, which breaks up the work and creates tension. On the other hand, it’s okay to make quick decisions when you really need to. For example, a Scrum Master can quickly stop a discussion to make sure the team meets a goal, or a developer can say that security is important, even if others are more focused on velocity.

Collaborating

The Collaborating mode is in the assertive and cooperative quadrant. Sometimes, trying to get everyone to agree can slow things down and make teams less efficient. For instance, if you spend too much time brainstorming and trying to please everyone, it can delay decisions and cause a condition called “analysis paralysis.” Or, if you try to include everyone’s opinions, it can expand the scope of the project beyond what’s actually needed. On the other hand, this mode is great for bringing together different perspectives and building consensus when a team works together to make sure technical decisions align with business goals. This can improve product delivery and customer satisfaction, or when developers and the Product Owner collaborate to make sure user stories are clear and prioritized correctly.

Compromising

The Compromising mode is intermediate in both the assertiveness and cooperativeness quadrants. Sometimes, accepting partial solutions can lead to missed opportunities for achieving the best results. For instance, when the team agrees on a solution that partially satisfies everyone but fails to fully meet important technical or business needs, or when sacrificing test coverage to meet a sprint goal, causing later rework and technical debt. On the other hand, it can be useful for achieving temporary settlements like negotiating a minimal viable feature set with stakeholders to meet release deadlines or splitting time between refactoring and delivering new features to balance technical health and value delivery.

Avoiding

The Avoiding mode is in the unassertive and uncooperative quadrant. Sometimes, ignoring recurring problems can make things worse, and it can hurt how well the team works together. For instance, if the team keeps ignoring the same issues, it can lead to technical debt or if a Scrum Master avoids dealing with conflicts, the team can keep getting stuck. But there are times when it’s okay to ignore small problems or when others on the team are better suited to handle certain conflicts. For example, if there’s a non-essential process debate that can wait until the retrospective, or if a developer with deep expertise can handle a minor technical disagreement without involving the whole team.

Accommodating

Finally the Accommodating mode is in the unassertive and cooperative quadrant. Sometimes, trying to please everyone too much can lead to forgetting about important things like technical and delivery needs. For instance, if a developer keeps agreeing to impossible deadlines to keep everyone happy, it can cause burnout, or the team always puts stakeholder demands first, even if it means ignoring technical debt. On the other hand, sometimes it’s good to keep harmony and relationships in the first place. For example, agreeing to small feature requests to build goodwill with stakeholders or when a senior developer lets a junior team member lead a task to gain experience.

Agile teams are all about teamwork, and it’s important for everyone to know how they usually deal with conflicts and how leaning towards different modes can change the team dynamics. For example, if you have a ScrumMaster who is very strong on Avoiding and Accommodating, they might ignore team issues, fail to remove impediments, and compromising agile principles to keep everyone happy for a while. In a nutshell, they’re not really helping teams and organizations change. Great ScrumMasters need to have a balanced profile with high Collaborating to integrate team insights and fostering consensus, and moderate Competing and Compromising to protect the team, keep agile principles, and navigate trade-offs effectively.

In real life, people have a mix of tendencies. For example, imagine you have a Product Owner who is very strong on Collaborating and Accommodating. He will cooperate well with the customers and build great relationships which is awesome but at the same time, they try to make everyone happy and can’t set a clear direction or make a decision when needed.

So how to start? Encourage team members to take the TKI assessment to gain insights into their default conflict styles. Understanding one’s natural tendencies can help individuals consciously choose the most effective approach in various situations.

After that, I usually run a workshop to discuss the five conflict-handling modes and explore scenarios where each mode might be most effective. Using role-playing helps team members practice switching modes and understand the perspectives of others.

Great Scrum Masters are a great help. They are good at recognizing conflict modes and are able to help teams find the most constructive way to deal with conflicts. They coach individuals to reflect on their tendencies and help them to create a better balance. They’re the ones who make sure everyone feels safe to share their thoughts, and they step in when things start to get too heated.

Backlog is not a Linear List

“It’s all about Product Backlog. Product Owner should manage it. Prioritize it. Fill it with User Stories.” Sounds familiar? It’s typical at certain stage of agile transformation to focus on building a Product Backlog. And use Jira for that. You find such linear to-do lists in almost every organization at the beginning of their agile journey. And though Product Backlog is very important tool as it brings clarity and align people around the same business goals, it’s also one of the most misunderstood and misused tools. It often starts with a good intention, Product Owner asking customer what they want. And they, in a good intention, brainstorm all the possible functionalities you can imagine. And the Backlog/scope keeps growing while the time expectations stay the same. That’s very common start of a big disappointment with Agile. “It didn’t help us. It’s not faster!” people say, and they are right. Agile is not the way how to deliver more functionality faster. Quite the opposite. It’s a way how to achieve higher business value faster, and those are two different things.

So, if you want to get more business value, start with the backlog. But this time, you’re not asking what you want to be implemented but instead ask for needs and look for a minimal functionality to be implemented to satisfy those needs. 80% of the value is in 20% of the functionality and that’s exactly what good Product Backlog should identify. The higher value items first, the rest later or never.

Good Product Backlog is co-created in collaboration with customer, stakeholders, and team members. They all need to uncover the business needs. They all need to develop an empathy for the customers. In most of the cases Product Backlog they create together is not a linear list that would fit traditional tools like Jira or Excel, instead very often we use Story Mapping technique to create multidimensional maps, or impact mapping technique to create a mind map, or visualize the product as a tree and prune the branches. Nothing that would look like a linear to do list. All the techniques have one thing in common; they focus on the business value and the customer needs. They don’t describe the solution. The how in Scrum should be uncovered during the Sprint in team collaboration. So, forget on the requirements, stop asking your customers what they want, and instead focus on uncovering their needs and together visualize the value in your Product Backlog.

Becoming a Great Product Owner

Companies often ask me how to find a good Product Owner. To start with, great Product Owners need to have a good business knowledge. It’s not about the product feature knowledge that much as your developers will have it as well, but it’s about understanding the overall business and market dynamics, the competitors, the existing product on the market. It’s about being able to create a business plan, understanding the customer needs. Product Owners need to have a sense of how we bring our product to the market. And finally, it’s also about being open to hear the feedback from the customers and change our plans accordingly.

The second area is about having a time to focus on being a great Product Owner. It needs to become your personal goal, so don’t combine it with anything else. After all, your ultimate job is to make the product successful so don’t worry, it will pay back. It takes time to develop different ways of creating Backlog items, it takes time to prioritize, but more importantly you need to have time to collaborate with people. Not only just with your developers, but more importantly with stakeholders and customers. In the traditional environments, we often believe that a Product Owner is a magical person who writes requirements, then throws them across the wall to developers to create and that’s it. But in reality when they catch it, they usually throw it back and say, “We don’t understand this, somebody should give us more details”. But that’s how it should never look like in agile space. Building a Backlog is about collaboration and co-creation with developers, stakeholders and customers. So you should never write backlog items without them. By collaborating and co-creating, people build the same understanding, alignment, and relationships among each other so then when they work on a particular item during the Sprint, they can actually be much more efficient. They ask clarifying questions directly, they don’t need a Product Owner to be in the middle. Having said so, the Product Owner could be seen more as a facilitative role, as a person who puts everybody together, who makes sure they can collaborate, who makes sure they all are aligned and share the same vision, who sets the priorities, who sets the product goals to be achieved, but actually who is not the team assistant that writes requirements. The power of Scrum is in creating teams that are close to the customer and understand their needs.

The next area for great Product Owners to be able to make a decision, be able to say “NO” to a feature. Product Owners who are weak in this and saying yes to every idea your stakeholders and customers come up with are not really good ones because their backlog keeps growing into unlimited size. And by the way, the more collaborative and inclusive you are as a team the worst it goes. So the most important thing Product Owners need to learn is to say “No, we are not going to do that now”. In order to say that you need to have a clear version, clear direction, good understanding of the customer need and market dynamics. 80% of the business value is only in 20% of functionality. Once you accept that, it’s relatively simple to say “We are going to do this now and the rest later or never.” And that’s quite a magical phrase. That’s how you really recognize if being a Product Owner is for you. Because if you can say that sentence with a big smile on your face, you are going to be a great Product Owner, if not, and if it’s only causing you frustration and pain, because you believe that everything needs to be done, the Product Owner role is not for you.

To summarize, you need strong business knowledge, authority and time, plus good negotiation, communication and facilitation skills. It’s a lot, but that’s the mix you need to develop to become a great Product Owner.

The Power of Metaphors

One of the tools I have started using more over the years is a metaphor. Many years ago I was taught the Speed Boat retrospective and tried it with teams. It brought great energy and fun, it helped us to uncover different perspectives. But it never occurred to me that I should take the idea to the next level and use it in other situations. So let’s have a look at different situations where metaphor can be useful.

Organizations are often used to look at outputs, measure effort, and compare velocity. One of the shifts that need to happen is from functionality to business value or in other words from output to outcome. And it’s not an easy shift, especially when the organization is still project-oriented, running on the “fixed scope” mindset. One of the reasons I’m using the metaphor with Product Owners is to shake with their business as usual – we deliver requirements – and reset their thinking about the product. I’m leveraging the Three levels of Reality concept I learned from ORSC and guiding them through the Sentient Essence level by exploring a metaphor, through the Dreaming level where the most collaboration at Backlog refinement is happening, to the Consensus Reality level they are used to by setting goals and objectives. The Sentient Essence level is about feelings it’s the spirit of things. It’s where the purpose is born. And the purpose is often forgotten in traditional organizations.

Using a metaphor is also a great icebreaker and team building. You see how different people collaborate, how they react to different perspectives, and look for commonalities. It can help teams to create an identity and become a better team together.

It’s also a great tool for ScrumMasters to reflect on where they like to have the team or the entire organization in six months, a year, or three years.

I’m often starting by letting individuals draw some animal, real or imaginary. Depending on the situation I might help them explore that metaphor more to uncover different aspects of it. Drawing is just one way how to visualize the metaphor. You can ask people to describe it, to create a gesture, song, or dance. There are no limits.

For example “We are like a flock of birds, they can fly fast, but not for long. Some got tired quickly and started falling down but the others continued without noticing. They are strong, they have great eyes, but once they start the journey they don’t like to change the direction.”

Then we compare the individual drawings, looking for similarities and uncovering the differences. And start integrating different perspectives into a coherent picture. It’s different than talking about numbers, goals, and objectives. It brings energy and creativity and I would encourage you to try it. Let me know how it worked for you.

Failing Fast

To my huge surprise, I realized that the concept of failing fast and learning from failure is difficult for some people to accept. They always feel the frustration when I say that ScrumMaster needs to feel comfortable to let the team fail so they can learn. I wrote about it here a few times, so you most likely know it, but the goal of a ScrumMaster is to make teams self-organized. They are not their assistant nor their mothers (as it might end by being dependent on a ScrumMaster), they are not their managers (the team is self-organized, fully responsible for their decisions), ScrumMaster is a coach, facilitator, helping the team to take ownership and realize they can solve most of their problems by themselves. And with every decision you take, there is a responsibility going hand in hand, and risk that you might fail. It is OK to fail if you learn from it. So ScrumMasters are not responsible for preventing failure, but for making sure the team will learn from it and figure out how are they going to work differently next time, so it will never happen again. And that’s very different from what the project managers have in their job description. And here is why – Project Manager is responsible for making decisions, ScrumMasters is not. It’s either the Development team (for how are they going to organize themselves to maximize the value towards the Sprint Goal), or Product Owner (for maximizing the value, prioritizing the backlog, and achieving the overall product success including the return on investment).

Agile is about safety to experiment and learning from feedback. In the VUVCA world, you never know what is the right functionality which will multiply the value and success. You need to inspect and adapt. Learn from failures. Be ready to respond to changes and be flexible to shift the direction based on feedback. Scrum has it all. Short Sprints which make it safe to fail, Retrospectives which ensure fast learning, Sprint Reviews which create a platform for frequent customer feedback, and Product Owners who take care of maximizing value and return on investment. It’s one thing to read it, and another to live it. What happens in your body if you hear “Your Sprint just failed.” Is it closer to the panic and looking for who to blame or is it closer to being curious and excited to search for improvements? It’s a simple question that indicates the level of agility. Failure is a good thing. All you need to do is learn from it.

New Scrum Guide

There was a new version of ScrumGuide published last week. And I have to say that I mostly like it. It’s lighter, less prescriptive, and simple. Here are a few differences.

#1 – Scrum Guide 2020 is Simple and Clear

Scrum Guide 2020 is clearer. Finally, there is a sentence that is easy to read, and that describes what Scrum is:

Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

A Product Owner orders the work for a complex problem into a Product Backlog.

The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

Repeat

Scrum is simple.

Yes, Scrum is simple and so the Scum Guide. It’s easy to read and understand. With this version, we got rid of many long and complicated phrases full of details. For example, one of my favorite changes in this space is that daily Scrum finally not suggesting the three questions but recommend that people “can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal…” Isn’t that awesome? After all those years of individual status meetings where people were reporting to someone what they did. It’s finally gone!

#2 – Focusing on the Mindset

I like the fact that the new Scrum Guide stresses the three empirical pillars of transparency, inspection, and adaptation and explains what are they about. The five values of Commitment, Focus, Openness, Respect, and Courage are clearly defined there now as well. It focuses on people’s behavior, over the processes and practices.

I also like the new Scrum Guide to remind us about the primary need for Agile and Scrum in complex and unpredictable environments: “In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.” All over, if you know what needs to be done, can plan it, then all you need to focus on is how fast are you going to deliver it. In such a world all different estimation techniques, velocity, burn-down, and burn-up charts are considered useful. Unlike Scrum, which builds on empiricism and inspects and adapts the plans on the way.

#3 – Scrum Team Focus

The biggest change seems to be that we don’t have “Development Team”, ScrumMaster, and Product Owner but “Developers”, ScrumMaster, and Product Owner forming a Scrum Team together. It looks like a big change, but it’s rather cosmetic as they all have to collaborate and self-organize (or self-manage if you like) to maximize value towards the Sprint and Product Goal. So, no real change there, we’ve just finally got rid of the very typical dysfunction where the Product Owner was like an enemy and the team was delivering to the Product Owner only. Now there is no such mentality in the Scrum team, they are in it together, responsible for all product-related activities. They are a team in the first place, a team that is cross-functional so can deliver end-to-end value together. ‘Developers’ is a poor name, as most people somehow read it as software developers but it’s more like a product workers. They are still the people who create working product increment every Sprint, while Product Owner focuses on maximizing the value and ScrumMaster on improving teams and organizations.

I also like the new Scrum Guide to make the scaling approach clearer than before: “If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.”

#4 – Product Goal, Sprint Goal, and Increment

Finally, the last change is the new language about Product Goal (new) and Sprint Goal (improved), and Increment (clarified). All over the Scrum Guide is catching up with the industry and adding a Product Goal as an artifact. It also provides a definition of a product, which is much broader than many organizations think: “A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users, or customers. A product could be a service, a physical product, or something more abstract.” Product Goal is a long-term objective for the scrum team – a vision. Sprint Goal gives meaning to each sprint and defines the value we are focusing on now. The increment is a useful output. Well done, verified, and delivering value towards the Sprint Goal. Simple and straightforward. Finally, there is a much better language about the Definition of Done: “The moment a Product Backlog item meets the Definition of Done, an Increment is born.” It’s almost like a poem.

All over, I really like the new version. It doesn’t change much from what I was teaching and using, just brings a more clear and crisp definition of Scrum as I know it.

Great Product Owners

Great Product Owners are not only having business knowledge, authority and time, but also a few additional skills which people often don’t expect.

“Great Product Owner is a facilitator, coach, negotiator.”

You will usually hear about coaching and facilitation in the connection with the ScrumMaster role. So why do we talk about Product Owners and facilitation and coaching? Can’t they just use the service of the ScrumMaster? They can. However, in many environments Product Owners are not the ‘heroes’ who decide on everything. Quite the opposite. They are great listeners, who have respect for different customer voices, and their highest value to the system is they can find alignment through coaching and facilitation. Customers (users, stakeholders, shareholders, sponsors, …) never agree with each other, they all have their own preferences and needs. Great Product Owners can help customers to reconnect with their needs instead of pushing what they want. In order to be able to do so, they need to step back, acknowledge that their requests are representing just one way of achieving their goals, and search for other options that would satisfy the needs of more groups than before. In other words, they need to be good at integrative negotiation and finding win-win solutions.

Finally, the last skill great Product Owner needs is visual facilitation. It seems like an unimportant skill, but the good picture speaks for more than a thousand words and can create real magic in searching for alignment. Visualization creates transparency, and transparency is ground for accountability. You would be surprised how good visualization of a conversation and different perspectives can help people to change their mind and proactively help you in searching for alignment.

Maybe those skills are not on the top of the Product Owners list at the beginning, however, the same skills differentiate great Product Owner from the newbies.

10 Most Common Mistakes of Product Owner

Being a Product Owner is not simple. At the end of the day, Product Owners are responsible for the overall Product success. They need to have business knowledge, authority and time. But let’s have a look what are the typical mistakes of a Product Owner as this is one of the very common questions at the classes and learn from that perspective. Here is the list:

Doesn’t Have a Vision

Without a clear vision, there is no direction, no way Product Owner can prioritize, and no Scrum. It’s just a mess where all we can do is to say “everything needs to be done”. The key responsibility of the Product Owner is to have a vision and be able to share it with everybody. Agile organization is about having an evolutionary purpose. If you don’t have it, why are you even here? Similarly to the vision, we have a Sprint goal in Scrum. Without it, everything seems like a good idea to do in Sprint. Sprint goal helps us focus on the need, the real business value.

Can’t Say No

There is no way you can do everything. There are so many options in a complex world. So much functionality customers can ask for. The Product Owner who says yes to all wishes from the customers will fail as the quantity will burn out the organization. Instead, Product Owners are prioritizing based on the business value, and as 80% of value is hidden in only 20% of the functionality, they need to say no quite often during their prioritization.

Doesn’t Have the Business Knowledge

Business knowledge is wider than just a product understanding. It covers the understanding of customers, the market, and the competitive landscape. Without such deeper understanding, Product Owners can’t make a decision and are drafted by different stakeholder groups into their politic fights and the products are usually failing to deliver the real value. Product Owner doesn’t have to be technical, but the business knowledge is critical to their success.

Can’t Prioritize

Product Owner who believes everything needs to be done is not a Product Owner but customer or stakeholder. Prioritization is key in Scrum, at any time you shall know what is more important than the rest and what are we going to invest our energy (effort and money) into next and the rest later or never, depending on the feedback and impact we achieved by the value delivered. There is always more functionality which can be implemented. But maybe that little we already did is good enough for now and we can focus on some other more important areas. As I said already, 80% of value is hidden in only 20% of the functionality. There is no need to implement 100% of the ideas you have.

Don’t Have Negotiation Skills

The Product Owners without negotiation skills are very weak Product Owners. They often end us accepting everything customers ask for and are struggling to say no. Negotiation skill help Product Owners to understand not only what the users want but also what they need. Ant that’s the key part of the prioritization.

Estimates are the Key

Product owners who focus too much on estimates are mentally tight to the functionality, not the business value. In the traditional world, the estimates are important as all we care about is delivery, and we need to deliver more. In the Agile world, it’s not about delivering features. It’s about achieving certain business value. And those two have often only very little in common.

Doesn’t experiment

Product Owners who believe they can create a plan (in agile called Backlog) and then step by step execute it with the development teams during Sprints are not real Product Owners. Backlog can’t be farther from a plan and an iterative approach of delivery is here to inspect and adapt and learn from experiments. Find out where is the real value. The approaches like Lean Startup are quite useful here.

No Impact

As we said, Product Owner shall be able to run experiments. In a way, every backlog item is an experiment where you expect something will happen as a result. That’s the impact. Without knowing why you invest team time and energy into it, why to do it in the first place? Running an experiment without knowing how are you going to evaluate it is silly. That’s not an experiment but functionality you plan to deliver no matter what. Why? Because it’s important. Because I said so. Instead, spend more time identifying the impact so you know why you do it and what you expect to happen. Tools like Impact Mapping are quite helpful here.

Multiple Products

Or shall I say systems, or projects? Because product definition is much wider than that. Product Owners taking care of multiple product don’t have focus, and often don’t have time. Considering Product Owner is the person responsible for the overall product success including the return of investment, it’s quite useful to have the focus for making the product successful and don’t switch the context all the time.

Not Part of the Team

Product Owners sometimes feel they don’t belong to the team. They act as Backlog managers, telling the team what to do, and then waiting to get results/blaming at the end of Sprint. Instead of that, Product Owners are part of the Scrum team, they are team members, they shall collaborate with the team on delivering the value and achieving the Sprint Goal. They are part of the team.