In the busy world of software blogging and speaking circles it's tempting to use an attention-grabbing, controversial title to present an often less than controversial subject. One method that's particularly effective at getting attention, primarily because it stirs up strong emotions, is the post title announcing the death of a software role.
This happened with testing a decade ago as people proclaimed that 'testing is dead' (most famously a GTAC keynote by Alberto Savoia), while actually discussing an evolution of testing skills and responsibilities. More recently I've read some similar arguments in relation to product owners, tempting us with inflammatory statements around 'doing away with Product Owners'.
I understand the reason for this kind of positioning. Challenging the status quo is a proven technique to drive readership and maintain a position as a thought leader. At the same time I think that there are real dangers to this kind of positioning.
The title vs the content
Here are two articles that have been shared with me recently. Both nominally about getting rid of product owner roles.
- Mike Cohn's article "Is it time to do away with Product Owners"
- and Joshua Kerievsky's "Eliminating the Product Owner"
On the face of it both appear to suggest that the Product Owner role is no longer necessary and should be removed. To support this both authors do argue that it should be a whole team approach to understand stakeholders and maximise value for them, this shouldn't be the responsibility of just one role.
Reading more deeply though - what both authors also suggest is that teams taking on this responsibility should include an individual who specialises in product thinking, just as other individuals take more responsibility for, say, testing (who obviously aren't testers, that role is dead). This is a far less dramatic shift than suggested in the post titles to the extent that the cynic in me feels that a more appropriate title for such a post might be:
'Is it time to subtly change the product owner role to be more embedded within product teams and to collaborate more with those teams to gain consensus on prioritisation decisions?'
however that would be a far less controversial position, not least because that is what most of the good product people I've seen were doing anyway.
Where's the harm in getting a bit of attention?
So one might argue that there's no harm in presenting a non extreme argument under a more controversial heading to get a bit of attention. I disagree. I personally believe that such positioning does cause problems. If politics has taught us anything recently it's that simple punchy and memorable messages persist faster and further into common consciousness than the boring practical details. What I've observed is that people can make some extreme decisions using 'current thinking' as justification.
By way of an example - a few years ago I worked with a company who had taken the 'testing is dead' position literally and had taken the approach of having no testing expertise in the building. They'd left all of the testing responsibility to the developers, without providing those people with any training in testing skills or establishing a clear definition of responsibilities. Needless to say they were struggling with reliably delivering working software and were suffering from high impact of production issues.
Stripping out roles and relying on 'the team' picking up new responsibilities without the requisite expertise is not something that any team should consider lightly. Read deeper into any post proclaiming the death of a role and you'll discover a caveat of keeping the skills provided by the individuals in that role through some other means.
Why not to get rid of product owners?
Just in case anyone was considering taking a literal response to posts like the ones above and performing a blanket cull of product expertise in your teams, let's look at the potential consequences. I think it's worth exploring some of the challenging situations that I've encountered when a clear product role is missing and prioritisation responsibility is left to the developers in the team.
Persisting siloed working
Not all teams operate as a cohesive unit. Some teams operate entirely as a set of distinct individuals who are all working in parallel on different things. Each person in the team can be picking up their own tickets with little consideration for what the others are working on. A product role done well will really bring a disparate team together by focusing development efforts around common themes and goals. Not only does this encourage collaboration but it also helps to other roles such as testers to focus their efforts.
Missing out on economies of focus
The product owner isn't just there to prioritise individual tickets, but also to synchronise related work. A huge amount of friction and expense comes from developers having to re-acquaint themselves with the code behind a feature when picking it up to work on. The process of consolidating related work into themes around product areas can result in dramatic savings in the overall time and effort of maintenance through minimising context switching. Collating and coordinating this work takes a considerable effort, but the absence of this effort results in more piecemeal and high friction work.
Not picking things up in priority order
Another behaviour I've seen emerge when prioritisation is left as a team responsibility is a tendency to skip down the priority list to avoid the tricky or lengthy tickets. Unless a team has really strong discipline then some members can fall into the habit of cherry picking from the backlog until they find something that appeals to them. In one extreme case I saw a team bypass clearly important negotiated customer work in the backlog to address other items that they preferred, leaving the company in a challenging position to explain why the paid work had been deprioritised.
Not considering the bigger picture
One of the responsibilities of the product owner is to ensure that they understand the business goals and align the work to maximise the chances of achieving them. In addition to meeting existing user needs this will also include considerations such as increasing revenue opportunities from existing customers, or supporting sales and marketing efforts. Without someone taking the responsibility to keep appraised of these needs, a prioritisation bias can emerge towards short term problem solving at the expense of strategic progress.
It needs a great team
Given the challenges I've presented here you may assume that I'm against team prioritisation, however this isn't the case. One of the best teams I ever worked on didn't have a specific product role and prioritised effectively based on a top level technical roadmap defined by the CTO. What allowed us to do that was a strong team built around multiple capable leaders with strong mutual respect. I've seen plenty of teams that don't have such a strong foundation for whom a product owner role was hugely beneficial.
I believe that it is important to consider the opinions of the whole team in prioritisation decisions, but that specific product expertise plays a critical part in informing those decisions. This doesn't necessarily need a devoted Product Owner in each team, but it does require someone with an understanding of the demands on that team and the implications of not doing things. What I'm aiming to highlight here is that if a team is not working well, a knee jerk response to a "Get rid of Product owners" message could well make things worse by leaving prioritisation decisions to the mercy of the most opinionated technical members.
Getting rid of thought leaders
Hopefully by this point the sarcasm in the title of this post is apparent. I don't think we should get rid of thought leaders, just as I don't believe we should 'get rid of' Product Owners or Testers. What I do believe is that all roles have to evolve - but successful evolution depends not on losing skills but on the people in those roles continously learning and advancing their craft.
- Testers needed to evolve away from after the fact script running and embrace shifting both left and right in providing more ongoing feedback right from problem definition through development and into production use.
- Product roles need to act less as remote indisputable decision makers and embrace gathering and supplying evidence to teams as influencers and information providers to help build consensus around how best to advance their products.
And maybe thought leaders need to appreciate that: what works in one context doesn't necessarily provide a blueprint for all others; a team evolving how they deploy and use specific expertise really doesn't justify announcing the death of that role for an entire industry; and ultimately that headline messaging should be respected as it propagates faster and further than the detail inevitably will.
Photo by Gary Chan on Unsplash
Post a Comment