Why we need to rethink product management in an Agile practice

Have you ever wondered why your Agile practice feels a bit uninspiring? Or why your engineers have become a bit jaded with all this Scrum stuff? Did you know that you might be the reason for this?

Something that both fascinates and frustrates me is how the discussions about Agile have flipped from being embraced in engineering and resisted in the C-suite. We now see blogs from the developer community about how Agile is evil/dead, while business leaders are writing about how keen they are to adopt Agile ways of working. Ironically, engineering teams are the very people for whom Agile was intended to be a breath of fresh air. In fact, Jeff Patton did a great talk at Mind the Product Engage Hamburg in 2018 where he said: “We got waterfall and we all complained about it and now we all complain about Agile. I’ve started to think the problem is us!”

Product management is a bit player

Most transformations/implementations of Agile focus on the behaviours of the delivery part of the organisation. Product management is a bit player – an afterthought when the organisation realises that, as part of implementing the Scrum framework they need these things called product owners. Agile implementations are generally focused on the introduction of the Scrum framework to move teams toward agility – paraphrasing the framework a bit, they work like this:

• Something something customer something something
• Product owner creates backlog from somewhere
• Grooming/planning etc etc meetings
• Build some stuff
• Demo it to some people
• Rinse/repeat

The focus is on how the engineering team works – this has value and is necessary in terms of shifting culture and ways of working. Having been part of several agile transformations I don’t underestimate the effort that needs to go into the culture change that grows great teams, but this focus fails to speak to what the team is working on – the product or products they are responsible for, and the customers that the products affect.

The most poorly defined, and yet critical, role in Scrum is that of the product owner (PO). The original intent of the PO role in Scrum was as an extension of the product manager role, however, Scrum literature focuses on the mechanical aspects of the role as they relate to delivery – like grooming a backlog with a team and participating in sprint reviews. As a result, the perception of the PO role has narrowed to the requirements of the Scrum framework, as that is where the focus of the implementation/transformation in the organisation. Scrum literature is also silent on where the backlog that the PO manages comes from – the backlog is simply assumed to exist.

Product owners become order takers

Thus a pattern has emerged where the PO becomes a backlog administrator or order taker – dutifully recording requests from all over the business in the backlog and then getting the engineering team to build them. They spend their days writing up detailed user stories and acceptance criteria, moving Post-Its across a visual board, and attending a never-ending stream of meetings where yet more requests are made for the team to build features. The requests are usually in the form of solutions – the PO receives something like “we need to build feature X for customer Y”. A feature gets shipped, and the team moves on to the next request.

Principle 5 of the Agile Manifesto states: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Most humans are motivated by the satisfaction of seeing their work make a real difference – the magical moment when a customer uses the product/feature for the first time and their eyes light up as their pain point is soothed by the new thing. However, if the team is building a feature that someone somewhere else in the business has decided is the “right thing to do” then the frequent result is that the feature is delivered and something doesn’t work – it doesn’t fit the customer expectation, doesn’t do what the customer expected it to, or it doesn’t work in their environment.

At this point, the team has moved on to the next item in the backlog, so when the customer feedback comes in that the last feature doesn’t work they feel under pressure. They are now being expected to fix the feature, while the business expects them to deliver the next one. Team delivery grinds to a halt while items further down the backlog get pushed further and further out. Battles break out over backlog sizing, as the reason that the last thing needs more work must be because “we underestimated the size”. Disillusionment sets in, and a thousand “Agile is dead/evil” posts get written…

Where did we go wrong?

Let’s look at the definition of “modern” product management:

The future state is where our customer has a problem, and the product we’re building or iterating solves this problem. The product manager’s role is to facilitate this process – encompassing not only the Scrum definition of the PO role within the engineering team (the ‘Do something’ stage), but also encompassing discovery, where possible solutions are assessed rather than being cast in stone and tossed into the backlog, and go-to-market aspects, where the customer outcome has to be measured and validated before we move on.

This cycle is not solely performed by the product manager however – the engineering team is also involved throughout this process. This widens the definition of the engineering effort to include discovery and post-delivery measurement and learning. The product manager has the toughest job here as they‘re also trying to ensure that the problem is not just specific to a single customer, and the solution(s) can be sold to multiple customers.

Now instead of the engineering team being handed a solution to build that may or may not solve the customer problem, and then dealing with the mess that results when it doesn’t, the team now has skin in the game throughout. Guided by the product manager they’ve understood the problem they are trying to solve, and assessed the fit of a solution – or multiple solutions – before the first line of code is written. They also do not start the next feature until the outcome of the last one has been validated, eliminating the instability of switching back and forth. The engineering team is now energised and engaged – they know the pain point they are trying to address and get to see (and measure) that magical moment when it gets solved.

This is hard – even basic delivery-focused Agile transformations/implementations require a tricky cultural change within the engineering team. Reaching the state described above challenges the way whole organisations operate – moving from a state of “engineers just build stuff” to “engineers solve problems (and not always just with code)”. It extends the definition of the engineering team to encompass everyone needed to go from a problem statement to a validated customer outcome – bringing in UX researchers, product marketers, account managers, and other roles in addition to engineers.

As a product person, why should you care about this? If the engineering team is not motivated and can’t reliably deliver outcomes that make a difference to the customer, then the product, and therefore the organisation isn’t going to be successful. Therefore the product management function needs to take on a leadership role in the way their organisation implements Agile – if the scope is only within delivery and the function just contributes as a product owner here and there then we’re going to be in for a bad experience.

This article is a summary of a talk that I gave at Agile Auckland in August 2018. A recording of the event can be viewed here:

Learn more from Anthony Marter

If you liked this post from Anthony, you might also enjoy some of his other posts. Explore Anthony’s articles.