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.

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?

Yes, obviously.

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.

Harmonizing Chaos

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.

Like this:

Owner to Owner

Enterprise Agile presents many fascinating challenges. One of the most fascinating is the notion of multiple Product Owners on a single project. If you think about it, this is a recipe for disaster. “Collective Code Ownership” is something engineers have worked out very well over the last two decades or so. But the idea of collective product ownership, and its successful execution, has not been thoroughly addressed as far as I know.

The Product Owner role is a classic Scrum role. In the official Scrum Guide, Jeff Sutherland and Ken Schwaber make clear and unambiguous statements from which one could easily infer that projects with multiple Product Owners have inherent challenges:

“The Product Owner is the sole person responsible for managing the Product Backlog.”

“The Product Owner is one person, not a committee.”

“For the Product Owner to succeed, the entire organization must respect his or her decisions.”

Finally, Sutherland and Schwaber assert the immutable nature of Scrum itself which strongly suggests that the very framework in which the Product Owner role is defined only makes sense when there is but one.

“Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.”

So with multiple teams and multiple Product Owners working together on a large enterprise project, we are likely to find ourselves with too many chiefs, too many chefs, too many egos and, as a result, often behind 8-balls, up creeks without paddles, between rocks and hard places, and continually searching for metaphors, idioms, and aphorisms to describe our challenges—because we don’t have clear language with which to describe them directly.

How do we know when we’ve got a serious problem? When we know there’s something wrong and we can’t even describe it very well.

And Then It Really Gets Complicated

While there are relationships you will have that are more important than your relationship with other Product Owners, PO-to-PO relationships are potentially the most complicated. The first complication is a classic one: How does shared ownership of a product work? The second complication is more specific to enterprise Agile projects: How do a set of co-equal “owners” each take full ownership of something when each only has a part, when so many dependencies are likely to arise across teams, and when there are shifts in workload, variance in team performance, and differences in team expertise with regard to specific parts of a large system?

There are many little Do’s and Don’ts that I will talk about in subsequent posts regarding PO-to-PO relationships, but I want to start here with a story about a situation I was in—one that I imagine is fairly common and for which there is no standardized “process” or “structural” solution that I’m aware of. It’s a distinctly human problem, one that I think is best addressed through human interaction.

Story Time

Product Owner A has been working with her team on part of Project X for eight sprints. Meanwhile, Product Owner B (yours truly) has just finished up working with his team on a different project. Management would like to put a little more horsepower behind the work that Product Owner A’s team has been doing, and now there’s a free team available. How lovely.

For Scrum Masters, engineers, architects, and QA’s this is not such a big deal. But for Product Owner B there’s a problem: What’s my status relative to Product Owner A? Do I work for her? If so, what do I really “own”? If not, how do we deal with co-ownership, especially when she’s eight sprints ahead of me on understanding the nature of the product over which she has already established sole ownership?

This has all the makings of a turf war. Does she have to share her product somehow? Or did I just get demoted to work under her leadership? I don’t even understand the work her team has been doing. Technically, we occupy the same level on the org chart, but she’s ahead of me on this part of the work. Having finished something up with my team, I thought I was moving on to bigger and better things. Now it seems I’ve moved on to a whole set of bigger and not better problems.

Problems Schmoblems

It’s true what they say: the solution to every problem in life can be found in a Broadway musical. But I’ll get to that shortly.

The key to making this somewhat awkward situation work out for everyone is for me to create a good relationship with my new PO partner. There will be no clean technical or procedural solutions here, only personal ones. The fundamental challenge we face in developing good relationships is that we don’t feel safe to develop them.

Relationships seem inherently risky. How do we introduce ourselves? What do we say to each other beyond the obligatory small talk required of our roles? How are we supposed to interact with each other? We don’t exactly know. And not knowing feels unsafe, especially if we are new to a group, in a junior role, or from a different culture.

Things are even harder than that when there are no guideline for us to rely on as is the case with the multi-PO problem. What boundary conditions exist in this specific context to keep us from making huge mistakes? How are we supposed to know how to interact at all, let alone optimally?

Gradually, over a long period of time, we may get used to each other, we may establish weak but workable norms for our interactions, but we probably won’t really get to know each other—at least not well enough to support high-performance work relationships. The longer this not-knowing of each other goes on, the more likely we are to maintain walls between us until an unproductive privacy becomes the default culture of our project.

This is even more critical in the multi-PO situation I describe. There has been little written or researched about how Product Owners might ideally interact, especially when one of them is a lot farther along on a given project. Even the small talk of our required roles isn’t something we can fall back on because co-Product Owners don’t have clear roles and “junior” Product Owners aren’t truly Product Owners at all.

Give My Regards to Broadway

So what’s the solution? Catch a performance of Rodgers and Hammerstein’s The King and I.(Even if it doesn’t fix my problem, it’s an excuse to see a show, right?)

As the story goes, in the mid-19th century, the King of Siam hired British school teacher, Anna Leonowens to educate his royal princes and princesses—all 67 of them. In a classic scene, a naturally nervous Anna meets her students for the first time and wins them over with a now-famous song:

Getting to know you, Getting to know all about you. Getting to like you, Getting to hope you like me.

Getting to know you, Putting it my way, But nicely, You are precisely, My cup of tea.

Anna’s message endears her to the children. Similarly, their happy reaction endears them to her. What’s the takeaway? The key to feeling safe with people is helping them get to know you, and you them—ideally with a lovely song, but in most workplaces this is not a requirement.

Getting to know each other, however, is a requirement if we want to create a culture that supports high performance.

This is not about participating in contrived team building exercises or pro forma introductions. It’s about making a conscious effort to discover who your co-workers are, and to make sure they discover who you are, too.

In this case—ripped from the drama of real life—I was the “new” Product Owner bringing my team onto the established Product Owner’s project. My team was, of course, looking to me for stories so they could get working. The first move, therefore, was mine: I had to get to know my co-PO and I had to figure out what our respective roles were going to be.

Getting to Know You

I had just wrapped up 16 months as a Product Owner on a large, tense, and often tedious enterprise effort when I was assigned to PO a completely different project, one that would require close coordination with a pre-existing team at my company’s headquarters, 500 miles to the north. I knew my own team members well but I didn’t know the PO at the home office at all—and it seemed pretty clear to me that she “owned” the project because she was, in fact, the original owner, and she was so far into it with her team.

Miranda had been PO-ing the effort already for eight sprints. My immediate task was to derive requirements and produce stories based on her backlog so that my team could code the plumbing for her vision of a system that would support applications and the storage of user data. I was also told that she was ambitious and that she liked to work fast.

Already intimidated, I thought my safest strategy might be to avoid personal contact altogether by working entirely off the project backlog without actually ever communicating directly. (Look at me! Taking the cowardly low road right from the start. But that’s what we often choose to do when we don’t feel safe.)

And so I began:

Log into Jira.

Have mild panic attack as I encounter 300+ user stories, most of which I don’t understand.

See who wants to go out for lunch so I can forget about this for a while.

There was no getting around it. Not only would I have to talk to Miranda, I would have to talk to her immediately just to plan my first sprint because I desperately needed her help to get up to speed on the project. (So much for that escapist lunch I wanted.)

Who Ya Gonna Call?

Calling an ambitious and potentially impatient person you’ve never met and saying “Hi, I need about six hours of your time between now and tomorrow afternoon to figure out my job.” is not a getting-to-know-you-strategy I recommend.

It then occurred to me that I knew absolutely nothing of any personal substance about this person. No one in our office had worked closely with her. Everything I’d been told about her was really second-hand information.

So I threw up a Hail Mary. I went to the employee directory praying for a miracle tidbit of useful personal information. Lo and behold, at the bottom of her profile in a text box labeled “Hobbies and Interests,” I read the following: “I play NLHE. Sometimes at WSOP tourneys. Hoping to make it to The Main Event some day.”

Huh?

A Winning Bet!

A few minutes on the Google revealed that she was a professional gambler. Her game of choice was No Limit [Texas] Hold’Em. She was a serious player, good enough to play in official World Series of Poker events. She hoped to qualify for the world championship some year.

By chance, I had stumbled onto one of her affinities.

I love the word “affinities” not only for what it means (“a natural liking for something”) but also for its last four letters which spell the word “ties”. I think of affinities as things that are a part of who we are to such an extent that we are literally tied to them.

I also now realized that what some people may have interpreted as her ambitious and impatient nature might just be the kind of gutsy competitiveness one would expect of a serious poker player.

You Never Get a Second Chance to Make a First Impression

I knew my first interaction with Miranda would set the tone for many interactions to come. I also knew that I needed her help. But before I asked for the help, I tried to make a connection.

I sent her a short e-mail introducing myself and at the end I asked her a question about poker. I made no reference whatsoever to the project, what I needed to do, what our roles might be, etc. I didn’t suggest a Skype call to begin talking about these things. This was purely a social call.

She responded right away and asked me if I was a poker player. (Notice again that we’re not talking about our shared project.) Even though I’m not a poker player, I continued the thread by asking her a few more questions about it, relying on Google and Wikipedia to shore up what little I knew about competition card play so I could stay in the game. This kicked off a thread of brief messages back and forth throughout the day.

I still didn’t even mention the challenges I had in getting up to speed on the project. But this time, it wasn’t avoidance that was driving me, it was the opportunity I felt to establish a good relationship. By talking to the person, and not about the project, I was building something far more valuable in the long run than whatever technical or procedural knowledge I might need.

Toward the end of the day I got lucky and found something we had in common with regard to the game of poker. The poker I have played wouldn’t even qualify as real gambling. It’s mostly just nickel and dime stuff from my high school and college years. But I had seen some great poker movies over the years, so I took a shot and sent her something like this: “My favorite poker movies are Cincinnati Kid, Rounders, and California Split. You?” She writes back five minutes later and says, “Oh, Rounders, definitely.”

Now I knew I was in. I had made a connection. We had some very, very small bit of shared history now (one movie that we both liked) but that’s a lot compared to what I started with.

At the end of the day, she sent me a message, this time not about poker but about the project. (OK, here we go. Deep breath. What’s the worst that can happen? Keep rationalizing away your fears. Yeah, that’s the ticket!)

In part, her message read: “You’ve probably seen the backlog. Sorry it’s such a mess. Do you have time on Monday for a Skype call so I can catch you up? I’ll work a little over the weekend to get things more organized.”

Rodgers and Hammerstein Were Right

Who isn’t at least a little nervous about interacting with a co-worker for the very first time? The unknown is inherently unsafe. When it comes to people, getting to know them and letting them get to know you often feels un-safest of all, but it is almost always the best thing to do.

Getting to know people, especially through their affinities, is often the easiest root. Most people love talking about their affinities. All we have to do to get things started is ask them a question or two. As the discussion expands, we often find commonalities, even if one person’s affinity is merely another’s curiosity.

But affinities are just the beginning. The first line of the famous song is, “Getting to know you”; the second is “Getting to know all about you.” This takes more time and a lot more effort. But our investment here pays rich dividends when it comes to creating highly productive work relationships.

Why Bother?

How well do we need to know someone we work with? And what does it take to know a person that well? Those are important questions but one question is even more important: Why bother?

Well, in my case, and in most PO-to-PO situations, there’s plenty of reason to bother. The project I had just come off of suffered from two common and devastating problems with multiple PO’s: we didn’t agree on the product we were making together and eventually there emerged a two-tiered PO hierarchy with more experienced PO’s treating less senior PO’s as though the latter group really did work for the former.

Far from ideal, I think now in retrospect that the dysfunction of our PO group was a key factor in the disappointment of our work together. We finished the project, released the software, and nobody got in any big fights. But the work we did was far from spectacular, and at times the friction was high and the tension was tedious.

