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


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


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

Please leave a reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s