In my previous article, When Scrum is not Scrum, I listed five criteria that must be met to say you are doing Scrum:
- Teams pull work from backlogs at their own pace
- Feedback is implemented at a higher priority than new development
- Defects are corrected at a higher priority than new development so that releases remain “potentially shippable”
- Sprints produce working functionality, not chunks of software
- An engaged product owner can convey the problems to solve for the team
That article addressed all but the fifth – having an effective product owner.
I observed that the inability to implement the product owner role was one of the biggest contributors to the missed expectations of Agile. Yes, there were instances of success, but mostly in smaller organizations with one or two teams. My clients were typically large product organizations with established product management departments.
The term “product owner” caused a lot of confusion in organizations with established product management departments. In the minds of product managers, they were the “product owners” because they had overall responsibility for the success of the product. Many product managers added the Scrum product owner role to their current responsibilities, but that wasn’t effective. They had little time other than to show up at the sprint review to tell the team how badly they missed the target.
To this day, I still see organizations that have anointed product managers with the title, “Product Owner,” as if this somehow makes them “Agile”. The term actually refers to a Scrum role, not a title. The Scrum product owner is continuously engaged with the team to guide them towards the right solution. It’s not enough to provide detail at the user story level and expect the team to get it right, especially when the company is in a complex domain foreign to the developers. High level user stories may work in cases where the developers are users of the products, like video games or streaming services. Not so much when the domain is financial services or medical devices.
Of course, the product owner is supposed to approve user story acceptance tests before development starts. This rarely happens. And, if it does, the acceptance test only covers the “happy path” needed to demonstrate the functionality at the sprint review.
So, why does the product owner need to be continuously accessible to the team during sprint development? Can’t team members just email or chat with the product owner when they have questions? That doesn’t work. When the teams can’t get with the product owner at the time implementation decisions have to be made, developers will make assumptions – especially under pressure from waterfall planning. The assumptions might be correct when the developers have deep experience in the domain, but that isn’t the typical case.
There’s another reason why I saw ineffective product owner roles. Most of my clients were product organizations with thousands of diverse users spread around the world. Who is the all-knowing product owner who can represent all these markets? Who does the competitive analysis and develops market strategies? This is the role of product managers, not product owners.
The line between the product managers and product owners has been blurred. And, as in most cases where responsibilities are not clear, individuals do the job they are most comfortable with at the expense of other work. That’s why I see product managers who spend their time down at the UI level and complain about having no time for competitive analysis or market research.
So, how can the Scrum product owner role be made more effective? We need to recognize that the product manager plays an important and separate role in product organizations. They do market research, competitive analysis, determine market strategies and support sales. They develop pricing strategies and models and create Go-to-Market plans. They develop partner strategies and are responsible for “make versus buy” decisions. I could go on, but it should be clear that the product manager doesn’t have time to serve as the Scrum product owner. And they are paid too much to be wallowing in implementation details. That’s the role of the Scrum product owner.
Scrum product owners have found it difficult to perform their roles in organizations with product managers. Product owners are often shielded from the direct customer contact necessary to understand implementation details. The old product management “voice of the customer” model must be retired. Product owners need two things. The first is an understanding of the business problem to solve. The second is direct contact with customers to translate the business problem into a solution in the form of user stories and acceptance tests.
In a previous article, Save Agile – Stop Waterfall Planning I explained “Agile Investment Planning” can replace waterfall planning with small increments of value that can generate revenue or reduce income. This approach creates clear demarcation between the product manager and product owner roles. Product managers are responsible for planning Investments that create financial value. Product owners work with the teams to define the functionality to achieve that value.
You’ll find that some of your product managers are better suited as product owners. Product managers can no longer hide behind feature and functionality details that “take all their time.” Professional product managers who can create business value will evolve. That’s what product management is supposed to be about. And you can develop effective product owners that engage with the team to define functionality to attain that value.
Watch for my next article, The Secret of Agile Team Motivation in Four Words. You’ll be surprised at how easy it is to create high-performance Agile teams.
For you engineers out there, I hope you forward this article to your product managers so they can adopt Agile planning to let you do real Scrum and meet the predictability they expect.