Your Client Isn't Your Product Owner

2 November 2012

Sometimes, when an organization is adopting Scrum as its development model, the following unfortunate thing happens: A decision maker with authority over the team-to-be is trying to match existing people to each of the Scrum roles, and he or she thinks, "Product owner . . . well, that's obviously the customer."

Wrong. In almost every case.

If the process formation proceeds from the premise that a client-side individual will fulfill the role of product owner, the most likely outcomes include:

  • A string of flailing, low-value product deliveries
  • Programmatic black eyes for both customer and vendor
  • Increasingly loud calls from leadership to regress to whatever development method was in place before the attempt at Scrum

 

Why? Because it doesn't matter how well you build software if you build the wrong things. Figuring out what to build (and what to build first) is the core job of the product 0wner. It's difficult. It's probably a full-time job. And your client already has one of those.

 

The product owner as core determinant of successful Scrum

To deliver value, Scrum requires an efficient, accurate mechanism for determining a product's vision and an able pipeline for distilling that vision into concrete, deliverable backlog items that can demonstrate tangible benefits and function as part of the longer-term project vision. It is for this reason that the performance of the product owner becomes the prime limiter of the team's success.

While product owners participate in each of the Scrum rituals, their core job functions run outside and parallel to the jobs of the ScrumMaster and team. Essential product owner tasks include:

  • Facilitating an achievable and valuable vision for the product
  • Guiding and adjusting an iterative release strategy that fits into the prevailing market tempo
  • Distilling high-level requirements into deliverable user stories with complete acceptance criteria
  • Enabling accurate prioritization of the product backlog
  • Communicating complex issues of system architecture and technical debt back to clients
  • Negotiating client-side disputes about requirements, design, and priority

 

In essence, then, the product owner fills two major roles: proxy client when facing the Scrum team, and product management coach when facing the customer.

 

Skills and commitment necessary to be a good product owner

Being a good Scrum product owner requires a wide array of skills. To list a few: business process analysis, requirements analysis, product lifecycle management, configuration management, organizational marketing, IT program management. and consensus building. In traditional Waterfall development efforts, each of these activities may be carried out as individual functions by entire departments of personnel, but Scrum requires some proficiency in all of them — and the awareness to solicit additional support when necessary.

This also means that for most efforts, being the product owner is a full-time commitment. On large projects with multiple teams, it's reasonable to portion out the role into a "strategic product owner" charged with maintaining product vision and release planning across all of the teams, and "tactical product owners" engaged on a one-to-one basis with each feature team to handle nuts-and-bolts decision-guiding with clients and to provide daily feedback in the various Scrum rituals.

These two considerations, the necessary skills and level of commitment, are what generally prohibit client-side individuals from being good Scrum product owners. If your customers don't have the ability to determine a cohesive, deliverable vision for what you're building, or if they can't commit to being accountable to the team at a level that enables rapid delivery, then they aren't suited for the product owner role.

 

Discouraging clients from assuming the product owner role

Educate your customers. If their organization is new to Scrum and you're "selling" the programmatic benefits of the Scrum process, highlight how difficult and time-consuming good product ownership can be. Make the idea of supplying a vendor-side product owner a core part of your value proposition: "We not only bring Certified ScrumMasters (CSMs) and Developers (CSDs) to the table, we bring Certified Scrum Product Owners (CSPOs) to make sure this effort has the greatest possibility of success." Sharpen the clients' awareness of the conflicting stakeholder and user landscapes for the chosen market, and illustrate how a good product owner will help them focus on the most important segments of those pools. Demonstrate how product owners can help bring complex initiatives in better alignment with on-the-ground mission needs. In short, help them understand that good product owners help turn busy customers into heroes, both inside and outside their own organizations.

 

How to cope if it's already happened

It's never too late to give your client a product owner. If your relationship is healthy enough for open critique, make a case that the project will work better with a trained, vendor-side product owner, and you'll be able to prove it almost instantly. If that pitch is not feasible, make a less obvious case. For example, state that as part of a process improvement initiative, you want a vendor-side "tactical product owner" to support the customer's "strategic product owner."

However you accomplish it, once your product owner is in place, it shouldn't take long for him or her to be seen as delivering significant value and for the performance of your Scrum team to improve. This can easily be leveraged into a competitive advantage, as customers begin to tailor follow-on vehicles to ensure that this support continues and that other efforts also require CSPOs in addition to CSMs and CSDs.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 1 (1 ratings)

Comments

