Your Client Isn't Your Product Owner

Article Comments

1. Stephen Hawkridge said on 02 Nov 12 14:49:
   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.
2. Dan Rawsthorne, PhD, PMP said on 03 Nov 12 13:41:
   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...
3. Patrick McConnell said on 05 Nov 12 08:01:
   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.
4. Pedro Garcia said on 07 Nov 12 11:27:
   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
5. Dele Oluwole said on 10 Nov 12 01:54:
   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.
6. Carlton E. Nettleton said on 14 Nov 12 19:47:
   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.
7. Carlton E. Nettleton said on 14 Nov 12 19:47:
   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.
8. Rahul V. Joshi said on 26 Nov 12 23:09:
   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.
9. Nirmaljeet Malhotra (PMP, CSM, CSP) said on 03 Dec 12 11:32:
   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.
10. Rex Lester said on 20 Dec 12 07:20:
    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?
11. Michael Swansegar said on 21 Dec 12 21:29:
    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.
12. Patrick McConnell said on 22 Dec 12 05:26:
    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).
13. Craig Larman said on 17 Feb 13 07:48:
    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
14. Craig Larman said on 17 Feb 13 08:04:
    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.
15. Craig Larman said on 17 Feb 13 08:12:
    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
16. Patrick McConnell said on 18 Feb 13 08:42:
    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.
17. Patrick McConnell said on 18 Feb 13 08:42:
    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).
18. Patrick McConnell said on 18 Feb 13 08:43:
    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?