Skip to main content

The Reluctant Product Owner

Mike Cottmeyer Chief Executive Officer
Reading: The Reluctant Product Owner

At this point in the discussion, it probably makes some sense to sync up a bit.

We started off looking for where all the traditional software development roles fit in Scrum. In the process we concluded that many of the roles are either the direct responsibility of the Product Owner or abstracted from the team behind the Product Owner. This conclusion is both powerful and problematic.

The Product Owner is a powerful construct because it solves two significant problems for the team. By virtue of having total ownership of the product direction, the Product Owner sets context. They give the team a single place to learn what needs to be done and why it is important to the business. The Product Owner also provides for coordination. They get to set priority and decide when the team has met its objectives.

Think about what happens when we don’t have a Product Owner working with the team. We might have excellent technologist, but no sense of the bigger market picture. If we sub out the Product Owner for a Business Analyst or Project Manager… we get the some of the coordination… some of the context… but little of of the vision. If we just have a Product Manager, we get much more of the context… but we are going to loose quite a bit of the coordination.

We lose the Single Wringable Neck. We must have both context and coordination for a successful agile team.

The Product Owner is problematic on several fronts. Most organizations have not hired single individuals with the breadth of skills necessary to fill the position. These skills rest with specialists… Business Analysts, Project Managers, and Product Managers. Do we convert these people to Product Owners? Can we train them with the new skills required to be a successful Product Owner? Will the organization trust these folks to be that Single Wringable Neck?

What if we hire from the outside? What do we do with our talented, dedicated, and most importantly…. knowledgeable traditionalists? Do we just let them all go? Is our organization structured such that a single person can do everything necessary to provide context and coordination for the team? Will we will able to find enough super human product owners to drive our mission critical products? What do we do while we are in transition?

This issue is BIG for small teams and mid-size organizations. It is even BIGGER for companies that want to do an enterprise agile roll-out. These are places where context will never be set by a single individual and coordination must happen on a much grander scale.

Let’s Start Small

We’ll start by looking at context and coordination issues on a small team and see what happens as that team tries to scale.


This picture describes our simple agile scenario. We have a single Product Owner working with a small team of 6-8 people… for this example, a team of generalists.

From the team’s point of view, the Product Owner has 100% responsibility for defining the context for the team. They create the product backlog, determine acceptance criteria, get the backlog ready for the team to build, and work with the team on a day to day basis to develop the emerging product. They own the product vision in its entirety.

In this example, the Product Owner also owns coordination. They set the priority of the backlog and thus the build order. If any trade-offs need to be made during the sprint, the Product Owner gets to make the call. At the end of the sprint, the Product Owner decides if the feature meets the acceptance criteria defined at the beginning of the sprint. They get to say when we are done.

Think about the kind of organization we are describing… probably a small start-up with a single visionary leader and a team of developers. There is no time or money for any unnecessary overhead, it is all about getting the product ready for market. There is no accountability to anyone other than the single stakeholder.

You might also see this model used on a small departmental IT project… someplace where there are no dependencies on any other part of the organization. This could be something like a small departmental website or maybe a homegrown accounting solution. These scenarios are optimally agile and optimally unconstrained… but do they reflect the reality of most organizations adopting agile? Probably not.

Next post, we’ll add some stakeholders and start to scale the size of our project. Any thoughts on what happens to our single point context and coordination model?

Next Product Owner by Proxy

Comments (2)

  1. Jeff Anderson
    Reply

    the suspense is killing us here, when are we going to get to the good stuff :-)

    Reply
  2. Mike Cottmeyer
    Reply

    Sorry… this is stuff I have been doing for a while now.. but getting pen to paper has proven pretty difficult. I start writing and there are 100 ways I want to go.

    I also don’t want to throw anything out there that is not well thought out and easy to dismiss… so I am probably going too far out of my way to be explicit in my logic and reasoning.

    Maybe when I am done, we can condense all this into a two page summary ;-)

    Good news is I have the next two posts written and I will release the next one tomorrow morning. I may do you a favor and combine the two for the sake of expediency, but then I am in a lurch for Thursday with no more time to write this week. Then again, maybe you’ll just have to be patient :-)

    We’ll see. I hope it is good suspense and that the conclusion is not anti-climatic.

    Reply

Leave a comment

Your email address will not be published. Required fields are marked *