In retrospect, it’s very easy for me to see now that the PO’s I took the time to develop good relationships with were the ones with whom I worked best. Had I put forth the same effort with all of my PO pals, I know that I would have been more effective and happier. Had we all worked hard to build and maintain good relationships with each other, I think the project would have turned out dramatically differently—much better for us and, especially, for the stakeholder.

There are Teams and Then There are Teams of Teams

We work in teams because the task before us is greater than that which can be completed by one person alone. If we could complete a task by ourselves, being part of a team wouldn’t have much value, at least as far as productivity was concerned. We might even be less productive because of time and energy spent on team interactions.

The systems we build today are huge. Rarely does a truly valuable project exist that can be completed by a single person in a reasonable timeframe—or even a single team. Scrum masters seem to have this figured out. Even if you’re not a fan of “Scrum of Scrums” at least it exists.

But what do groups of Product Owners have? Only the quality of the relationships between them.

Because we can’t solve problems by ourselves, we need help from others. Highly accomplished individualists that we are, we tend to think of ourselves as self-sufficient. But on most projects that’s an illusion. The reality is that we need to help each other a lot to get most things done. This is especially true if we are one among many Product Owners on the same project.

This is why it makes sense to know our PO partners well. The better we know each other, the more likely we are to cooperate well together. And because the PO role is prototypically a singular function of ownership, multiple PO’s on the same project have to figure out ways to cooperate especially well in order to be sure we’re all making the same product and, to the best extent possible, speaking to stakeholders with one voice. Problems are going to come up, systems are going to break down. The quality of our relationships is what gets us through the low periods and supports the potential for high performance.

Like this:

Welcome to Grand Central Station

I began making products way back in the Pre-Agile-ite Era in the History of Software Development—roughly the mid-1980s to the mid-1990s. I realized early on that what I enjoyed most was being in the middle of it all, working with developers, designers, marketing, management, end users—the list never ended and I liked that a lot.

In the bright shiny world of contemporary Agile software development, being a Product Owner is even better in this regard because “the middle of it all” is more precisely defined. There are fewer turf wars to fight; everyone knows (or should know) why you’re in a particular meeting asking particular questions.

My last project was the biggest I have ever been on (100+ people, $75 million budget, 18 months to v1.0). I had what I now think of as “the full-on enterprise Agile experience”. I was in the middle of it all and there was a lot more “all” than I had ever been in the middle of before. I felt like I was going to work every day at Grand Central Station.

A Metaphor

Grand Central Station is where everybody goes to get from where they are to where they need to be. The Product Owner is the person everyone goes to to get the product from where it is to where it needs to be. Waves of humanity flow constantly through the Product Owner just as they might flow through a person standing in the middle of Grand Central Station at rush hour. The trick is not to control the flow but to know the flow and direct the flow with as little friction as possible so that everything ends up at its appointed destination.

Product ownership is a game of expectations: When will it ship? What resources are required? How do we know that our idea of MVP will be our users’ idea of MVP?. But it’s not about expectations management. It’s not “under promise and over deliver”. It’s “answer questions and tell the truth.” Why is truth-telling better than expectations management? Because expectations management is dishonest by definition.

At some point your dishonesty will be exposed and you will lose the trust and support you need to be successful. The worst thing that can happen if you tell the truth is that some people may not like the truth when you tell it to them. But telling people that their train has been delayed and will arrive an hour late is far better than allowing them to believe it is arriving on time and dealing with every story they make up about you when it doesn’t.

Another Metaphor?

There’s a view of Product Ownership as “running the show”: You are not conducting trains, you are the conductor of The Software Development Symphony Orchestra. Your backlog is the score. Your stories cue the players. You face the music when it comes to stakeholder and management interactions.

This is a valid take on the PO role. But it’s not one I like because the POs I’ve seen who work this way tend to be more competitive than collaborative. The “PO as Conductor” metaphor smells to me of ego and eccentricity, of command and control. It tends to set the PO above and apart from the project, just as the conductor of an orchestra stands on a platform above and apart from the players.

Any time you think you’re in charge of anything, think again. You’re the Product Owner, not the Product President, Commander and Chief of the Armed Product Forces, or master of the Bully Product Pulpit. To me, this “commanding” or “conducting” way of thinking is bad for relationships. And relationships are the currency of successful Product Ownership.

Relationships or Transactions?

It’s tempting to view your work as a huge series of transactions: taking stories to the team, getting requirements from the stakeholder, accepting stories from engineers, giving sprint demos, and so on—each has a built-in quid pro quo, simple trade of services from provider to provider: you do your job, everyone does theirs, we all go home happy. This is the fantasyland view of Product Ownership that you’ll often find in books and courses.

Real life, as we all know, is a bit more complicated. It’s tempting to see the work of Product Ownership as simply trading quid for quo all the time and not worrying too much about who you’re trading with. Everything’s a transaction, nothing’s personal; it’s cut and dried, black and white, professional, reasonable, rational—no emotional labor required.

Sounds perfect, right? But it’s not. The truth of transactional product ownership is that all transactions are not created equal; some are harder than others, and others are simply impossible.

In the quid pro quo approach, there are going to be times when you don’t have the quid to trade for the quo. There are times when there are no consumers for what you are trying to sell (a new stakeholder-demanded feature, a new goal from management) and no providers of what you would like to buy (a little more time, budget, or even just an extra dev server). In these situations, transactions cannot go through.

This is when projects—and sometimes careers—grind to a halt. Need a favor from someone? Can’t get it. Need the stakeholder to see reason? Not gonna happen. Need management to back off? Fuhgedaboutit.

In a transactional approach, when stakeholders want functionality that could drastically change scope, there’s no easy way to give it to them. When management seeks to impose unworkable time and budget constraints, knee-jerk capitulation will make your team think you’re a jerk. When your engineers are running on empty, and you need them to go the extra mile, no quid pro quo buying a few pizzas and some Mountain Dew isn’t going to cut it; the only reason they’ll go the distance is because you ask them to and because they know you’d never ask if it didn’t matter.

