On the surface, this statement appears as if I’ve lost my mind. For one thing, a traditional view to Product Owners is as a Product Manager or customer/business stakeholder-facing role. And the traditional Project Manager is more so a planning and execution focused role. The two are quite far apart and seem to have little synergy.

The other factor is traditional versus agile contexts.

There are no “traditional” Product Owners. Usually a Product Manager is in essentially the role but it’s very outwardly and upwardly facing. Once the requirements are “signed off”, they’re not that interested in collaborating with the team until the end of the project.

And traditional versus agile project managers can be quite different. For one, the acts of estimating, planning, and tracking are the prime directive. For the other, these are important, but team collaboration, exploration, customer feedback, quality, and value-based delivery are even more important.

The 4 Quadrants of Product Ownership

When I introduced the 4-Quadrants in this article or blog post, I introduced four areas where I thought a skilled and well-balanced Scrum Product Owner had to have skill and focus:

  1. Product Management
  2. Project Management
  3. Leadership
  4. Business Analysis

The one that seemed to get the most pushback from folks was the Project Manager area. I think because many had a view to traditional project managers they’d worked with in the past and they were having trouble mapping these skills into the role of Product Owner.

I actually struggle with that aspect myself – so I get the need for the activity. I just worry about more traditional project managers (or the tactics) having a negative effect on their agile teams performance. Nonetheless, let’s explore it.

A Deep Dive into the Product Ownership – Project Management Quadrant

Next I want to explore seven specific project management-oriented activities that should help you visualize the responsibilities of this quadrant. The list isn’t exhaustive. For example, I could have added some sort of budget level and ROI responsibilities to the list. And there are probably others. But it should give you sufficient flavor to help you understand the quadrant more and to effectively describe Product Owner responsibilities within it.

1) Project Chartering

It often starts with a project vision or base need on the part of the business. This then drives a project chartering activity where things like:

  • Vision & Mission
  • Goals
  • Functional and Non-functional requirements
  • Constraints
  • Success criteria
  • Budget and ROI
  • Teams themselves are established
  • High-level plans
  • All leading towards some sort of “Commitment”

Within an agile context, teams need to be pulled together, jump-started, and product backlogs (high level to low level) need to be constructed with the teams. Terminology like Sprint #0 can often be heard or used as part of these efforts.

In this blog post, I explore some of the dynamics of creating a “proper beginning” for agile projects. Agile project chartering is this activity and I believe the Product Owner should be in the middle of helping craft an effective launching pad for their agile projects.

2) Project Risk Management

A few years ago I shared a blog post about agile risk management. Essentially I implied that it wasn’t done the same as in traditional projects; that there was very little specific “risk planning” in agile projects. Instead, the entire team was responsible for surfacing risks as early as possible and for mitigating and reacting to those risks.

Now I still largely hold to that advice, but I think it changes a bit in many projects. I do think that having the team “sit down” for a bit and brainstorm their project risk landscape as a good idea. As is factoring these discussions into the teams planning efforts and strategies.

For example, in the SAFe framework there is a specific Potentially Shippable Increment (PSI) planning event and risk planning is an important and distinct part of it. And these plans either surface in a succinct risk plan, or better yet, in the PSI plans and strategies to deliver the committed features.

3) Project Communication

When I was studying for my PMP, one of the key areas that they discussed as part of “good project management” was pulling together a Communications Plan. I used to think that it wasn’t needed for agile contexts. I thought that the principles of software demonstration, transparency, information radiators, and cross-team communication naturally took care of “all” the necessary information sharing.

And that’s true in smaller contexts. But I’ve changed my mind elsewhere.

In larger, Enterprise-level contexts, I now think a concise look at the needs for organizational communication:

  • Who;
  • How often (frequency);
  • What to communicate;
  • And gaining their “buy-in” that they’ll be “listening”.

as being incredibly important for a successful, larger-scale agile effort. And this communication plan, or the responsibility for creating and reinforcing it, falls to the Product Owner and the PO Organization.

4) Project “Tracking” & Adjustments

I’m using the term tracking lightly here, but someone needs to be aware of the “big picture” commitments that the project has made and then map the teams’ progress back to those plans and commitments.

In traditional environments, that’s either the project managers and/or functional managers. In agile contexts, I contend it’s the role of the Product Owner.

Now the job isn’t too difficult because of the level of real-time transparency that should be occurring within and across your agile teams. Often there is a cross-team authority, for example a Scrum of Scrums meeting, that consolidates this information into a single meeting and set of tracking artifacts.

The real value of the tracking is what you DO with the information – i.e., the adjustments you make within your plans. This is distinctly different from the traditional responses, where projects were either on or off track. And, if they were “off track”; often overtime and quality compromises were the only way to get them back “on track”.

In agile contexts, we want to “flex on SCOPE” as our leverage for adjustment. And these options largely fall to the Product Owner to make. With the teams input and help of course, but scope tradeoffs are how you adjust towards your goals.

5) End-to-End Project Release Planning

One of the central activities of SAFe is conducting a 2-day PSI (Potentially Shippable Increment or Release Train) planning session as a team. The event is focused on mapping work (Epics & Themes) or the “ask” from a business perspective to each teams’ ability to commit to User Stories that meet the ask.

The planning takes an end-to-end view, so from:

  • Requirements & visualization,
  • Architecture – system, UX, DevOps
  • Through construction
  • Testing (functional, non-functional, automation development)
  • Covering operational readiness (DevOps deployment, documentation, training, customer readiness, etc.)
  • Deployment to Production