Stephen Hawkridge, CSM,CSPO, 11/2/2012 2:49:25 PM
Thank you for the article. I've been wrestling with this exact issue. The teams I work with are confronted with the legacy act of the customer assuming the product owner position, usually to the detriment of the process. The customer very seldom understands the scrum process and thus creates more issues than benefit. I agree completely with the conclusion that the entire scrum team (PO, SM, and dev team) should be from within the company doing development and should have sufficient training in their prescribed roles.
Dan Rawsthorne, PhD, PMP, CST,CSP,CSM,CSPO,REP, 11/3/2012 1:41:34 PM
You are absolutely correct, but you don't go far enough. As you say, the main purpose of the Product Owner is to make decisions about what to do next - this is what the PO is accountable for. To do this effectively, the PO must be a full-time member of the Scrum Team, and this precludes lots of candidates: clients, marketing guys, project managers, and so on. This is a major point in my CSM and CSPO classes, as well as in my book, "Exploring Scrum: the Fundamentals". Unfortunately, many scrum gurus and authors get this wrong,likely because Ken Schwaber got it wrong in his first two books (he finally got it right in his 2007 book, "the Enterprise and Scrum"). As the latest example on my bookshelf, see pgs 176-180 of Kenny Rubin's new book, "Essential Scrum". This movement of the PO from the client/Customer to a full-time Team Member is an adaptation that Scrum has made to itself over the last 20 years, and was finalized (but obviously, not fully accepted) in 2004-5 or so. It's a big deal...
Patrick McConnell, CSP,CSM,CSPO, 11/5/2012 8:01:54 AM
Thanks for reading the article, Stephen and Dan, and thanks for the feedback!