In these kinds of situations—and you’ll be in them all the time—the only sustainable strategy is to leverage relationships. But you can do this only to the extent that such leverage exists. And it doesn’t exist unless you create it—early and often.

Stakeholders have a right to demand anything they want. So does management. And you won’t make your team do anything they don’t really want to do because, among other things, you don’t control the actions of your teams; Agile organizations are much flatter than traditional organizations. It may seem like you are “in charge” of your team but you’re not; the team is in charge of itself.

Handling Product Ownership as a series of transactions puts you in the position of endless negotiating, promise-making, cajoling, coercing, and capitulating. Things like excellence, engagement, collaboration, contribution, meaning, satisfaction, aspiration—all the things that really matter to people—will not be found, at least not easily.

Instead of working for everyone else, or trying to get everyone else to work for you, it’s better to work with everyone one else. The success of this approach is predicated almost entirely on the quality of the relationships you establish with people. But if true success is what you seek, this is the work you’ll undertake to achieve it.

Back to the Station

Getting thousands of people and hundreds of trains where they want to go seems like a challenge that cries out for processes and tools. But shift happens. Dates change. Budgets don’t balance. Stuff breaks down. Things fall apart. The center does not hold. The world tilts off its axis. And then you have to go to a person and work with them to right it—with no tricks, tools, or trades, just a strong relationship you will desperately need in order to get things back on track.

Living at your laptop, running Rally like a rockstar, is great. But even the best laid plans of the best POs often go awry. This is when your key relationships become the key to your success. Everything comes and goes through Grand Central Station. At virtually every moment, you will find yourself in between one or more parties and one or more other parties. It’s better to be between good relationships than between rocks and hard places.

Roles and Relationships

As Agile scales up to the up to the enterprise, we begin to see it formalize. And as it becomes more formalized, it becomes less Agile. There is nothing wrong with this; it’s just what happens. When we’re one happy little scrum team working in our happy little startup garage, we have more flexibility. But when we are 100 or 1000, we pay a cost for working at scale, and that cost is usually some degree of agility.

That being said, this loss of agility is compensated for by tremendous gains in capacity. We may not do things as nimbly as we could if we were small but we can do things we would never be able to do at all because they are just so big that one team of eight or ten people simply can’t get everything done.

Agile at enterprise scale, therefore, is heavily role-based. As such, people can seem like interchangeable parts. For the organization itself, this has obvious appeal. But it doesn’t produce optimal results in the long run because strict role-based formalisms are antithetical to the Agile mindset. When Agile becomes formalized, it ceases to be agile.

In highly formalized systems, we have to look harder for ways to improve outcomes beyond the point of formalization. Processes and tools, systems and structures tend to play themselves out over time. In the worst cases, they ossify and are rendered useless because new and badly needed changes can’t be operationalized quickly enough to meet the demands of a highly competitive marketplace and a rapidly changing world.

So how do we deal with this? Where do we find the Deus ex Machina, (the “soul of a new machine” as Tracy Kidder coined it) from where comes the magical, mystical agent of intervention that restarts the engine of change, rejuvenates a geriatric system, and restores lost agility?

Relationships.

The difference is in the quality of the human relationships we have. Better relationships equals better results through agreements kept, friction reduced, and increased workplace satisfaction that is the catalyst of greater productivity. Strong working relationships make up for the loss of agility as we take Agile to scale because relationships transcend roles. Strong relationships bring out the best in each of us by increasing our personal agility. And it is this increase in personal agility at the micro level that replaces and even exceeds organizational agility lost at the macro level.

What follows are brief thoughts about the common roles you’ll encounter and the uncommon relationships you will build. We will explore each of these roles in more depth in future installments of this series.

PO to Scrum Master

Requirements come through you to the engineers on your team via your Scrum Master.

Your relationship with your Scrum Master should be your closest relationship. Reach agreement early about how to work well together. Talk about the kind of team you want to grow and how your combined and well-coordinated actions might best serve that end. The Scrum Master provides technical leadership and management expertise but this is not the totality of leadership expertise required for success.

Seek to complement each other for the good of the team and the success of the project. Work closely but respect the “What/How Line”, that often blurry demarcation between WHAT you ask your team to build and HOW they go about building it.

Always stay on your side. But always seek to understand their side to the extent that they know you appreciate the incredibly intense, ridiculously demanding, and supremely stressful situations in which they find themselves almost every sprint.These are the people who do the work. These are the people who always have skin in the game, reputation on the line, and fat in the fryer.

How do you achieve this high degree of synergy with your Scrum Master? By cultivating a co-equal relationship grounded in respect: for your Scrum Master, respect for what needs to get done; for you, transparency for what can get done. This is where your personal agility will be tested most often. Be flexible, open, and always working toward agreement.

Pay close attention to how your Scrum Master excels at consistently moving your team forward and continually optimizing its efficiency and effectiveness. This is the essence of what great Scrum Masters do and it is often what they take the greatest pride in. Look for it. Notice it. Inquire about it. Make sure your Scrum Master knows how much you appreciate it.

PO to Engineer

Code comes to the project through you via engineers and the ritual of story acceptance.

To accept stories with confidence, you need to be able to ask many questions of an engineer without casting aspersions, causing offense, or creating some kind of warped accountability process or compliance task.

In most cases, you won’t be able to see what’s going on under the hood. So how will you really know if the story is done? You’ll go through Definition of Done, of course. But even here, there are ways for stories not to be done and for you not to know this.

The relationship you need with your engineers is one that is characterized by safety and clarity of intention, a relationship where any question you ask is phrased as sincere interest on your part regarding their contribution and skill so that it is perceived as inquiry not indictment. To be truly successful, create relationships where you have made it clear that it is always safe for engineers to disclose things to you about code quality, tech debt, or risk and never have that information used against them.

Many engineers pride themselves on mastery. They write clean code. They are precise. They sweat the details.That means you don’t have to. Thank them for it. Treat them as trustworthy by default. Frequently express your appreciation of the knowledge and conscientiousness they bring to their work.

