Product Owner (capital letters) is a role known from Scrum. The role which is defined pretty well. Sort of. Actually, sometimes I think that there are almost as many approaches to Product Owner role as there are Scrum teams.
In theory it is an ideal situation when PO is client representative working closely with a project team. That’s the theory. In practice I could hardly point any team that has comfort of such setup. More common scenario is PO on vendor’s side, a member of the team, who is acting as client’s advocate the best they can.
However, for many teams it is still too good to be true. The only thing they want is to have a single person that can answer any product-related question in reasonable time. I once called it an acceptable scenario. Bob Marshall answered that it is as acceptable as broken leg is, which is also true.
I treat such solution as acceptable as I know many teams that don’t even get this. In other words broken leg is still better than no leg at all.
Anyway, my point is that understanding of Product Owner role is um… broad, to be delicate. However, more interesting dispute would be about reasons which PO role was introduced in Scrum for. Now, excuse me this generalization, but basically PO role is there because we, as a team, want to know what the heck the right thing to build next is.
Product Owner role is set as an important part of Scrum team model, gets tools to mark out and correct team’s course (planning meetings, demos) and is a go-to person whenever any scope-related doubts pop up. Saying that PO tells the team what to do would be an oversimplification but generally it’s PO who has almost full control over what the team builds.
What about product ownership (small letters) then? Well, I’m not really fond of definitions or labels, so don’t treat the following as an oracle’s epiphany, but when I use the term product ownership I mean roots of Product Owner role: knowing what is the the most important thing to build at any given moment.
Note: I point roots of PO role and not the PO’s duties. The difference is important as Product Owner, being a part of Scrum, is pretty well-defined, formalized and prescriptive approach to the problem of product ownership. And definitely not the only one.
If we discuss a project you work on, I don’t want to know who is your Product Owner, product manager or whatever-you-call-them. I don’t even want to know how you call them or what flavor they are of. What is really important for me is how you know that you’re building the most important thing at any given moment.
If you don’t have a damn good answer for this question you’re likely wasting money of your employer.
Knowing what is important is a clue of product ownership. Good Product Owner is only one of paths of pursuing this goal.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
5 comments… add one
Pawel, i think “product ownership” would deserve probably more literature and research than “product realisation”, as this is the root of evil… i am frustrated with methods like Scrum that turns this totally obscure by positionning a ProductOwner role as a stub.
@hadrien what exactly positions Product Owner role as a stub?
@hadrien – I don’t agree with your view on Product Owner. Actually Scrum treats product ownership pretty seriously – no other area deserved a named role in Scrum team. Well, no other besides Scrum Master which is artificially created role and is specific for Scrum.
I agree though that Scrum approach to product ownership is pretty prescriptive (“do this, this and that”) but you can’t complain – this is how the whole Scrum is defined.
I also agree with what you haven’t written but have implied – Scrum doesn’t say how to choose things which are important; it just says what to do with the important stuff. However, by the ideal definition of Product Owner (client’s representative) you can expect that you get a person knowledgeable enough to make such decisions reasonably.
Of course, commonly PO setup is far from ideal, thus often sub-optimal choices in terms of what is important, but you shouldn’t blame the method really.
I entirely agree with you: product ownership is the most important aspect of software development, i.e. there needs to be a true demand for the software. Someone has to really pull at the team and say, “Where is your next working software increment so I can see if we´re coming closer to the overall goal of the project?”
If you like, read this article of mine where I´m putting this at the core of agile software development: http://geekswithblogs.net/theArchitectsNapkin/archive/2011/12/16/from-agile-to-elastic.aspx
Unless you’re truly building a product for a single customer, the product owner role in scrum is performing the work of a product manager in commercial software. The determination of what to build is influenced by company strategy, the markets a company wishes to serve, and the pervasive problems those markets are willing to pay to solve. Beyond that, the right product must be developed to solve those problems, often requiring user experience design to reach an optimal solution.