This is a problem on several teams that I've been coaching lately, and one that I hadn't encountered before (In prior engagements, I'd been dealing with clients that were completely new to Scrum, so it was natural for our teams to assume all of the scrum roles, with the client-facing project manager serving as the Product Owner).

Since writing this piece a few months ago, one of the teams I'm involved with has done something interesting to help with the problem of client-side Product Owner engagement: In the re-up of the current contract, they've specified 'Service Level Agreement' type language that spells out exactly how engaged the client's Product Owners need to be. I now include that as a formal strategy for coping with this issue in my internal Scrum Master and Product Owner courses.
Pedro Garcia, CSM, 11/7/2012 11:27:25 AM
It's a good point. We adopted Scrum 3 years ago in our organization. The first mistake was to give the PO's responsibility to the Clients. We tried to training to them in the Scrum... and we learn soon that it didn't work. Now, the PO is a member of our team very close of the Client vision. The PO is a filter and catalysis of the client's product. Our PO background is Business Analyst... so, he has the skills to identify the priorities of the project, deal with the clients and write a good Product Backlog.

Thanks Patrick
Dele Oluwole, CSP,CSM, 11/10/2012 1:54:38 AM
Product Ownership is all about effective representation;
Anyone, who can represent the interest/vision of the product successfully either by proxy or directly is a product owner, he or she must be able to drive down the vision of the product through the scrum team.
The scrum team must see the PO as someone who they must make happy.
It is therefore not typical if the Product Owner is a client or a customer as long as the PO can represent, and facilitate the vision of the product effectively and successfully.
Carlton Nettleton, CST,CSP,CSM,CSPO,REP, 11/14/2012 7:47:32 PM
Your experience matches my own - the client already has a fulltime job and does not need another one by accepting the role of Product Owner. The people who I encounter who hold this belief often come from the professional services world where the client is paying an outside contractor to execute on some type of product or service the client cannot produce.
Carlton Nettleton, CST,CSP,CSM,CSPO,REP, 11/14/2012 7:47:32 PM
Your experience matches my own - the client already has a fulltime job and does not need another one by accepting the role of Product Owner. The people who I encounter who hold this belief often come from the professional services world where the client is paying an outside contractor to execute on some type of product or service the client cannot produce.
Rahul Joshi, CSM,CSD, 11/26/2012 11:09:21 PM
Thank you for the very good article that you have presented. I am currently experiencing all that effects that you mentioned above when your PO is either one of the Client/Marketing Guy / Project Manager. The last point of "Never being late.." is the next step for me.
Nirmaljeet Malhotra, CSP,CSM,CSPO, 12/3/2012 11:32:22 AM
I have part of company providing Agile consulting and an organization that is internally implementing Scrum and each time there are enough reasons for the world to assume that customers would make the right Product Owners. Talking of projects where the customer is trying to replace legacy with next gen systems where you need someone with an excellent understanding of how the business runs and who better than the functional SMEs? Why should one spend the time in educating professional POs about the client business which would potentially have matured over a few years/decades?

We resolved this issue in one of our projects by ensuring that SMEs who were assigned to the projects were trained to be effective Product Owners and agree on the Product Owner deliverables. This included aligning with thr product vision, writing user stories, being available to the team etc etc.

I think given the present scenario, it would be smarter to NOT rule our customer being a Product Owner. Rather appropriately train them to perform a effective Product Owner role.
Rex Lester, CSM, 12/20/2012 7:20:01 AM
Thanks for the article, very interesting... My thoughts are that Business Analysts do make good Product Owners but they need to be embedded in the business and not part of the development organization. That should give them the autonomy and accountability they need to perform the role?
Michael Swansegar, CSPO, 12/21/2012 9:29:54 PM
I am greatly disappointed in this article as it points to the certifications as an answer. A 2 day class does not mean anything.

This is the worst line of the entire article:

""We not only bring Certified ScrumMasters (CSMs) and Developers (CSDs) to the table, we bring Certified Scrum Product Owners (CSPOs) to make sure this effort has the greatest possibility of success.""

You should be ashamed for saying something like that. If the client knew and understood the training in the CSM/CSPO classes they would laugh in your face. The CSPO especially is very basic and misleading.
Patrick McConnell, CSP,CSM,CSPO, 12/22/2012 5:26:00 AM
Michael:
IΓÇÖm sorry you didnΓÇÖt like the article. YouΓÇÖre right: Certifications are never a guarantee of individual ability, or that an entity will deliver successful products. They are, however, one of the quantifiable ways that an organization can demonstrate commitment to Scrum. The selling pitch that you object to is not meant to be received as, ΓÇ£CSPO automatically equals good Product Ownership,ΓÇ¥ but rather, ΓÇ£As an organization, we recognize that Scrum Mastering, Product Ownership, and Scrum Team Membership are all separate vocations, and weΓÇÖve at least spent some time and money trying to give our people the tools to succeed in each of those areas.ΓÇ¥

I work primarily in the US Government IT services sector. In much the same way that large projects are now required by the Government to have a PMP running things, itΓÇÖs becoming common for Agile development RFPs/RFQs to require that the software development lead be a CSM. Imagine: A several-hundred-body software initiative, and every firmΓÇÖs response spells out that they can be trusted with taxpayer dollars because a single CSM will be at the helm! Having CSPOs involved too (especially if theyΓÇÖre CSPs) can be a differentiator over competitors, because itΓÇÖs a way of telling the buyer that you understand that Product Ownership is the limiter of Scrum success.

Often thatΓÇÖs the best case I can make in a proposal. Ideally, I would demonstrate Scrum success by showing prospective customers my Teams in action, and letting them play with the tools we build. But unless theyΓÇÖre already my client, that opportunity never occurs for reasons of security, classification, conflict with contracting regulations, and a host of other concerns. So instead I default to what (I think we both agree) are the least meaningful indicators of future success: certifications and past performance.

But maybe IΓÇÖm thinking about this too narrowly. If youΓÇÖve got other ideas about how best to claim organizational Scrum competency, or quantify Product Ownership ability, I would love to hear them. IΓÇÖm always interested to find new ways to sell the services I provide (or to ghost my competitorsΓÇÖ pitches).
Craig Larman, CST,CSP,CSM,CSPO, 2/17/2013 7:48:25 AM
Well, somewhat disagree: it wouldn't hurt to remember the history of the name "Product Owner." (i asked Jeff years ago...) it was chosen by Jeff Sutherland to imply "the owner of the product" (surprise) and in the first Scrum adoption by Jeff, the PO was the head of Product Marketing/Management. so a classic good choice for PO is the product manager for a product, as in the first Scrum adoption. and remember, the PO, per original definition, is the person responsible for ROI and who can independently choose/change release date and content; neither you nor i get to change that definition. the intention of the name was/is "the ROI owner of the product also becomes the Product Owner" and strongly related to all this is the "end of the contract game" where a traditional business owner shifts responsibility to an R&D project manager for "the project contract"; rather, in Scrum, the business-side person no longer (to use ken's words) "throws the project over the all" but rather, directly steers and collaborates with the Teams. i.e., Customer collaboration over contract negotiation. It is *very* important that the PO be from the side of the wall that previously was throwing the project over to the R&D side ;)