PO to QA

Validated functionality comes to the product through you from QA.

If you have embedded QA on your team, you have an extraordinary opportunity to have good acceptance criteria translated into great testing. It is well worth an hour or two listening to a thoughtful QA person talk about his or her approach to testing a story. But you won’t get that much of that this person’s attention unless he or she knows how much it matters to you and how much you appreciate the time your QA person is giving up to give you greater assurance in the validity of the work you own and represent to stakeholders, management, and the organization as a whole.

Think about it this way: when you go to do your sprint demo, you vouch for the fact that new functionality exists. For the PO to say, “We completed our sprint!” is, in a sense, to give your word that the work has not only been completed but validated as well.
This implies the delivery of defect-free functionality. Even though we know there are always defects, we don’t stand up in front of stakeholders and management and present completed stories that might have big holes in them. How do you know the holes are plugged? Your QA tells you they’re plugged and you trust your QA implicitly because you have the kind of relationship where that level of trust is possible.

The point of pride for many QA people is rigor. Rigorous testing catches defects early. Thorough and rigorous testing catches more defects even earlier. Take the time to understand how your QA person thinks about rigor and breadth of coverage. For Product Owners, life is always about the Happy Path. For QA folks it’s always about the bumpy road. Show them how much you appreciate their willingness to live that rocky ride so you don’t have to.

PO to Stakeholder

Work comes to the team through you from the stakeholder.

This is the classic Agile relationship. In theory, the PO is the stakeholder’s advocate on the project. While technically true, and often the best stance for making sure stakeholders get what they want. It’s an incomplete perspective for making sure stakeholders get what they need.

What stakeholders say they want isn’t always what they need because they don’t just want functionality, they also want certainty. You are their advocate, yes. But you act responsibly in that advocacy by advocating for things because they are right and because they are possible, not just because your stakeholder wants them.

While your stakeholder may certainly know more about their own challenges and goals than you do, no stakeholder knows enough about the range of possible solutions to solve their problems optimally. If they did, they wouldn’t need a Product Owner to help them render their requirements. The mere fact of your existence is proof that the stakeholder alone is not fully prepared to dictate every aspect of the product.

Instead of an advocate, think of yourself as a mediator. You want all parties to come together in agreement that the right thing has been made the right way. Insulate your team from stakeholder concerns; insulate your stakeholder from team operation. You want the stakeholder to consider your team a very capable and reliable “black box”. Stakeholders have enough anxiety; they don’t need to be wondering if your team can execute, and they certainly should never be tempted to wonder about how well your team is executing.

Stakeholders care about getting what they want, the way they want it, when they want it. The key to dealing with this type of uncompromising demand is clarity. You want your stakeholders to be very, very clear. So notice when they are and thank them for it. Encourage clarity at all times. Look for patterns in your interactions where clarity emerges by default and seek to repeat those patterns. Take responsibility for situations where stakeholders might not be clear by guiding them to clarity. Take the lead by being clear yourself, not as a way of diminishing or manipulating your stakeholders, but as a way of ensuring that your stakeholders really do get what they want.

PO to Architect

Great risks are mitigated, and great rewards are won through you via clear communication with your architect.

If you are very fortunate, you will have an embedded architect. This person can help you understand the past, clarify the present, and predict the future better than anyone else. Or your architect can render inscrutable all that your team has done, is doing, and will ever do.

This person can be your greatest teacher and most valued advisor. Or he or she can be an aloof genius who doesn’t have the time or the interest to tell you anything about what’s really going on.

How this plays out is entirely up to you and how hard you want to work to create and sustain a strong personal relationship that encourages your architect to share his or her thinking even when it is well beyond the limits of your expertise and the scope of your role.

Where many of us like to be appreciated for what we do, many architects like to be appreciated for how they think. Take a sincere interest in the intellectual elegance that many architects prize so highly. Ask them how they solve the problems they face, how they resolve and wrestle with the myriad tradeoffs that always exist between one way of doing things and all the other ways.

PO to Management

Organizational goals are achieved through you via directives from management.

Can management tell you what to do? Of course it can. It told you to be a Product Owner, right? So what happens when management puts on the pressure? You have to absorb it so it doesn’t hinder your team or trouble your stakeholder. (If management is your stakeholder, you have double duty here.)

Management pressure is serious pressure. So the only sustainable strategy is to have ways of alleviating it. And all of those ways will come from the quality of the relationship you build and maintain.

Regardless of how formally and at arm’s length your manager may want to treat you, you need to have a close relationship with this person because there will be many times when you will have to say, “No” and have “No” be an acceptable answer.

Respecting the “No” from a subordinate occurs only if both parties respect each other—as human beings on a planet not as slots in an org chart. You can’t own your product if someone owns you. The only way to beat the tyranny of the org chart is to develop peer relationships with people who are, technically, not your peers.

This requires getting to know people, and letting yourself be known to them, in ways that extend beyond the the structures and strictures of the organization. This is not breaking the rules; it’s making the rules. It’s changing the game from its zero-sum default to a more promising win-win reality.

Management’s reward comes from results. But along the way, management usually wants to be appreciated for the qualIty of its stewardship. Keep that in mind as you form the foundation of your relationship.

PO to PO

Unexpected work comes through you to your team from other POs.

In a large project, with many teams and many POs, this is your most interesting and often your most valuable relationship.

There will come times when one team cannot complete its work, or when one part of a system to which a particular team has been assigned generates more than one team’s worth of requirements.

The over-burdened team is just as likely to be yours as someone else’s. When that happens, you will need to be able to go to one of your PO peers and ask them to take a story or two from your backlog. The only way that people will do this for you is if you demonstrate at the earliest possible opportunity that you are willing to do it for them.

You cannot arbitrarily pledge the technical resources of your team toward new and different areas, but PO-to-PO you can always offer your consideration by saying, “I’ll take it to the team and get right back to you.” If it’s not possible, it’s not possible. But it’s always possible to see if it’s possible, to show that you were open and sincere in your effort to assist.

