The New Product Owner’s Survival Guide: Stuff We Don’t Get From Coaches, Courses, and Books, Part Two

grand-central-station-impasto-vignette

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.

Advertisements

The New Product Owner’s Survival Guide: Stuff We Don’t Get From Coaches, Courses, and Books, Part One

skydivers-impasto-vignette

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.

Considerations for Prioritization

Pheonix

Priorities. They can fall out at so many different levels.  Organizational, program, story, task, individual, team…   I will often talk about two types of priorities.  One set for the work that we do, and another by sharing some priorities from teams themselves.

Priorities for Teams:

I am fairly retrospective by nature.  Leading by modeling the behaviors that we expect in others is a great place to start.  Be open, help determine and actively be a part of the solutions. Motivating, inspiring, and encouraging each other are important along any journey in overcoming the obstacles which beset us. Be pure of heart and value the people who shared in that journey along the way. These are some of the priorities from teams that came as they had a chance to examine and reflect:

  • Problem SolvingHow well do we attack and task apart work, bring the solution, overcome the question and form answers?
  • Grace Under Pressure – How calm are we, are we learning, were we stalled or frozen?
  • Communication – Are we all talking effectively? Did we get it? are we arguing or exploring? Was there emotion or achievement?
  • Productivity – Was this pace sustainable? Did we improve? Was this re-work?
  • Responsibility/CommitmentWere we reliable? Did we earn their trust? Did we do what we said?
  • Self Evaluation – How accurate are we? Do we know ourselves? Do we know the work? 
  • TeamworkDid we do this together? Who was left out? Are we all rowing in tempo?
  • Balance – Are we overloaded in one direction? Is there something we are not seeing? Are we aligned? How can we help?
  • Continuous Improvement –  What changed? Are we faster? Higher quality? Can we do different kinds of work?
  • Having FUNDid we laugh? Did we share? Did we let off some steam or break away for a bit?
  • Shared Vision – Common Goal – Are we all IN? Can we represent the vision? Are we Charged up the this is IMPORTANT? 
  • Collective Skill SetAre we growing? What did we learn? What did we share/teach? What was new or different about the work? Do we have the skills we need?

Priorities for Work:

It is unfair for anyone to say that they need 300 things all at once.  It is irresponsible not to help the team prioritize the list of work.  We all want to succeed at this, and having the correct alignment and convergence takes some doing.  Especially, when this is balanced across several teams.  Often our ability to critically negotiate starts with the scope of the work.  We should not negotiate the quality although in practice this is often the first thing that start sliding.  Emphasize the actionable.  Leverage and consider, but don’t be distracted or frozen even when criticized.  Be fearless and get to doing the right thing the right way.  Its all about the delivering software. When we consider the work itself – I tend to think of BIRD as an acronym. Points for consideration when making our goals rise clearly from the vast ashen grey landscape.

  • Business Value
    • Revenue – What can we sell this for?
    • Penalties – What is the fine if we miss this compliance?
    • Increases in
      • Margin – Are we more efficient?
      • Reactivity – What is the organization’s ability to do this.. 6 months or 3 weeks?
      • Quality – Is this solution robust, reliable…?
      • Product Offering – Is this a new strategic direction?
  • Impact
    • Mission Critical – Are company exists to do this…
    • Must Haves – As opposed to Should or Could Haves…
    • Core Values – We want to or already do this better than anyone…
    • Critical to Quality – Customers will not buy this unless…
    • Customer Requested – Directly from our target and not because we just feel like it…
    • Risk and Severity – Did we explore this? How will we mitigate this? 
  • Readiness
    • Capacity – Can we do more of this or do it faster? 
    • Capability – Is this a new type of work or technology? 
    • Complexity – Is this as much as we can break it down? Are we doing the simple one first to build up our skills, then try something a little harder?
    • Maturity / Vetted – Was this seen by everyone involved? Are we clear on the scope and acceptance criteria?
  • Dependency
    • Deliverables / Inputs – Did we need something in place BEFORE this work starts? 
    • Sequence – We did a vertical slice and this is the next feature that builds upon that deliverable.
    • Coordination – We might have the work of three teams coming together… Can others outside the team support us? 

It is a list I have found useful to keep around. All things being equal, tie breakers would go the the smallest work first as a tie-breaker.  This moves value through the system the fastest.  Just remember to be careful which finger you use to represent priority number one.