-craig
Craig Larman, CST,CSP,CSM,CSPO, 2/17/2013 8:04:13 AM
And also disagree with your following phrases: "an able pipeline for distilling that vision into concrete, deliverable backlog items" and "Distilling high-level requirements into deliverable user stories with complete acceptance criteria". if you are familiar with lean thinking, or simply observant, all that implies the wastes of hand-off, information scatter, delay, and "working to job title" (among others). you are reducing the PO to a kind business analyst and project manager. the *Team* should do most of the detailed analysis (during PBR) in collaboration with SMEs (which may include the PO). you seem to not know that "stories" is a *behavior* (not a template) that emphasizes the 3 Cs: card, conversation, confirmation. the idea is requirements is done by the team in conversation with other SMEs. to suggest "doing stories" is something done by a separate person who is an "efficient pipeline" is a rather gross misunderstanding of the original point of stories. this is simply old skillful R&D 101: the implementers should do the detailed analysis of things they will implement - the Team is cross-functional and does most everything. Scrum is not a model where an upstream fake PO (fake PO AKA business analyst & project manager) defines the detailed requirements and *hands-off* to the Team.
Craig Larman, CST,CSP,CSM,CSPO, 2/17/2013 8:12:12 AM
Very much disagree with this statement: "A decision maker with authority over the team-to-be is trying to match existing people to each of the Scrum roles". In what way does this illustrate the spirit of self-organizing teams or the elimination of command-control manager and top-down thinking? why can't the people themselves decide their team composition in a self-designing teams workshop (which i have seen or facilitated several times). your assumption that a "Wise Manager" has better knowledge to do this than the people themselves, or your assumption that of course it would be decided by a manager suggests you have not yet fully grasped the implications and possibilities of eliminating command-control and moving to much more self-management.

this article reminds my of the apparently increasingly low quality of insight found amongst SA participants and is perhaps a reason why many early CSTs no longer bother to participate. Scrum is almost being mutated into traditional development with simply changed titles and some minor changes, rather than the much deeper implications it was founded on.

-craig
Patrick McConnell, CSP,CSM,CSPO, 2/18/2013 8:42:17 AM
Response to CraigΓÇÖs 1st comment:
It donΓÇÖt think weΓÇÖre in disagreement about what the Product Owner ΓÇÿshouldΓÇÖ be, but thatΓÇÖs not really what my article is about. The ΓÇÿIT ServicesΓÇÖ landscape functions differently from that of ΓÇÿproduct companiesΓÇÖ where Scrum and other Agile approaches were pioneered. Especially when your client is a government, these differences can significantly interfere with the establishment of high functioning Scrum. The point of my article is to how to recover and create the space needed for a Team to perform when a fundamental decision (who should be the Product Owner) has been decided ahead of time by someone who doesnΓÇÖt understand the role, and then that decision is formalized in a contract or task order.
Patrick McConnell, CSP,CSM,CSPO, 2/18/2013 8:42:49 AM
Response to CraigΓÇÖs 2nd comment:
HereΓÇÖs what I expect a Product Owner to do, in a nutshell: Articulate the starting line for a story (description), and nail down the finish line (Acceptance Criteria). I donΓÇÖt expect the PO to tell the team what course to take in between or what travel method to use. I donΓÇÖt expect them to personally generate every detail in the description or the AC, but rather own the process of getting those elements determined in back-and-forth conversation with Teams and stakeholders to a state that the Team considers workable before a given story is pulled into a Sprint. ThatΓÇÖs the ΓÇÿpipelineΓÇÖ IΓÇÖm talking about. ItΓÇÖs a lot of work, and thatΓÇÖs one of the reasons that a client with Program Management and ΓÇÿProduct OwnerΓÇÖ responsibilities for 4 or 5 different projects probably wonΓÇÖt be able to do it well (whatever their individual talents may be).
Patrick McConnell, CSP,CSM,CSPO, 2/18/2013 8:43:49 AM
Response to CraigΓÇÖs 3rd comment:
Again, my point is that this circumstance happens a lot in Services contracting. I am not, in any way, suggesting that is how Scrum should work. I donΓÇÖt assume that thereΓÇÖs a ΓÇÿWise ManagerΓÇÖ better able to make this decision than a Team; IΓÇÖm stating that right or wrong, this decision has often been made by a prospective client or Business Development type long before the Team existed, and then set into stone in the eyes of those paying for the effort and accounting for whether youΓÇÖre meeting whatever objectives were set into the SOW.


The tenure of your comments show an understanding of Scrum that is largely ignorant of how things work in large-scale services contracting: We donΓÇÖt do Agile instead of Command and Control, but in spite of it. Our clients function only as hierarchies and nested ranks, and insist that we appear to as well. One of the core challenges of implementing Scrum in this context is creating breathing room within those structures to self-organize. When core elements of ScrumΓÇÖs necessary self organization are coopted before you start, you either find a way to recover (in this case inserting your own PO to assist the ΓÇÿofficialΓÇÖ one), or just embrace that your team will never be successful.


As for your final dig, IΓÇÖm not sure how to respond. How is my article indicative of a ΓÇ£lack of insightΓÇ¥ in recent articles on Scrum Alliance, when in this case youΓÇÖre mostly upset about assumptions I donΓÇÖt make and didnΓÇÖt write?
Andy Deighton, CSM, 4/7/2014 5:28:40 AM
@Michael Swansegar: it might be worth putting a request in with Scrum Alliance to change their site so that it *doesn't* put "CSPO" after your name (or whatever other qualification is listed), if you truly believe the letters have no weight! :-)

You must Login or Signup to comment.