If your relationship with your team is based on cooperation, and not coercion, you will find them more sympathetic to the needs of other teams and other Product Owners—and ultimately to the needs of the organization as a whole.

You know what motivates you as a PO so look for that and reinforce it in your PO peers. You will also find POs who are much better than you are. Study them, express your admiration for their abilities, ask them to mentor you to the extent that they are willing. For those POs who are perhaps not quite as comfortable in their role as you are, pay it forward and do the same for them.

In the the PO-to-PO relationship, think of apprenticing yourself to your practice. That is, instead of taking the reductionist view of “Product Ownership as required functional role”, take the expansive view of Product Ownership as an evolving art, something always to be practiced, never to be mastered. And then appreciate the mastery you encounter in others.

How Product Owners Get By

As a Product Owner, you go to work every day at Grand Central Station. Things can come at you, things can go around you, or things can go through you. Things that don’t go through you will come back to bite you—unless other people have your back. The only way that will happen is if you cultivate good relationships.

In modern enterprise Agile projects, Product Owners have a dizzying array of disparate responsibilities. No degree of domain knowledge, technical expertise, 24/7 work ethic, or even sheer bravado will ensure that every responsibility is met. You must have help. And you must know you have help in order to make the tough calls that you, and you alone, will have to make.

Being in “the middle of it all” is exciting. But at certain times in a project lifecycle, it’s overwhelming. At some point in almost every project, your work life will become complicated beyond chaos. Nothing will be clear or easy.There may be no good choices, no correct answers, not even half-solutions to the monstrous problems you face.

And you own the product, right? So how do you get by?

If you’re as old as I am, and you started making software in the Pre-Agile-ite Era in the History of Software Development, you probably grew up listening to The Beatles. They were, arguably, the most agile band of all time. How did they do it? They got by with a little help from their friends.

Where New PO’s Are Relocated (The State of Confusion)

Valerie and I started a thread of e-mails the other day. She’s on a big Agile adoption project and we were talking about the challenge of getting many teams up and running quickly.

Valerie is a Scrum Master by nature; I’m a Product Owner. When I say that we are who we are “by nature”, I really mean that. I’ve been “a product guy” on software—and other types of projects—for almost 30 years. Valerie was Scrum Mastering her way through her career long before “Scrum Master” was a title anyone could hold.

So she asked me for a few thoughts on helping new Product Owners come up to speed. What I’ve realized upon reflection is that new Product Owners might benefit from a “Survival Guide” of sorts. So that’s what I’m contributing here, in a series of posts, over the next few weeks.

Here’s Whatcha Gotta Know (Not!)

I thought about sending Valerie a few quick “Here’s whatcha gotta know” tips. Then I got more interested in actually trying to solve the problem of helping new Product Owners get up to speed quickly.

I went back to some of the books I have on Product Ownership. I pondered their wisdom in the context of a large project I worked on recently. From 2011 to 2013, I spent 18 months as a Product Owner on an enterprise application platform and data system. We had about ten teams distributed across three locations, 100+ people, and something like a $75 million budget.

That’s a lot of product to own. I was perfectly happy not to own it all.

The project was something of a trial by fire but I didn’t get too burned along the way. Thanks to the many people with whom I worked, I came out of it with a lot of confidence, much new and very useful knowledge, and what I think is a good sense of what it really means to be an Agile Product Owner, as opposed to all the other product development roles I’ve played throughout my career.

This most recent project was that very rare greenfield work in a domain we care about deeply—a once-in-lifetime opportunity, I thought. It was also rare in that there was no “Agile adoption” phase to go through. We hired for Agile and we started with Agile from the beginning. In particular, all Product Owners were given hardcover copies of Dean Leffingwell’s “Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise”—probably the nearest thing that we have in the enterprise world to “ the Bible of large-scale Agile adoption.”

RTFM

“Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise” is a heavy hardcover book. It’s the “playbook” for the Scaled Agile Framework, or SAFe as it has come to be called, and it goes hand-in-hand with what is now known as “The Big Picture”, a nifty interactive Web-diagram you can find here.

For the discussion that Valerie and I were having, I purchased a copy of the book for my iPad, booted up “The Big Picture” in my browser, and dug in. And I kept on digging. This is not a breezy “book at the beach” sort of read, and for good reason: The list of “Agile software requirements” is not short.

For me, a person who has shipped commercial software products since the late 1980s, who has held management and executive roles related to product development, who has followed Agile with great interest since “The Manifesto” was born, and who has even applied Agile ideas in domains outside of software, I was surprised to find upon reading “Agile Software Requirements” for the first time during my first week on the job that I was seriously knocked off my game.

I spent several hours reading each night after work, and about 10 more hours over the weekend, reading as much of the book as I could. When I couldn’t absorb any more information, I remember the feeling I had all too well. It was like a song playing over and over in my head with lyrics that went something like this:

“Someone just wrote down an inventory of things Product Owners have to do in order to fulfill the Product Owner role. Everything I need in order to know WHAT my job is has been written down here. But I don’t have a lot of information about HOW I’m supposed to do all these things. It’s midnight on Sunday and I am totally freaked out about going to work tomorrow.”

Of course it wasn’t that bad back at the office. But that’s the way I felt the night before. And I felt that way for a several weeks thereafter. Even re-reading the book again just a week ago, in the context of my current discussion with Valerie, I found myself overwhelmed by all the things a Product Owner is supposed to do and to be.

I “Heart” Product

I love product work because I’m at the center of everything. In Agile, I call the Product Ownership function, “Grand Central Station”. All the trains run right through the PO (engineering, QA, Dev Ops, stakeholders, project management, business analysis, executives, other POs on the same project, etc.) and the PO makes sure they aren’t crashing into each other in horrible, costly, and extremely uncomfortable ways.

According to what I’ve read, this requires me to possess high levels of technical knowledge, domain knowledge, stakeholder knowledge, Agile knowledge (of course!), business knowledge, and really, really good communications skills.

