Eight Tips for Optimizing PO-to-PO Relationships
I’ve talked before about the inherent problem with enterprise Agile: having more than one Product Owner on a project. The fact that the problem is inherent, however, doesn’t mean that enterprise Agile is flawed, it simply means that we have to accept the incongruity of what amounts to mutual ownership, shared ownership, or no ownership at all (when no PO feels like a true “owner” of any part of the “product”).
In the archetypal Scrum team, there is but one Product Owner. So enterprise Agile, with its multiple POs represents a change from that model. Agile embraces the idea of harnessing change to increase value. So it makes sense to ask, “How do we harness the inherent ‘problem’ of multiple POs to increase value for our stakeholders and satisfaction for ourselves.”
Here are eight ideas. In my experience, pursuing all eight give me the opportunity to maximize my effectiveness. But pursuing any of these with transparency and diligence will improve your results—and because you’re a Product Owner, they’ll improve your product, too.
1. Pick a PO Partner
The most obvious thing we can take advantage of on an enterprise Agile project is that we are not alone. Specifically, I recommend identifying one other PO you can think of as a true partner. As a Product Owner, you face pressure from all sides of the project. The only people who truly understand this are your co-POs. Having one person you can go to—for advice, consolation, or just to vent—is a very useful thing.
If you set out with good intention to pick a partner, you’ll eventually gravitate toward the right person among the other POs on your project. In most cases, there will be several different people you can partner with successfully. Look for two things: (1) A person you can relate to easily and who can relate to you; and (2) A person who has skills that complement, rather than amplify, your own.
The PO role is simply too expansive and ill-defined for any single PO to have everything covered. Finding a PO partner who has knowledge and skills that you don’t, who is also someone you can come to in confidence, and come to depend on for support, is invaluable.
The value of a strong PO partnership is probably best seen when we are struggling. If I struggle alone, there’s a good chance I’ll get stuck. But if I struggle in the presence of a partner, there’s a good chance that person will help me get unstuck.
This can take many forms, but the most valuable thing that I have experienced is the benefit I’ve received from another PO in helping me understand and serve the needs of stakeholders. Often, in our attempt to collaborate with stakeholders, we end up negotiating instead—and all too often we negotiate badly because negotiating is not something most of us specialize in. While stakeholder collaboration is preferred over contract negotiation, we all seem to love to negotiate on the job, such is the competitive nature of most workplace cultures.
At times, I have had a very hard time communicating effectively with stakeholders. At times, I have not clearly understood their needs or faithfully represented their requirements. At times, stakeholders have seemed to me entirely unreasonable. But notice that these assessments are based on my own survey of my own perceptions, perceptions that could be highly flawed. After all, a survey where n=1 has a margin of error of infinity.
If, however, I can check off my perceptions about stakeholder interactions with someone who knows me well, someone I trust, and someone who has exactly the same relationship to the stakeholder that I do, I can get a much more accurate read on what’s happening and gain valuable insight into how to perform my role of stakeholder advocate more successfully.
2. Practice Reciprocal Altruism
Evolutionary biologists are always working to make the case that one key element in the survival of the human race is our ability to execute acts of reciprocal altruism. In fact, the best explanation I know for the development of language in our species is that grammar is the easiest way to know “who did what for whom” so that we can remember to return the favor.
Think of this less like scorekeeping and more like investing. The altruistic things you do for other POs—the things you don’t have to do and take no immediate benefit from—are investments in your future success. The more you invest, the more likely others are to reciprocate.
I suggest the investment analogy over the scorekeeping analogy because the latter is competitive and the former is cooperative. Doing something I don’t have to do for another PO is a form of cooperation. The interesting thing about this is that it doesn’t take two of us to agree on the cooperative action. I can initiate it myself.
One of the biggest investments you can make in this regard is picking up the occasional story from another PO’s backlog when that PO’s sprint may be in jeopardy. Invariably, on a project with 5-10 teams, one or two will be doing just fine on their sprints, while several others struggle. Under normal circumstances we can’t barter our team’s resources because this amounts to reassigning work, something that is clearly in the Scrum Master’s domain. But I can always offer to do this if I say, “Let me take this to the team first.”
In fact, I have gotten into the habit whenever I receive a resource-related request of saying, “Let me take it to the team.” What I mean by this is that I am open to considering any and every way of contributing positively to the project but I can only do this through the unanimous consent of my team members.
Setting the high bar of unanimous consent may seem like saying, “I’ll never help anyone ever.” But, actually, it allows you to help everyone more often because it simultaneously displays respect to your fellow POs, to your team, and to the needs of the project as a whole.
If people know that you are always open to considering their needs, they will bring their needs to you more often. If you are transparent about the conditions under which you will be able to help, everyone will understand why you do some things at some times but not at others.
Even consideration is a form of reciprocation. This means it’s perfectly OK to come back with, “The team says we can’t do that right now.” Making the project safe for “No” is a huge achievement that will dramatically improve your organizational culture. It will also make your organization a place where others are more likely to say “Yes”.
3. Root for the Other Players
Multiple Product Owners is a recipe for competition. It’s so easy to get into the habit of zero sum thinking and “win-lose” propositions that we have to put forth a deliberate effort to build a culture where this is less likely to happen. The best way to do this is to actively root for other teams and their Product Owners.
No two teams will perform equally well across every sprint. Some will perform better, others worse. Over time, some teams may develop patterns that contribute to sustained high performance while other teams struggle, sometimes for no obvious reason. When I’m on the high performing team, it’s very easy for me to feel superior. When I’m on the other end of the scale, it’s even easier for me to feel like a failure. Neither of these positions is helpful.
My feelings of superiority, even if they are grounded in empirical evidence, set me apart from my co-POs. This is corrosive of cohesion and culture. It’s also a recipe for disaster if I get into a situation where my team hits a bump in the road. Perhaps worse is the situation where I begin to sense my own failure. Now I want to isolate myself, to pull away, to lay low hoping no one notices until I can figure out how to get things back on track. Ironically, this is the very time I need people around me.
If I’m always actively rooting for the success of other POs and their teams, we stay closer together as a community. My success is everyone’s success and, even better, the success of others is shared with me as well.
There are many ways to root for others, but two have worked well for me: (1) Publicly acknowledging the work of another team during a cross-team demo; and (2) Acknowledging the skill of another PO in private.
4. Exude Optimism
This is huge. Actually, it’s huger than huge. Seriously.
Whether it is fair that the role of eternal optimist should fall to you, a Product Owner, is irrelevant. You must play that role. If the Product Owner is not optimistic, why should the stakeholder be optimistic? Or the development team? Or management?
Optimism doesn’t mean glossing over challenges or misrepresenting hard realities and inconvenient truths. It means responding to these things with a “glass half full” attitude.
Even if you don’t know a way to solve a problem, assert that there is a solution and pledge your best effort to discover it. For every misstep that occurs, focus on the lessons learned and immediately show how you can apply that learning to the next iteration. Reframe problems as opportunities.
Enterprise projects are never a picnic in the park. They are more often a long, hard slog. At difficult points in a project lifecycle, times may be hard for everyone. It is at these crucial points where success is won or lost.
For the most part, perseverance is the key. And the energy for perseverance comes largely from optimism, from the mental calculus we all engage in about whether something is worth our effort based on our impression of its likelihood of success.
You, the Product Owner, are the public persona upon which many of these assessments are based. When things go wrong, nobody likes to move forward. Yet this is precisely the time when leadership is most required. As long as others believe that you believe there is a way, they will follow. You don’t have to have the answers, but you have to insist that the answers exist, that they will be found, and that when they are, effective action will be taking by everyone involved.
5. Know the Narrative
Large projects are like long novels. They have a narrative: a past, a present, and a projected future. As a Product Owner, you are likely to be the only person who knows the whole story.
Development teams are often protected from stakeholders and management for good reason: so they can get their work done with the fewest distractions. At the same time, stakeholders and management have a deep need to know how things are going because they bear the ultimate responsibility for success or failure.
Whether you like it or not, one of the requirements of being a PO is being a storyteller. Not a teller of tall tales, something more like a historian. You are the person who knows the most about where the project has been, where it is now, and where it is headed.
Why is it so important to know the narrative? Two reasons: (1) As I just mentioned, everyone naturally wants to know it and they know that you know it best; but more important than that is the fact that (2) When fortunes shift, people will naturally look to you for your interpretation of events.
I’ve never seen a project that didn’t have it’s low points. I’ve seen teams hit negative velocity because more time was spent in a sprint on tech debt and defects than on features. I’ve seen resources run low and executives run hot. It is at these times that many people feel like giving up or getting away.
And that’s the last thing a struggling project needs.
I have a talk I give called “Great Expectations”. It’s about how most of us start new projects with high hopes even though every project we’ve ever been on has hit rock bottom at one or more points in time. There’s always a moment in the talk where I ask the audience, “What do you do when you don’t know what to do?” Astoundingly, more than half the people say something like, “Start looking for another job.”
This is why we suffer so many colossal failures on enterprise projects: at the very time when we need to pull together, half of us have one foot out the door.
This is the crucial moment when the Product Owner must construct a new narrative for a new outcome. Again, this does not mean diminishing difficulties or spinning circumstances. It means honestly and transparently projecting a way out, a path, a possibility—better yet, two or three because one of them certainly won’t work.
On my last project, we hit the wall three or four times in 18 months. Each time, people thought the project might be cancelled, that we would lose headcount, that teams might be shuffled and responsibilities changed.
Time and again, people asked me about these things in private. They were right. Times were tough. And the easiest thing for me to do would have been to console them and send them to my favorite headhunter.
But that wouldn’t have been right or smart. It wouldn’t have been right because I wouldn’t have been advising my friends based on my belief that we would, indeed, find a way to be successful. And it wouldn’t be smart because encouraging people to jump ship when you really need all hands on deck is almost a form of self-sabotage. Think how you might feel if the most productive engineer on your team left for another job right at the worst time in your project.
Things were really bad at certain times on our project (though we ultimately delivered). Concerns were justified. But panic is never justified—and even if it is, it isn’t helpful. So what did I do?
I offered plausible reassurance based on three things that were part of the project’s narrative: (1) Past history (Did anything bad happen the last time?); (2) Current circumstances (What value would the company see at this point in stopping the project?); and (3) Reasonable forecasts (If we can get through this, doesn’t it seem like there will be a big upside for the company down the road?”)
These were all legitimate and honest ways of responding based on facts and, in the case of future projections, reasonable assumptions that could easily be supported by facts.
It is especially important that you project optimism to your fellow Product Owners because they are keepers of the narrative, too. When times are tough, it’s important that we all stick together. When things seem unstable, people crave stability. Projecting optimism when times are tough is the best way to create the feeling of stability that people need to do their best work even if such stability doesn’t, or can’t, exist.
6. Bestow Respect
I was giving an all-day talk at a conference a while back and I discovered that some of the participants did not understand the circular nature of respect—and that this was getting in the way of their own success and the success of their teams.
One engineer said, “I don’t respect my manager. He makes too many bad decisions.” Another said, “I don’t respect my Scrum Master. His technical knowledge is insufficient.” And so on.
These are unfortunate situations. But they are also common ones. The reason they are so common is that disrespect (which is what these two people were expressing) is a vicious cycle. How likely was it, I asked, that either of the people they did not respect respected them?
Not very likely.
Here’s the vicious cycle part: If we have decided that each of us must earn the respect of the other, then what happens when our success depends on collaboration? Was it possible, I asked the people in the workshop, that the manager and the Scrum Master need your help in order to be successful?
Well, yes, they supposed it might be.
And you certainly need to be respected in order to be as successful as you can be, right?
So what happens when two parties who depend on each other’s success are waiting impatiently and judgmentally for that success to emerge—while withholding respect on the condition that it emerges?
In this situation, both parties likely fail, respect declines, failure escalates, respect bottoms out completely, and soon, the respect none of us can earn from the other becomes palpable friction that slows our progress to a crawl or halts it altogether because we’re both withholding based on a condition of mutual disrespect in which neither of us can deliver.
Many of us have this notion that respect must be earned. While understandable, and very human, this is a potentially disastrous attitude to take and a toxic culture to take part in.
Respect is bestowed, not earned. I’ll say that again in bigger letters this time: RESPECT IS BESTOWED, NOT EARNED.
Respect must be the default condition. And, in fact, if we truly want to be successful, respect must be a constant because without it, we lose much of the power we have to solve problems collaboratively. And on enterprise projects, most problems need to be solved collaboratively.
This idea about the bestowal of respect, its default nature, and its constancy, is particularly crucial among Product Owners. If POs don’t respect each other, how can they depend on each other to collectively deliver a product? And if they can’t depend on each other because they don’t respect each other, what is the likelihood that they will collaborate to solve hard problems?
And if they don’t collaborate to solve hard problems? You guessed it: ownership declines until, really, no one owns the product because the entire PO group has collectively abdicated its most basic responsibility.
As difficult as it can be at times, maintaining respect for others (and for ourselves, too) is critical to our success. Every member of the PO group on an enterprise project must respect every other member because every other person on the project is looking for leadership from the PO group.
7. Learn From Your Peers
There really is no standard playbook for POs on enterprise projects. There are books, courses, coaches, certifications, etc. And these are helpful. But they tend to focus on the tasks and competencies of Product Ownership as a generic functional role. You need to understand the specifics of your job as it exists within your specific project.
This why it’s so important to learn from each other.
Unlike engineering, which is a relatively mature concept, Product Ownership came into being only in the last decade as Scrum became popular. That means that most POs don’t have a lifetime of experience and wisdom to fall back on.
What became obvious to me on my last project was that there was something I could learn from each of the other Product Owners. One was particularly good with the stakeholder. One was very technical. One was extremely conscientious and always very well prepared. One had a very interesting talent of being able to identify a team problem and express it succinctly in a single sentence.
At this point in time, I know there are master engineers, wise architects, well-tested QA people, and so forth. There are also many standard references for the technical aspects of software development. But nothing like this exist for Product Owners. We are probably still a decade away from having the definitive PO playbook in front of us.
In some sense, we’re all still trying to figure out how best to do our jobs. And the Product Owner’s job changes more with each new project than almost anyone else’s. So even those who have served on several projects over several years may not know everything they need to know on their current project.
Agile software development is all about learning. And in many ways, POs have the most to learn. It’s not that POs lack skill or experience, it’s just the nature of the work that each product a person owns will likely be a new and different experience.
Because the Product Owner role is, by definition, a singular role, Product Owners tend to be individualists. On behalf of stakeholders, they are responsible for holding the vision of the project. But this doesn’t mean they always have a vision of how to be successful in delivering it.
Acknowledge this with your co-POs. Maintain a collective vision of success and muster the courage to achieve it. But move forward together in a spirit of inquiry. Nobody has all the answers. And in many cases, the answers are unknowable until very late in a project. While having more than one Product Owner has its challenges, it also has the big advantage that several heads are usually smarter than one.
8. Leverage Collective Domain Expertise
As the Product Owner, you are required to have or to develop deep expertise in the problem domain of your project. If you’re lucky to enter a project with years of domain experience, that’s great. But it’s hard to have both years of domain experience and years of Product Ownership experience because Product Owners typically don’t spend years working within a single domain.
This means that you must leverage the domain experience of others.
Your first source for domain experience should be the other Product Owners on the team. Instead of competing to see who knows the most about what, cooperate to first discover and then act upon the domain experience distributed across the group. But don’t count on the PO group entirely to know everything that needs to be known.
Stakeholders are, in some sense, experts in their own domain. But here again, different Product Owners will have different experiences of their stakeholders. And in many situations, stakeholders won’t actually know their domain as well as you might hope. Often, people needing something need it for a very simple reason: they’ve never had it because they’ve never been able to define what it is.
Don’t disrespect the domain. Don’t trivialize it. And absolutely do not take for granted that every PO sees the domain the same way you do. Remember that an enterprise project with eight teams has eight POs. Ideally, those eight minds must in some sense function as one. The only way that’s going to happen is if you leverage the collective domain expertise of all POs on the project.
With 100 to 150 people working on a project, and eight to twelve people “owning” it, there’s bound to be some chaos in the machine. The best thing a group of Product Owners can do is strive to continually harmonize the different voices on the project, to refine and synthesize all the ideas floating about, to distill the essence of what it is the teams are producing, to find order in chaos, and to communicate all of this clearly and concisely to everyone else on the rest of the project.
Only through carefully considered collective coordination (yes, that’s a quadruple alliteration for a reason: it’s really important) can a group of POs serve their teams, their project, and their stakeholder well.