Agile introduces a new product management role: the product owner. The primary responsibility of the product owner is to groom the product backlog, present stories to developers, and act as the “voice of the customer” for the development team.
The product owner role provides the crucial interface between developers and customers to quickly collect customer feedback at the end of each sprint, and adapt to changing customer needs. In essence, the product owner role is about embedding product management into the development team to remind developers that customer value should drive their decisions, to remind product managers that not all features are technically equal, and to proactively respond to the changing needs of the market and customers before the release goes out.
The product owner role is time-consuming: ahead of sprint planning, the product owner writes user stories and collaborates with testers on acceptance criteria, at sprint planning, she explains to her development team the stories to work on in the next couple of weeks. During the sprint (usually one to four weeks), she monitors progress, make decisions on alternative implementations, answers questions, validates completed stories, and prepares her stories for the next sprint.
So what happens to the traditional product manager tasks? Who stays in touch with prospect demands? Who keeps a pulse on market trends and competitors’ moves? Who reviews sales recent win/losses? Who defines packaging and pricing for new products? And who educates sales and support about new features?
Avoiding the Single Biggest Pitfall
When teams adopt Agile, product managers are often not part of the first pilot in which development teams are getting used to Agile practices – from short time boxes to continuous integration and test-driven development. At that point, often a technical lead will assume the role of product owner. Once the development team is familiar with these key Agile development concepts and starts delivering on a more frequent cadence, they then want to make sure their efforts lead to greater value to users, at which point the product owner role needs some “real” product management skills. That’s when the traditional product manager is usually pulled in to join the Agile experience.
The biggest pitfall is to simply transition existing product managers to become product owners. It seems like a natural transition when everyone is focused on adopting agile, yet there is a heavy price to pay. When a company falls into this pitfall, one of two things can happen as traditional product managers are forced to pick a focus:
The most common scenario is a product manager who fully embraces her new product owner role: she learns to write good stories and gets to know her development team.
The short-term cost: this leaves no time for the traditional product management tasks mentioned above, so those fall by the way side.
The long-term cost: an incredibly productive development team delivering software that is launched at the wrong time, with the wrong price, with sales and support poorly enabled and, as a result, unable to reach the target audience and bring the expected revenue.
A less common scenario is the product manager who does not embrace the product owner role. That individual prefers focusing on “big picture” topics than the tactical day-to-day product owner duties. In this scenario, you often see the sprint user stories lacking acceptance criteria. Because traditional product managers were not in involved in validating requirements (most often the quality assurance group was), writing acceptance criteria is often a challenge, and are quickly overlooked.
The short-term cost: the team flounders with poor requirements, making assumptions as they go, because “the voice of the customer” is absent.
The long-term cost: team frustration and costly rework. Stories without well-defined acceptance criteria run the risk of not being accepted at the end of the sprint, resulting in frustrating and costly rework to deliver actual customer value.