I am also the Product OWNER, and that’s not a figurative term. I own the work product that results from my team’s efforts. I don’t own the team, but I own our results. Most important of all, in the context of doing and retaining my job, I represent the work of my team to all other parties and account for it fully at all times, for better or worse, richer and poorer, in sickness and in health—you get the idea.

So two years ago, as I’m heading back to work on that second Monday morning, trying to remind myself how much I love product work, I’ve got another song playing in my head:

“I just read this huge book about what it takes to be a Product Owner and it is telling me that I have a huge number of responsibilities, that I need high levels of expertise in many different and disparate areas, and—oh, by the way—since almost everything I do has a huge human interaction component to it, none of my work is an exact science.”

I have a team of very talented people to work with (two teams as it turned out in the end), supportive management that is “all in” for Agile, and a stakeholder who is demanding but constructive. I have what is arguably one of the definitive books on the subject of my work. Our company arranged for one of the book’s major contributors to coach our project in several multi-day “all hands” sessions.I even got four days of CSPO-like training as well.

But it’s obvious in my first week on the job that my role is vast, and that while I am slowly coming to know what it is, I really don’t know how to do it. Even nine months after leaving the project, I couldn’t tell Valerie HOW I did it. So whaddya know? The books, the courses, and the coaches are right: Product Ownership is not an exact science, not by a long shot. As such, the books, the courses, and the coaches are not where the true answers are to be found. All of these things are helpful to some degree but they are far from sufficient for success.

Keeping Myself Afloat

During my first weeks on the project, I am dog paddling in the deep end, gasping for breath, putting in 10-12 hour days during the week, and logging even more hours at home, learning at night and on the weekends about Agile Product Ownership.

What I get from this effort is two things: (1) A friendly reminder from HR that the hours I’m logging on our internal billing system are way too high; and (2) A difficult “adjustment period” that didn’t seem like an adjustment or a period at all because I didn’t know how to adjust to it and I saw no end in sight for the period I had just entered into.

However—and this is where I had a big insight in talking with Valerie—I ended up doing this work pretty darn well, all things considered. I think I’m a pretty good Product Owner now.

I PO’d for three different teams—two simultaneously for seven really hard months—and served as the project’s overall domain expert. When I left, after the product was released, I received an outpouring of admiration from my peers and three offers of new positions from my CTO. I felt deeply honored by my co-workers, and especially proud of each new job offer I received, but I was leaving to head back home and work with my wife on her business. My decision was a lifestyle change for me, not an expression of dissatisfaction.

So I must have been doing something right. Yet there was literally nothing in the books I read, the coaching I received, or the additional PO-specific training I received that told me how to be a good PO. Always, smart people were telling me WHAT to do. But rarely did anyone show me HOW to do it well.

Curiouser and Curiouser

So the discussion I was having with Valerie made me curious. How did I become a decent Product Owner? I really didn’t know. So that’s why I was up late for a few nights once again this past week, re-reading much of “Agile Software Requirements” and a few other books, drilling into “the big picture”, and taking some notes on my iPad as I went. Each time I read about WHAT I was supposed to do, I reflected on HOW I did it. If it wasn’t in the books, I made a brief note.

I ended up with more than 50 notes.

Apparently, I discovered on my own—with a lot of well-intentioned trial and error, some good help from another Product Owner in the organization, excellents support from a stalwart scrum master, and some very helpful guidance from my CTO—HOW to be a decent Product Owner. But doing that involved putting into practice 50 or more “micro-strategies” to help me do my work, none of which came from coaching, courses, or books.

So Here We Go

With the incredible rise in the number of enterprise Agile adoptions, the number of people who are becoming new Product Owners these days is skyrocketing. These folks are probably all smart, hard working, experienced people. They’ll have books, coaching, and courses just like I did.

And I’ll bet they’re discovering much of what I did, too: that there’s an incredible amount of information available about WHAT a Product Owner’s job is, but not a lot about HOW to do it well. This is what I’m going to address in the next set of posts in this “New Product Owner’s Survival Guide” series.

This is not “official” stuff. It hasn’t been blessed by any major organization or well-known consultancy. You won’t get a certification at the end. Or even the ability to say, “I got advice from a famous person!” because I am in no way famous. This advice is entirely personal to me. And as the saying goes, “Your mileage may vary.”

But I don’t think my experience is that unusual. I think many of us are in the same spot. And I think more and more people are entering that spot every day as enterprise Agile becomes “the next big thing.”

Truth is, I’m using Agile in several different industry sectors right now. Agile is everywhere all of a sudden. And just about everyone is struggling to some degree to get their head around it.

We all have access to coaches, courses, and books. And these are all very valuable. But I don’t think they give us exactly what we need. At least they didn’t give me exactly what I needed, and I had some of the best support resources in the business—plus a very supportive management team encouraging me every step of the way.

I realize, among other things, that most new Product Owners will not be nearly as fortunate as I was to work with such great people under such hospitable circumstances.

I know how much I appreciated all the help I got from the terrific people around me. And talking with Valerie about the major Agile adoption she’s involved with made me think I might have something to give back to others.

So stay tuned in the coming weeks for more of “The New Product Owner’s Survival Guide: Stuff We Don’t Get From Coaches, Courses, and Books.”

Steve Peha has split his 30 years or so of work across several industries including software development, writing, education, music production, graphic design, and a few other short-lived but long-valued professional experiences. He has worked for half a dozen software companies and even started one of his own that he was fortunate enough to sell to his publisher and count as a small startup success. Currently, he is working in the Agile world with Amr Elssamadisy on something they have created called “The Culture Engine“, a method for improving workplace culture in Agile organizations, especially those in the midst of enterprise Agile adoptions.

A few months back I had a lunch meeting at Google. My host asked if I could come a little early because it was “Take Your Kid to Work Day” and if we kept our original noon meeting time, we might have to wait a few minutes for our all-you-can eat free gourmet food. (I know, I know: first world problems. But I digress.)

