Product Ownership as a team sport

Interesting reading a couple of Leading Agile pieces about teams of product owners ( PO-team-why, PO-team-supporting-the-portfolio-team ).  I liked one a lot and the other not so much, I’ll try to explain why and some suggestions for scaling that role.

PO Team:

  1. A team of PO’s can be useful, successful, and improve the delivery if some simple rules are followed:
    1. Each team has 1 PO. Other PO’s can collaborate with them, but a single PO will give a team the stories for planning, acceptance, and for answering questions.  This avoids any conflict and makes sure each team knows where to go for what they need.
    2. The PO team communicates constantly. The PO’s should meet regularly to review, discuss, and align their directions, stories, and release information to ensure that no information is left on the floor.  I had really good success with a daily scrum type call with all the PO’s & BA’s on a team to make sure we were preparing the work for the team and to discuss any issues or new information that was discovered with the clients or teams.
    3. The Chief PO needs to make sure each team PO has a clear direction, epic, and authority for that product or area of the product to be successful.  It is the CPO’s first responsibility to make sure the PO team is running smoothly and spends time clearing the rails for them or getting answers to questions that are funneled up.
    4. Decision making needs to be swift and decisive.  If an issue comes up and time is of the essence, the PO team needs to be able to quickly analyse the situation, facts, and impact and keep moving forward if possible.  Sometimes this required input from the client/business and sometimes they won’t make a decision. If not, then you as a CPO or PO team need to decide and be ready to explain and possibly change that decision in the future.
      1. This usually isn’t a large gap.  If you’re in touch with the goals of the project, users and teams then your educated guess will be correct most of the time and if not, then you’re close enough to pivot into where you need to end up within another iteration most of the time.
      2. There are times where you cannot make a decision, you simply don’t have enough information. At that point it’s OK to decide that you can’t do anything yet, and to move that item off the team as you learn more.  Not making a decision is the worst thing you could do.

Some questions and clarifications from the articles:

  1. “Provide timely information to the Portfolio Management for investment decisions”
    1. I’m having issues wrapping my head around this one.  If I think of this Portfolio Team as the stakeholders/customers then it makes sense.  Otherwise I’m not sure. It would be helpful to detail out the membership of this team as he did for the PO team.
      1. If this is leaning toward SAFE then some of this makes more sense.
    2. Having a team on the other side of the PO helps to gather ideas/input.  I see some of the PO responsibilities taken away in this scenario ( Epics for release, Features for MVP, and Prioritization to name a few ). POs should seek feedback and input on these but if others are deciding for them, then what exactly are we providing that’s different from a waterfall Project Manger?
  2. Product Owner Team Roles
    1. Product Manager (PROD), Solution Architect (SA), Release Manager (RM), QA Management (QA), Project Manager (PM), Product Owner (PO)
      1. To me this seems like a leadership team, there are people here that need to be informed about getting the product out but does not seem to be focused on the what, mainly the when.
    2. In my reference above I would have the following on a PO team:
      1. Chief Product Owner, Product Owners x n, Business Analyst, Data Analyst, Scrum Master ( Chief if there is one, coach if not ), and Product Manager ( if there is one ).

I can agree with the last statement he has ( with a slight modification ) and that should be what we are striving for as a Product Owner.


With a few brief reports and frequent communication, the Product Owner Team ensures

the Portfolio Team client has visibility and timely information they require to make good business decisions.



I like to create things, work with interesting people, and do all things agile. I have a testing background and really want to make great products that solve problems.

Posted in Uncategorized

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 )

Google+ photo

You are commenting using your Google+ 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

%d bloggers like this: