Product Owners – The Guardians
I just read an article (blog posting) on the Scrum Alliance Website that discusses the role of Product owner in an Agile Scrum project. The author, Roman Pitchler makes some great points regarding the critical importance of the role of the Product Owner on the scrum team. As you might surmise he discussed the close relationship to the scrum team in order to provide guidance in the molding of the end result. In addition, he describes the Product Owner as the one that prioritizes what will be done next as it relates to the needs of the business. He discusses the idea of proactive stakeholder management, gathering the thoughts, opinions, desires and expectations of all the various stake holders of a project to ensure that the software system is “hitting on all cylinders” if you will.
The most striking comment that I believe summarizes the primary role of the Product Owner was contained in one sentence:
“The product owner should express what value is from a customer perspective and focus the development efforts toward providing that value.”
This I believe is the true essence of the Product Owner role. Product Owners should be considered “the guardians” of the customer/business value dimension. The Product Owner is the anointed one that needs to decide if a feature on the feature/function list (product backlog) provides REAL value to the business, and that means quantifiable value. Will it streamline processes and save time (by how much?), will it make work easier and contribute to worker productivity (how much easier and by how much?), will it increase revenues (by how much?), will it reduce operating expenses (by how much?), will it increase our visibility as a company (by how many people, how often?). And, the Product Owner must be completely in tune with the overall corporate objectives to ensure that these REAL business value measures are in sync with the overall business directions and goals.
It is all too easy to proclaim a business analyst or program/project manager as Product Owner only to be influenced by the wishes and desires of strong willed personalities, authority figures or favored peers. The Product Owner, therefore, needs to be fully trained and experienced in the role of Product Owner, walk in lock-step with the corporate executives (in fact I would suggest a direct reporting relationship to the business executives), embrace the overall corporate objectives, justify the selection of target features and functions based on real value, be granted sufficient authority and accountability to ensure that business value is delivered, and be recognized and rewarded for eliminating extraneous “fat” (non or low business value contributors). Selecting and preparing the right Product Owner that will diligently and passionately drive business value should be the number one critical success factor in making Agile-Scrum work.
Pete
Follow me on Twitter at www.twitter.com/peterdeyoe
Yes, indeed, the product owner role is to ensure product success. But it’s not just about maintaining a tick list of ideas that came from execs and developers. A great product owner gets the product ideas from the market. This, a product owner must be a market expert. The difficulty with the product owner title is that this role is already called something else–a product manager. But alas, many teams haven’t worked with a GREAT product manager so they hope a new title will solve the problem.
If a product owner (or product manager) is to be the business leader of the product, they’ll need frequent and current market experience (which means that they can’t be tethered to the team every day) and they’ll need business savvy to project revenues thus they’ll need to own pricing.
Instead of discussing titles, I focus on activities. What do we want product owners to contribute to the team? What skills do they bring to the team? For more on my take on product managers and product owners, download my free ebook Living in an Agile World at http://www.pragmaticmarketing.com/liaw
Steve,
Thanks for your post and I cannot agree with you more completely. Having the pulse of the market is an essential function of the Product Owner/Manager. And, the business savvy is equally essential. It is truly a “Big Picture” function that they must play. Too many times I have seen the Product Owner floundering in the minutia of a project and missing the boat on true business value delivery. And as far as titles go…a rose by any other name…
Thanks again!
Pete
Currently, I am working on a new customer service platform for a major financial entity. We practice Agile methodology. Our product owners are branch managers and district managers who have intimate knowledge of the system and how it currently operates. Because of this, they know what functionality can be enhanced in the new system and what cannot be enhanced due to limitations with Chordiant. Together with the B.A.’s in Solutions, if a functional requirement from a workflow team cannot be fufilled, the product owner will suggest alternatives. They see the “Big Picture” and are sometimes chastised for this by the workflow teams because they aren’t adhering to the functional requirements that the WFT created. Product owners keep the velocity of the project going and are instrumental in the creation of a successful end product.
A good post, Pete. It is interesting that so much onus rests with a single individual, however. In many projects, as you observed, the product owner flounders. Your suggestion that the product owner be “trained” is a good one, but it is often the case that this “training” is insufficient. As Agile seeks to mitigate risk by spreading responsibility across the team, how can a team protect for this critical issue?
One possible solution is to require a connection between what the product owner knows — user stories — and what the business needs. That is, each story must be tied to a “business value” (that set of things the executives are attempting to achieve with their approval of the product). As often happens, product owners get caught up in “features”. If forced to justify each feature against a core business value, we can likely reduce the set of backlog items that appear down to a core, manageable amount and thus reduce the risk of floundering and, ultimately, we can succeed.
Dan,
Thanks for the response. I really like your idea that each user story have a required business value criteria built in. This serves a couple of purposes. 1. the entire team understands how this particular feature addresses business value delivery so that the entire team is focused on it. 2. It provides the Product Owner and Scrum Master a means for discussing what truly is critical to the project so when the backlog is prioritized and reprioritized, there is less “gray” area.
Also, in regards to the training…I think the content of the training has typically been around transactional activities rather than around principles of Agile and software development. For instance, how does a Product Owner identify and quantify business value? So, I think the training and preparation of Product Owners needs to be expanded and enhanced.