Sure enough, at high noon, Gary Cooper did not show up, but throngs of big and little people did: the lunch line reminded me of a crowded cafeteria at an over-crowded high school. And what’d’ya know? I saw hundreds of whole children all over the place just having a blast. Imagine that: entire kids; none that I was aware of seemed to have forgotten parts of themselves at home that morning; not a one near as I could tell.

Many companies have days like these. “Take Your Pet to Work Day” also comes up once in a while. The last time I saw something like this, whole critters of all kinds popped up in cubicles, hallways, and offices. Entire dogs and cats. Even a bird or two. And every one of them all 100% there.

But I know that I’ve gone into work many days and failed to bring my whole self. Certainly, some of me might have been ruminating about issues at home or chewing on other matters of high personal significance like why my fantasy football team was floundering just because I didn’t know what “snake draft” was. But even then, I wasn’t bringing all of what I had with me.

Usually this manifested itself in my holding back, playing it safe, waiting for someone else to go first—and sometimes not even going second to follow right after them.

In more extreme but not uncommon situations, this manifested itself for me in resentment over something that might have happened weeks or months in the past, a kind of “I told you so!” feeling that I continued to carry with me though it served no constructive present purpose at all.

In the worst circumstances, I might intentionally come in late or leave early. I might also skip a meeting, especially if I could rationalize the futility of my participation. (Note to self: pre-determining one’s futility in any situation to the extent that I do not participate is by default a self-fulfilling prophecy.)

Maybe you’ve had days like these, too. Maybe you’ve had a lot of them. Regardless, you know what they feel like and you probably also know the impact they have on your performance—and especially on the performance of those around you.

Fortunately, I was able to do a nifty A/B experiment on myself around this issue. I was a Product Owner on a very cool 150-person project: Agile all the way; greenfield work; no legacy code; generous budget; and a really good social cause, too. Very cool. But it was also very challenging. I won’t go into the details suffice it to say that we experienced, sometimes in huge doses of our own design, all the typical challenges that most Agile projects face—and then some.

The product was officially released in March and we did make the deadline. Many people worked hard to negotiate scope with our stakeholders and many others worked even harder to deliver on what was eventually agreed to. But it was a tough slog for us all and the end result didn’t really seem satisfying to anyone.

A few days later, I gave a month’s notice that I was leaving. This was the project I came to work on, and aside from maintenance and mop up, there wasn’t really anything left for me to do. I was actually chosen to PO an entirely new project during my last 30 days.

So here’s the experiment: During the first 17 months of my engagement, how fully did I bring myself to work each day? And how did this compare with the last month of my engagement?

There was much for me to enjoy during the entirety of my employ. But I absolutely loved my last 30 days. People kept asking me, “Dude, why are you working so much when you’re about to leave?” Truth was, I didn’t really know. I was just having a really good time.

With a few month’s distance from the project, I know the difference now: when I had a job I thought I might want to keep and even advance in, I held back, ruminated over problems of corporate calculus, and performed more poorly as a result; when I had a job I knew I couldn’t lose (because I had already announced my leaving), I brought my whole self to work each day and performed much more effectively. Not only did I make a better contribution to my team but I did a lot for other teams, too. And I really did enjoy myself almost every minute.

Writing this, I’m reminded of a quote that I think we all know at least a little of: “You’ve gotta’ dance like there’s nobody watching. Love like you’ll never be hurt. Sing like there’s nobody listening. And live like it’s heaven on earth.”

Corny, sure. But most true things are.

When I “had” my job, there was always some silly chess match going on in my head, some sense of relative advantage or disadvantage, of gaining position or losing material, of the thrill of victory or the agony of defeat, and most certainly more than the occasional dollop of flat out fear. Looking back, it was probably the fear, the lack of safety I felt, that sat at the root of any dissatisfaction or withholding I may have rationalized at the expense of my team members, my stakeholders, and my employer.

I reckon I’m not alone in this. There has been, in every company where I’ve worked other than the ones I’ve run myself, some not insignificant element of trepidation for me. This isn’t to say that I haven’t had my close calls, near-bankrupt moments, deal-killing incompetence, or general doubts about my own organizations. I have. But I’ve had a lot more control in my own organizations, so I’ve always felt a lot safer. I think that’s why, ultimately, I tend toward entrepreneurism. Some people think I’m a risk taker. I think the exact opposite is true.

Working in my own company once again, I try to make every day a “Take Yourself to Work Day”. After all, if I don’t show up fully, the work doesn’t get fully done. And, historically, all the really great work I’ve done in my life has been for companies I either owned or ones that I have at least been a co-founder or executive of. Even though all of those companies have had far fewer resources, a decidedly un-Google-like lack of luxury, and far less prestige than any corporate situation I’ve been in, my work has been better and so has my work satisfaction.

I had a couple of great teams back on my last job. What, I wonder, could we have achieved had we all taken our whole selves to work each day? The difference in myself between a moderately fearful first 17 months and a totally fearless last 30 days was dramatic both in what I contributed and how I felt. Multiply that by an entire scrum team and I think our achievements would have been significantly greater than they were. Multiply by 150 and my hunch is that we could have delivered everything our stakeholders wanted and much they would never have imagined and would have been thrilled to receive.

But I know that there was a fair amount of fear around the work we were doing, and when we weren’t afraid, we were often confused or at best ambivalent about which path to take. What we needed was a long unbroken string of “Take Yourself to Work” days.

I realize now that bringing all of who I am to work every day makes all the difference in the world. I don’t always do it. But I always know that it matters. And when I work with others, it seems to matter even more. So now I’m thinking that maybe there’s one more line to add to that corny old quote: “Work like you’ll never get fired.”

Steve Peha is a learning strategist and product developer with a keen interest in the creation of high-performing teams and organizational cultures that encourage their development and support their growth. He is the founder of Teaching That Makes Sense, a learning consultancy in Chapel Hill, NC. He has two dogs, one wife, and zero reluctance to throw himself fully into his work.