In other words, it takes a “Concept-to-Cash” view to ALL of the work required to deliver on the goals, themes, and features for the release. And keep in mind that the PSI is planned in a series of sprint-level increments, so it is an iterative plan.

In SAFe, there is a role entitled Release Train Engineer or RTE. They are largely responsible for facilitating and orchestrating an effective PSI-planning event.

Even if you’re not implementing the SAFe framework, many agile organizations and teams leverage some sort of release-level planning activity—particularly in at-scale agile It just makes sense to have a view to a larger picture before letting loose multiple agile teams towards an unplanned goal.

I would argue that the individual Product Owners and the Chief Product Owner are incredibly important to effective release planning. Not only to “set the stage” with the “ask”, but to be there during the planning to answer questions and to help the teams make appropriate scope tradeoffs as they try and deliver on your goals.

I would even say that Product Owners should become “students of” release planning techniques, approaches, and models. Even with an RTE or similar role, you’ll want to partner with them to ensure you and your teams have a solid plan. Here’s a link to a PDF article that explore various forms of release planning in much more detail.

6) Stakeholder Management

I remember distinctly in traditional projects where our C-level team would “call in” the project managers for portfolio level tracking. Often they would never see or interact with the individual teams. Instead, the project managers were the sole lenses for each project.

This placed a tremendous burden on the project managers to effectively “manage” stakeholder information sharing, expectations, and their reactions. Some were good at it and others were not. Some had more trust with stakeholders, which mattered a great deal too.

Often you could draw a direct correlation between projects that were going well versus not, by the maturity and skill of their project managers stakeholder management.

As we move to agile contexts, this sort of stakeholder management is still largely relevant, but now it falls to Product Ownership to handle expectations management. Often it focuses on reinforcing the importance of your Stakeholders and Senior Leadership to “fully engage” with your/their agile practices.

For example, getting them to regularly attend sprint demo’s, release planning, Scrum of Scrums meetings, and even circulating around daily Scrums will give them a strong sense for progress, challenges, and where they might help.

But you’ll still need to provide a “buffer” between your teams and your stakeholders, so that they effectively understand and react well to the transparency and the adjustments being made.

Note: this crosses into the Leadership Quadrant of the 4-Quadrants to some degree. This is one of those nuanced areas that really make a difference in your overall success. I often challenge the Chief Product Owner (or other Product leaders) to think about who and how they’ll be thoughtfully and actively managing their stakeholders.

7) Project Retrospective

Clearly you’re involved in each sprint retrospective that your teams conduct. And I want to encourage you to fully engage in each one of them. But that being said, I also think you need to take your feedback acquisition “up a level”.

Your Sprint Reviews are a wonderful ceremony to gather feedback from your Stakeholders and Leaders. Please don’t miss that opportunity to gather their feedback as you deliver each increment. And don’t always assume that you’re getting it either. I’ll share a story to make that point:

I was talking to the EVP of Software Development at a conference not that long ago. He was describing the interaction in a recent Sprint Review or Demo. He said:

Bob, I threw a 5 to represent my reaction to the demo, but I wanted to throw a 2. In truth, the demo was terrible and I believe the team failed to meet customer needs in their development efforts. I just felt very uncomfortable giving that sort of negative feedback in front of a large audience. I pulled aside the Director of that team later, and I gave her my feedback.
I actually challenged him to speak the truth” in future reviews. I tried to make the point that it was important to be transparent with feedback as well. Sure, craft it carefully, but if a demo sucked and you said it was great, that is setting a very bad precedent.  He responded:
You’re right Bob, but we are located in the South and have a culture of thoughtfulness and care when giving bad news. It will take me (and us) time to get over this cultural barrier. But I can’t imagine “telling truth” for quite some time.

Clearly you need to work incredibly hard to get all forms and types of feedback out from your stakeholders. Be aware of your cultural norms and figure out creative ways to get the truth on the table so you and your teams can address any deficiencies or misses.

SAFe has a release-level retrospective at the end of each PSI. It’s a cross-team, ALL stakeholder meeting where issues are discussed and improvement action-plans are formed. So there are multiple “layers” to the feedback and reflection opportunities.

I’ve written several articles that explores the power of Sprint Reviews beyond simply showing software:

Get Help!

I wanted to remind you of one of the reasons I developed the 4-Quadrants in the first place. It’s because of how hard the Product Owner role is to perform well. It’s an incredibly deep and broad role that requires tremendous effort and skill. It also requires quite a bit of time.

I often joke, and it’s not really a joke, that I’ve only met 4-5 Product Owners who could perform all aspects of the 4-Quadrants by themselves. Ever! What this implies is that it’s OK to ask for help. In fact, you’ll most probably need to get help in your role.

If you have Project Management strengths and skills, then take some of this on yourself. If you don’t, then look for someone else in the organization with these skills and strengths to help you out. For example, in SAFe environments, you might want to make the RTE a partner or best friend.

But the KEY is to find or ask for help if you need it in the quadrants where you are weakest.

Wrapping Up

I know, I’ve just added a tremendous amount of additional work to every Product Owner reading this article. I’m sorry. But whether you like the 4-Quadrants model or not, this work is there for you regardless. The key is to be aware of it, get someone covering it, and to do it very well.

All of the 4-Quadrants are important to the role of Product Ownership, but I hope I’ve shown you how crucial the Project Management quadrant is to you, your team, and your organization.

Stay agile my friends,

Bob.

4 Comments