Product Owners Must Go Beyond Scrum!

It’s too naive to think Scrum is enough to create valuable products.

A faulty understanding of Scrum frightens me: companies want to use Scrum to increase output. Instead of speeding up the learning time, they want to accelerate the features pipeline. When that’s the reason companies decide to move from whatever they do to Scrum, you can only expect confusion in all layers.

Beyond a poor Scrum implementation comes the misinterpretation of the Product Owner’s accountability. I am shocked by how companies can mess up with it. They overlook the size of this role and what it takes to succeed. Management thinks that once someone understands Scrum well, they can flourish. Consequently, unprepared people are nominated to be Product Owners.

The truth is simple: no one can live up to the Product Owner’s responsibility relying solely on Scrum. Yet, companies turn a blind eye to it and let someone clueless about Product Management become a Product?Owner.

Let me share why I believe Product Ownership goes way beyond Scrum (the framework is incomplete by design ). At the end of this piece, you should be able to understand what else you need before taking the challenge of being a Product Owner.

Failing by?Chance

Imagine the following situation: you work for a successful online shop and are a respected business analyst. After two years, you’ve built trust with people around you, and your manager comes to you and offers you the chance to join Team Avengers as the Product Owner. She convinces you can do the job. You may be scared because it pushes you out of your comfort zone, but you decide to accept the offer.

Your manager believes you can gain the required knowledge quickly, so he assigned you to a CSPO course to prepare for the challenge. After a two-day training, you got a certificate, and now you’re a Certified Scrum Product Owner. Now you know your responsibilities and what the team expects from you. Although the burden seems heavy, you’re excited and eager to get your hands dirty.

As soon as you become a Product Owner, many stakeholders want you to put something into the Product Backlog. Everyone pressures you because their requests are urgent and equally important; if you don’t deliver what they want, the business may explode, leaving everyone unemployed. Every day the burden gets heavier, but you believe that if you do a little bit of everything, you can calm them down.

Three months have passed, and you review your achievements. Thirty-seven new features were created, thirteen bugs were fixed, and three critical components were refactored. The numbers seem relevant, but something annoys you a lot: you are clueless about what these numbers mean.

Despite pleasing your stakeholders by doing what they want, they still pressure you as much as possible. No matter what you do, stakeholders remain unsatisfied. Meanwhile, developers are getting mad at you. They insist the code base is unsustainable and urgently needs time to refactor.

You’re confused. During the last months, you thought you did Scrum well. You continuously managed your Product Backlog items, refined them with the Scrum team, planned the Sprints, crafted Sprint Goals, engaged with stakeholders during the Sprint Reviews, inspected the output with them, and adapted to address their wishes. And apart from doing Scrum to the best of your abilities, failure seems unavoidable.

You feel trapped. The business side pushes for more, developers urge for less, and you don’t know how to solve this puzzle. What’s?wrong?

What It Takes to Be a Product?Owner

Why do you think the business analyst ended up in a situation where stakeholders and developers were unsatisfied? Think about it for a couple of minutes. Now let’s look at the traps she faced and why she failed:

• Managing the Product Backlog: given the pressure received from several stakeholders, the Product Owner used the Product Backlog to reflect the stakeholders’ wants. She failed to understand the needs behind their wishes. The Product Backlog inevitably descended to a messy pointless wishlist within such an approach.
• Prioritization: stakeholders claimed everything was urgent, and the Product Owner lacked a method to evaluate what was indeed critical and what not. She decided to avoid conflicts by doing a little bit of everything for everyone. Ultimately, everyone was disappointed.
• Deliver value: despite creating many features, fixing bugs, and refactoring components. The Product Owner didn’t look into the impact caused by the output produced. In other words, the tangible outcome was not measured.

Unfortunately, this story isn’t hypothetical. I’ve experienced such a situation more often than you can imagine, and I guess you’ve probably observed something similar. But why do people land in such traps?

The point is simple; Scrum isn’t enough to create valuable products.

Don’t get me wrong. I am not saying Scrum is useless. For me, Scrum is one of the best available Agile framework, but you’ve got to know how to benefit from it. Scrum is incredible in helping you navigate the unknown and improve collaboration. In a nutshell, Scrum tells you what is in the way to create value, but it doesn’t guide you on how to act. When it comes to action, you’re on your own.

Product Owners must go beyond Scrum to succeed. Here are some of the questions you will have to figure out once you wear this hat:

• How can I identify problems that are worth solving?
• How should I order the Product Backlog to deliver value faster?
• How could I establish solid partnerships with stakeholders?
• How can I measure the impact generated by the Scrum Team’s work?
• How do I uncover the needs beyond the wants of stakeholders and end-users?
• How can I move from implementing tasks to achieving goals?
• How should I balance between new features and keep the lights on work?
• How do I speed up the learning time of what helps our end-users?
• How do I validate our assumptions faster?
• How do I define metrics to accelerate decisions?

Scrum may remind you to do all the above, but it won’t tell you how to do it. That’s why you must develop proper product management skills to thrive as a Product Owner. Otherwise, you rely on luck, and that’s a bad choice for such a heavy burden you carry.

Take Responsibility for Your Development

No matter how you ended up as a Product Owner, you are responsible for leading teams to create value. It’s challenging to deliver on your expectations, but you can do it with the proper skill set. And that’s why you must act and take responsibility for your development. You cannot rely on anyone besides yourself.

You’re the only one who can acquire the skills you need. Neither your manager nor an experienced Product Owner nor anybody else can open your head and put the knowledge you need into your?brain.

Product Ownership and comfort zone go in different directions. If you choose to be a Product Owner, you better continuously sharpen your skillset. Otherwise, success will be no more than an illusion.