On-site Product Owner
Lack of user involvement traditionally has been the No. 1 reason for project failure. Conversely, it has been the leading contributor to project success. Even when delivered on time and on budget, a project can fail if it doesn’t meet user needs or expectations.
— Software Magazine, Feb. 2001, Collaborating on Project Success
— Based on the Extreme CHAOS 2001 Report from The Standish Group.
Agile teams deal with the issue of business and user involvement by having a person who is empowered to specify the User Stories, set their priority and to answer questions about them in order to clarify the real requirements. Ideally, this Product Owner is co-located with the development team, although an even better approach is to locate the team with the Product Owner.
The effect of having the Product Owner working so closely with the development team is two-fold:
- Communication improves dramatically. Verbal discussions provide much more valuable information than e-mail or hard-copy documents, and thus costs and the time taken to make decisions are reduced. This isn’t to say that no documentation is produced, but rather that the documentation should be the result of a conversation first, and not vice versa.
- Decisions are made more quickly. Because the Product Owner is readily accessible, questions can be answered and decisions made in very short order. This allows the team to keep moving forward, rather than waiting for answers or performing speculative work.
Providing a Vision
Because of its importance in ensuring the success of a project, the Product Owner role requires certain traits in the person who fills it. They must be able to make informed decisions quickly and not waffle on their answers. If they don’t know the answer to a question, they need to be able to say so and then follow through with getting the answer as quickly as possible. They need to know the business that will be supported by the system quite well. They also need vision.
For a small system with a focused group of users, having an end-user as the Product Owner is fine. When a system is larger, for example if it has a large user base or crosses several lines of business, the Product Owner needs to have an overall strategic vision of how the system is going to be used to support all of its users. This requires someone at perhaps a management level, or they have a reporting relationship with C-level management. This is required because the issues faced by this Product Owner increase considerably with the number of lines of business in the system. Often, these issues require resolution from a higher level of management, and having a Product Owner either at that level or with a direct reporting relationship to that level will speed the resolution process.
Scaling the Product Owner
It’s quite rare that the Product Owner for a system is able to devote all of their time to the product ownership role. As a result the Product Owner role filled by a single person doesn’t scale very well as a system grows or if the system has multiple stakeholders, each with their own competing priorities. Some strategies to help are:
- Business Analysts function as ongoing proxies for the Product Owner, working directly with the team and able to answer 75% of questions on the spot * Product Owner team, with one person who is empowered to make final decisions if consensus cannot be reached
- A hierarchical Product Owner group, with single Product Owners for very focused areas of the system
Summary
The Product Owner role is the single most important and difficult on any type of project, but is especially important for an Agile one. However, by having a dedicated person located with the development team, the chances for success increase tremendously.
These posts may also be interesting...
Smaller User Stories?We are the Borg
Every little thing
What problem are you trying to solve?
There’s a new look around here
Product Management
comments powered by Disqus