Why Product Owners?

In a Waterfall environment, teams divided by specialty hand off a project several times from inception to delivery. The need for a Project Manager to track each hand-off, the budget spent by each team, and the deadlines per team seemed obvious: how else would stakeholders have any visibility into an investment? Naturally, because Return on Investment was delayed until the deliverable reached the end-user, larger projects needed several Project Managers. IT, HR, Operations, Business Development and other stakeholders often provided their own Project Managers.

Scrum, in contrast, circumvents the need for checklist-keeping by driving the continuous visibility of the productand keeping its value easily “shippable”. No one wants a never-ending project, but a great product is expected to have a long lifecycle. Scrum puts that product in the hands of end users and stakeholders constantly so no one needs ask “What’s the status?”

Ownership of a Product:

So why do Waterfall projects have managers while Scrum products have owners? Because the most important thing the Product Owner owns is accountability. Scrum empowers cross-functional and self-organizing teams to make the best solutions possible, delivering working software constantly, while incrementally and iteratively increasing the value of the product. In a Waterfall world, this extensive team-level “solutioning” would have been terrifying due to multi-team diffusion of responsibility. In contrast, the Scrum team is empowered to make great solutions because a final decision-maker owns all accountability for decisions made.

While projects frequently end in a “Waterfall Witch-hunt”, a product with a single owner – accountable to the stakeholders for their investment, the end users for the value of the experience, and the team for technical risks taken – has a clear and transparent “single neck to choke”.

For more information on Scrum and best practices in Product Ownership, follow my blog or connect with me on Twitter and LinkedIn.