Skip to main content

The Product Owner is a Metaphor Too

I've been having many conversations recently about how to set up the agile teams I'm coaching with the right Product Owner.  As we all know, the PO must be empowered to make decisions, yet must also be knowledgeable enough about what the software should do that she can make constant small decisions for the team so they don't have to wait.  The PO understands the big picture, understands the small picture, and can set priorities.

I blogged a few months back about how the "Team Room" must be considered a metaphor, not a literal prerequisite to trying agile for the first time.  I know I am stepping into equally sacred cow pies here, but I am going throw my weight behind greater thinkers than I who have already posited that the "Product Owner" should be considered as a team, not an individual.  A small village, not a literal person.  Consider these "Product Owner Team" proposals from Mike Cottmeyer, Ben Linders, and Marc Löffler, specifically when considering how to do the Product Owner role at scale.

Product Owner Team enthusiasts posit that if the village can reach consensus and speak with one voice in a timely way on a consistent basis, the whole agile development team will be in fine shape.  The trick is building the right village.

"The Body Politic" from

I'm currently helping a large vertical in a corporate environment structure the product ownership function for its teams, and it's going to look something like this:
  • 1 Executive Point person where the buck stops (contacted as infrequently as possible)
  • Some large number of SMEs who have details about value and usage of the feature (contacted only as needed by appointment, with a fall-back appointment arranged in case the first one falls through)
  • 1 Business-side "feature point person" per desired feature (readily available but not in the metaphorical team room.)
  • A team of business analysts, user acceptance testers, and business systems analysts who are responsible for knowing which SMEs are needed for each feature, and are able to get those people to the table in a reliable way (part of the core team, always working in the metaphorical team room)
For the software features these teams are building, the "value" of a particular function is generally a corporate legal compliance issue.  The real "Product Owner" who is paying to get the work done has skin in this game only insofar as they need to get a signed approval from an auditor who has made a "finding" against them.   If they don't get this approval, they will face true Profit and Loss consequences.  They are motivated.  Sadly, this person whose neck is on the line for the new feature most likely doesn't ever see the software in use by the people who use it.

On the other hand, the people who do see the software have no funding authority for the team.  In a waterfall world, their only power is to scream loudly for the first time when they first see the software (at UAT or even in production).  They get their way, but in the least convenient way for the business and for the technologists who need to absorb a huge influx of last minute requirements from an unexpected direction, all in the unlovely package of a "production down" situation.

If you will pardon the use of a second major metaphor, this situation is like that of the company that makes chairs for airport seating areas.  The airport will willingly buy chairs that are uncomfortable if they are made of knife-resistant kevlar, if what they're optimizing is wear-and-tear.  The people who actually sit in the chairs don't get the last say.

At any rate, in this enterprise environment, the actual requirements for the software are spread among many corporate divisions and controlled by many different national laws, and the people who do the actual work are spread across many parts of the business.  The person with "final say" is actually an executive at a high enough level to placate others who may be annoyed at what is happening in their operational area in order for this business owner to be in compliance.  Powerful executives are not available to sit in a team room all day long.  They must be consulted sparingly.

The people who know all the details of the various "sunny day" and "cloudy day" scenarios of software use are scattered all over the enterprise, and all over the real world, and they only speak for a piece of the whole software puzzle.  They have day-to-day responsibilities with live clients, and they are certainly not available to sit in the team room, nor do they have the objectivity to make decisions.

The actual decision-making Product Owner, therefore, must be a group of people who together have the right business-side contacts to put together a proposed solution that meets the needs of all stakeholders with the right level of priority for each stakeholder.  That's where we get to the trifecta of business analyst, business systems analyst, and user acceptance tester.  Decisions need to be made by the whole village, so some simultaneous-in-time meetings will need to be set up to get full Product Ownership up and running.  But it is quite likely the whole Product Owner team may never meet simultaneously.  The Product Owner body politic will need to self-govern in a way that will be as efficient as possible for the team, but at least it doesn't need to ask the software developers to guess what to do.

I imagine that this scenario will make some agile purists totally freak out, but I think if we're serious about taking agile to "enterprise scale," we have to be prepared to scale things like the team room and the product owner as well, and we need to be comfortable with that.


  1. I'm not freaking out at this definition of product ownership for a large convoluted enterprise.
    I'm rather sad.

    I'm sad about the fact that the work which could have been potentially done by bringing in key stakeholders "together" for a limited period of time will now take weeks (if not months) to visualize, comprehend and deliver (however many iterations and showcases you care for). The question that springs to the mind "is that being effective or being efficient?"

    The arrangement of organizations into functional silos seems anachronistic. This is the age of cross functional teams and polyglot skill set. This is the age of collective wisdom over individual brilliance. May be an organizational transformation of the corporate environment is overdue.

  2. Thanks, arcane. I agree. I think there are companies that purposely organize themselves into self-governing units of 200 people or less (the company that makes Gore-Tex, for example). It would be cool to see a very large company do that.


Post a Comment

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

How To Write A One-Page Proposal to an Executive

One day you may need to communicate with an executive. Pro tip 1:  executives do not have time for you to dim the lights and show them forty slides with charts composed of animated dancing leprechauns and flashing arrows that emerge from the void in a checkerboard pattern. Pro tip 2:   Guys, and gals with deep voices, executives also don't need you to use your "Radio Announcer Voice."

As a rule, what executives want is simple: one printed page. No matter what it is, it should be one page. And it should be printed, not emailed.  You should plan to hand it to the executive, and then you should be quiet when they read it and wait for their questions.  It's harder than it sounds.
 So how do you do it?  Here are the steps:
Write the deck that expresses your proposal in as many slides as it takes.  Use imaginative animation and blinking letters if you must.Remove your title slide.Insert a new slide at the front of the deck with "Appendix" written on it in big …