I’ve been spending a lot of time over the last week wrestling with a whole load of semantic noise. When I set up my current team a couple of years back, one of the requirements from my leadership team was to try a new way of working, and most importantly ignore what we already had – don’t let the past unduly influence the future. Since there was no real view of a single way of working across the organisation, and the current processes we had were inefficient and tedious to say the least, this wasn’t a difficult challenge. What was a little more challenging was figuring out how to do work in a more impactful way, whilst creating a high performing team.
I had plenty of agile experience, mostly poor, but this at least helped me understand what didn’t work, so I wasn’t operating in the dark. I knew how I wanted the team to function, and had an idea of how this might be achieved. What I didn’t have was any organisation around me that worked in a similar way, we were on our own in a large enterprise that worked and thought differently.
Based on my previous experiences, I thought that having a good Product Owner was essential, a role that is generally seen as part of the Scrum method of agile. I also knew that this was a role I had seen being performed poorly more often than not. Product owners, in my experience, had often been placed in the team by leadership as an ‘eyes and ears’, and mouthpiece for those in charge of the programme of work, rather than the customers. One argument that we used to have was around the identity of the customer. The product owner would argue that it was those in charge of the budget – their money, their product. Others, including myself, argued that it was those that would actually use the product. The answer, as always, was more nuanced than that. The point, however, was that the PO only worked to the tune of the budget holders, and as a result the products were often way off target with the users.
The other area that I really struggled to understand and accept with product owners in previous teams was the lack of accountability and ownership. The PO would more often than not see themselves as messengers only, with no skin in the game. They would convey the requirements from leadership, and then pass responsibility onto the development team. This led to a lack of trust, and a breakdown in communication; disastrous for a Scrum team.
According to Jeff Sutherland’s The Art of Doing Twice the Work in Half the Time, the Product Owner “…is required to make prioritization decisions…consult with all stakeholders and team to make sure they are representing both what people want and what can be built”. Simple? Not in an enterprise designed around projects and budgets, and centralised decision making. I brought in a very good business analyst to help me understand what a Product Owner might look like. We wanted someone to have responsibility for a product, that would build good working relationships with the stakeholders, have a good grasp of the product and what was needed to deliver what people wanted, and made those priority calls. We agreed that the analyst would be a good Product Owner to start with, and that’s how we set the team up. We would have a Product Owner, that could understand and interpret the business problem, design a solution to that problem with the stakeholder and technical input from the team, and would then provide all the information for the team to build a working solution.
Two years on and this is still working. We’ve had good success in being able to deliver different products in parallel by organising our team and pipeline around the role of the Product Owner. What we’re now seeing is the enterprise around us start to adopt agile ways of working more widely. This is great, and I continue to provide as much support and encouragement as possible. What we’re also seeing is a challenge to the role of Product Owner. As a Scrum role the thinking was that all roles should be generic to agile, not to a specific approach. I agree. Rather than having Product Owners we were being asked to adopt the role of Product Manager, something I had always associated with a business role. I found a really good perspective on this by Melissa Perri, in which she comes at this from the opposite perspective. Melissa’s article makes it very clear that I still have (and always will) a lot to learn and understand. Melissa’s view was that the Product Manager is a job title, a set of skills. Product Owner is a role you play, possibly as a Product Manager, possibly not. I like this idea, and it has helped me frame the new way of working that is being implemented. What I see, however, is the amount of effort going into the semantic arguments around this. Again, Melissa points out that we should all be Product Managers, but what I’m seeing is that all we’re doing in our organisation is changing the name of the role, rather than fostering a new way of thinking around how the role can be performed effectively.