Product Owners are critical in an Agile team: they are the primary link between business and developers. The concept of Product Owners is awesome – as awesome as the idea of unicorns, and perhaps as unattainable.
Scrum defines a Product Owner as “representing the customer’s interest in backlog prioritization and requirements questions. This person must be available to the team at any time”.
Let’s go through what can be expected of a product owner on a typical business project:
- Gather specifications from various stakeholders within the business, and build the stories that the team will work from.
- Manage the priorities of the Backlog, deciding on which features will give the most business value.
- Have the excellent communication skills to understand the business users as well as the development team.
So we have a role defined that requires high level strategic thinking around business value and priorities, with a need for highly detailed thinking on stories, and the ability to understand the highly technical needs of the developers as well as the business needs of the users.
Rather a large order, wouldn’t you say? I’m not saying that such talented individuals don’t exist – I am querying the thinking that defined a role that would be so hard to fill!
Look at the roots of the Agile movement – essentially, 17 very technical people got together at a skiing lodge in Snowbird Utah, and laid out the agile principles over a weekend. Scrum is one of the commonest implementations of Agile, and it is in Scrum that the role of the Product Owner is most fully defined. Scrum has its roots in the same developer mind-set that shaped the Agile Manifesto, including some of the same authors.
When I look at the almost impossible role that Scrum defines for a Product Owner, I just hear the age-old developer plea for a user who can tell the development team what they want.
This is broken on so many levels. The key one being that Scrum has enabled developers to retreat from interacting with a wide set of users and instead rely on only one channel of communication from the business: the Product Owner.
It shouldn’t have worked out like this. Scrum never dictated that developers shouldn’t talk to users, but the mere existence of the Product Owner role has lulled many teams into believing that all business requirements will be handed neatly pre-chewed to them via their Product Owner.
Other methodologies like Lean also have a similar approach where stories and scenarios are defined ahead of the team being ready to develop those features, and so also cement the idea that the stories are “ready to dev” straight from the Product Owner.
When you have a perfect Product Owner, this might seem like a reasonable approach. However, it never is! Between the facts of the requirement as expressed by the story, lie a thousand little details that make the difference between user friendly and efficient software, and the horrid end results that you will find in so many projects.
I want to see development teams “get out the building” to borrow a phrase from Lean Startup. To get out the building is the idea that you take your early prototype to real users and get feedback. This can be as simple as taking a tablet to a shopping mall and asking random people if they would use your product!
Simple, but perhaps not easy for developers who are often introverts and find it very hard to speak to people. That’s part of why the role of the Product Owner has been so persuasive for so long. But we need to get over how hard it is, and get our teams back in touch with our users.
We can’t afford to have teams locked up in back rooms, waiting for elucidation from their Product Owners. This has been a comfy little cocoon that we have tolerated for far too long, and we need to recognize that it is not serving anyone’s best interests.
I have a number of possible improvements to suggest:
- Focus the Product Owner role on defining business value. The type of individual best suited to the role would be a high level strategic thinker, with good communication skills (because you can’t be in business without good communication skills anyway).
- Re-introduce the role of Systems Analyst. This is a rather antiquated term that was replaced a few decades back by Business Analyst, but we lost something in the replacement. The Systems Analyst had a development background, and understood the impact of the users’ requirements on existing software, as well as the development effort required. They may not understand the business requirements as well as a Business Analyst drawn from the business side would, but it is in that tension between business and IT that the best conversations can be had to challenge old ways and produce better software. I would suggest that any of the more experienced developers on a team could act as System Analysts as well as developers. These are the detail oriented people needed to produce accurate user stories and scenarios. As active members of the development team, we would be ensuring that they are developing the skills and knowledge to develop software that users want.
- Include “get out the building” time in your sprints. For instance, if you are developing a new feature for your finance department, you could arrange for the development team to shadow the users in finance as they do the task that will become the new feature. This works very well where you are automating a manual process, or improving an older system. “Get out the building” is a neat phrase to sum up the fact that the team must go out to some real users to understand the unspoken subtleties of the new feature. The only possible exception might be some very technical server-side software, but most commercial software needs interaction between the development team and the real users.
I’d love to believe in Unicorns, but I’d prefer to have great systems produced by engaged and empowered teams. The current definition of the Product Owner role sets too many people up for failure: from the super-human expectations of a Product Owner to the isolated and out of touch development teams.
Goodbye unicorns – the fantasy of the perfect Product Owner has outstayed its welcome…