Playing Safe Ensures Mediocrity for Product Owners
By: David Pereira
Tags: Agile, Product Management, Leadership, Software Development, Startup

Don’t Run From Conflicts. Engage in Passionate Discussions.

Being a Product Owner is exciting yet daunting. Every day you have tons of decisions awaiting you, but one is quite impactful: do you want your day to be exciting or boring? If you want an exciting day, don’t run from conflicts. Otherwise, your day is going to be pretty dull.

A typical day for a Product Owner has endless opportunities for conflicts; how you deal with them will ultimately define how successful you can be. Running away from conflicts will lead you to fake harmony and slower progress. But if you are not afraid of conflicts, you’ve got great chances of success.

“It’s as simple as this. When people don’t unload their opinions and feel like they’ve been listened to, they won’t really get on board.”

― Patrick Lencioni, The Five Dysfunctions of a Team: A Leadership Fable

Stakeholders’ happiness is pointless. Alignment is what matters.

Wherever you work as a Product Owner, stakeholders will always have more wishes than the Scrum Team’s development capacity. If you aim to please everyone by doing a little bit of everything, frustration is inevitable.

Although stakeholders may argue everything is essential and urgent, we all know that’s just their perception. But if you try to negotiate with each stakeholder at a time, you will have a hard time coming to an agreement. A rather bold approach is to have a conversation with all stakeholders at once. But guess what will happen? Conflicts.

Once you have all stakeholders in the same meeting, the only certainty you have is: conflicts. To reach commitment, as a Product Owner, you should foster conflicting discussions. If everyone has the chance of unloading their perspectives, they can commit to the decisions. A successful way of conducting this meeting could be:

Set a goal to achieve : the Product Owner shares the goal to achieve. For example, “we have to double our recurring users by the end of the quarter. What could we do to make it happen?”

: the Product Owner shares the goal to achieve. For example, “we have to double our recurring users by the end of the quarter. What could we do to make it happen?” Be a facilitator : observe how the stakeholders interact. Search for unsolved conflicts and bring them to the table. For example, John has a request disconnected to the goal, but he has the highest pay-check in the room. If nobody challenges him, you should do it. You could ask: “John, I don’t see how your request puts us closer to the goal. Could you help us understand it?”

: observe how the stakeholders interact. Search for unsolved conflicts and bring them to the table. For example, John has a request disconnected to the goal, but he has the highest pay-check in the room. If nobody challenges him, you should do it. You could ask: “John, I don’t see how your request puts us closer to the goal. Could you help us understand it?” Clear agreements: as the stakeholders unload their opinions; you need to make clear agreements. Write it down what will be done and what will not be done. Ask the group if they can commit to that; if not, ask why.

A joint prioritization meeting works if you ensure everyone shares their opinion. That’s why you should have a proper timebox for it. Don’t try to shorten the meeting. Everyone has to express their opinion. Otherwise, forget about commitment.

The result of the meeting is the alignment between the stakeholders. Not everyone will leave the room with something prioritized for the upcoming sprints. Still, everyone should be happy because the group made the right decisions for the product. Reaching commitment is what matters the most.

Photo by Headway on Unsplash

If your choice is to play safe and avoid conflicts with stakeholders, they will annoy you with new wishes every day. By saying “yes” to everything, you ensure the unhappiness of everyone.

Developers will be fed up with interruptions.

End-users will be lost with a confusing product.

Stakeholders will be unhappy if no real value is delivered.

Tension between Developers and Product Owners lead to meaningful solutions.

Product Owners are responsible for defining which problems are worth solving and why to work on them. The entire Scrum Team is responsible for the solution, and the Developers are accountable for the implementation. A thin line separates Product Owners and Developers; I call it the how line. If Product Owners step on it, Developers may not welcome them with arms wide open.

From my experience, if Developers don’t challenge the Product Owner, we risk building too simple solutions. And suppose Product Owners don’t challenge Developers. In that case, we risk to develop solutions that are too complex for the problem we want to solve. Conflict is a mandatory ingredient for success. A Scrum Team cannot be successful by playing safe.

Suppose the Product Owner brings a straightforward solution to implement instead of a problem to solve. Developers should ask what kind of problem the Product Owner wants to be solved instead of discussing how to implement the solution without knowing the problem.

Suppose Developers try to over-engineer the implementation to avoid non-existing problems. Product Owners should bring more context to ensure Developers are not wasting their time by building something not needed.

Simplicity — the art of maximizing the amount

of work not done — is essential. — Agile Manifesto

Product Owners and Developers may not appreciate being often challenged. It might create a tense environment, but it will surely avoid focusing on something that doesn’t matter. Open discussions lead to discovery, while no discussions lead to mediocrity.

A Scrum Team without conflicts will never be a high-performing team.

The fear of conflict blocks teams from evolving. Patrick Lencioni insists that teams without trust cannot become an outstanding team because they will live in an artificial harmony.