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.
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.
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?
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.