The product job: to say no.

We can consider the Product Owner to be the main stakeholder. She should own the product and determine direction. The reality is that the Product Owner role is different from that of a project manager, since she has the passion, the vision, and, unlike a project manager, has to say no to people. Let me explain.

On a typical project, the team delivers a certain amount of story points per sprint. But it’s common to see that once stakeholders notice what the team is capable of doing, they start asking for more and more stuff. Imagine that certain project has around ten stakeholders, and each one of them suggests a new idea, which represents, let's say, two story points. The problem is that the team is only capable of delivering ten story points per sprint, and if we let this situation run out of control, then we will end with an infinite queue of pending work.

The Product Owner is the one in charge of prioritizing the work queue. More than that, he is the one in charge of preventing the creation of that infinite queue of features, and the only way to do it is by saying NO to stakeholders. At least from time to time.

It's true that the Product Owner must develop a good relationship with the stakeholders, and part of this is helping them decide what should or shouldn't be part of the product backlog. By having a clear product vision, a well-studied market, and regular interviews with end users, the Product Owner should be able to determine what features are the best for the product.

The business value produced by each feature tells the PO what should be the priority for each story. Let me clarify, when I say value I'm not talking about the size in story points, I talk about the actual ROI of each story.

The Product Owner should be skilled enough to find out the real value of each feature, by studying end-user behavior and market trends. Let me give you an example of that.

"Jim Employee" is part of the marketing department of a graphic design company that sells templates to graphic designers. On a sprint review, Jim proposed to add a small countdown clock right below the daily offer section. The only problem is that his requirement was down the road in the backlog because of the urgent features that the accounting department has requested.

"Mark Product-Owner" decided to support Jim with his idea and he put it at the very beginning of the next sprint. After an (expected) argument with accounting, he stood his ground, and the team developed Jim's idea.

At the end, that small requirement increased sales, and it wouldn't have been possible without Mark's support.

What if one of the stakeholders proposes a simple change to the interface that improves the end product a whole lot? If the stakeholder doesn’t have enough influence and there’s a lot of pending work on the backlog, chances are that the feature could stay in the backlog forever. It is the product owner’s job to support good ideas that have high value.

It is true that the scrum master is the one in charge of making sure that Scrum is followed as intended. However, there is just one person that can say no to the Scrum Master and change a sprint’s path or add features, and that is the Product Owner.

According to Voltaire, “With great power comes great responsibility” and, in this case, that quote applies very well. The Product Owner is the only one that can say no to the Scrum Master, and if she doesn't use this power wisely the team could end with a useless Scrum implementation.

But, when can a Product Owner interrupt a sprint? There is no rule for this; it depends on the urgency of the requirement. As a rough guideline, I could say that most of the time a sprint can only be interrupted because of the appearance of an urgent bug on the production server. It is the Product Owner and the Scrum Master’s job to exert their judgement and decide when a sprint can be interrupted for the sake of the project’s health. Nonetheless, the Product Owner has the last word.

It's the team’s job to think outside-the-box. However if they didn’t have any external boundaries to keep them in check, the product could easily become something different than what the market, users, and the company need and want.

One example of this happened to me when I was Product Owner of a project that started as a small demo to a group of investors. After a few months of work it became a more serious networking application.

On a Sprint Review Meeting, one of the most experienced developers of the team asked me to spend a significant part of the upcoming sprint time on redefining the architecture of the application. He explained to me that the design that we had up to that point didn’t fully support the new requirements, and we had to do it right away.

At that time, we just had one "urgent feature" to develop, so it was easy for me to say yes to that. I wasn't sure I had made the right decision until some time passed, and the velocity of the team went up. When I asked about what changed, they told me that the new architecture was allowing them to develop things faster.

Later, I received a suggestion from the same developer about moving to a NoSQL database. According to him, that database model offered better compatibility with what the product was becoming. I analyzed the situation, asked for some advice and I decided that it wasn't a good idea to proceed at that moment with the change. We were far away from launching the product and, even though we were near to the deadline, the improvement on the application’s response time wouldn't be significant.

In other words, the Product Owner is in charge of making room where the team can experiment with their ideas.

I'd say that this is the hardest part of the work since this involves a lot of what some people call "soft skills". It involves leadership, friendliness, persuasion, and more.

The Product Owner must have a good relationship with her team and become the main bearer of the product’s vision. She or he should maintain a good relationship with the Scrum Master since he will help her to mediate difficult situations and will support her with the improvement of the Product Owner’s performance.  Finally, she should maintain positive relationships with the stakeholders. They are her customers, investors, and end-users. Without them, the project wouldn't be possible.

The Product Owner role is a complex one that needs skills and knowledge in professional communication, user experience, and market research. At TangoSource, we have internal Product Owners who act as the eyes and ears of our customers. They are in charge of interviewing the stakeholders, studying the market trends, and defining the features of the project. Ultimately, they’re responsible for the results at the end of the sprint.

Want to know more about how we run Scrum within the company? Drop me a line or follow me on Twitter, I’ll be glad to strike a conversation.

Thanks for reading!