Some days it feels like Agile frameworks are dictating how product management is done. At a minimum, they seem to be dominating the product management narrative in the software industry. If that’s true, it’s not good for your products and it’s not good for your organization. On the other hand, when product management and Agile are 100% complementary, the end result is solutions that make customers better at whatever they do.
Let’s call a spade a spade – Agile is not a product management framework. Agile is a software development methodology. Period.
I’m one of the world’s biggest fans of Agile software development. I love the fact that teams are accountable for delivering measurable units of work at the end of every sprint. I love that code is written in spoon-size bites so if it doesn’t hit the mark, it’s no big deal to toss it and start over. And I love the fact that Agile teams are always developing functionality with a clear customer purpose.
If product management and Agile are going to be complementary, there are three core principles that both teams have to stick to.
Uncovering needs has absolutely nothing to do with how software is developed.
The most critical part of any product management discipline is understanding who your target customers are, what they’re trying to accomplish, and why those goals are important. There is absolutely no correlation – zero – between how market needs are uncovered and how software is developed. None!
The line between WHO, WHAT & WHY (product management) and HOW (development) is never gray.
Everyone stay in your lane! Product managers are guilty of telling developers how to build features, and developers are guilty of telling product managers that they know the customer better just so they can justify features they want to build. Both of you, knock it off!
Product owners are the only ones who get to dabble in both. They’re the surrogate users, and the product experts. They have to understand who the target users are, what those users are trying to accomplish with each job task, and why. Then…they have to work with product managers, designers and developers to implement the feature set that ultimately makes users better at their job.
Agile doesn’t need to be a product management framework.
Just like product management frameworks don’t need to be software development methodologies!
As a former product manager, I want to be fair. So let’s look at this from the developer’s perspective, because many product managers are quick to criticize Agile. And like most things, there are two sides to every story.
You’re familiar with the old saying, necessity is the mother of invention. Agile was born out of necessity for a host of reasons, one of which, in my opinion, stems from the fact that many software development teams weren’t getting what they needed from product management.
Just look at the content the Agile teams are demanding from product management – which they have every right to. It’s all about who, what and why, and they’ve drawn a very clear line in the sand: Don’t cross into the how. I couldn’t agree more. I think this is a by-product of having so many product managers with technical backgrounds.
When I was a product manager, I was guilty of trying to dictate “how” for the first few years. Then I figured out that the end result was better when I stuck to the who, what and why and let the developers take the first crack at the how. After some brainstorming by both parties, we always delivered a solution that was far better than either of our starting points.
At the end of the day, Agile doesn’t need to be a product management framework – just like product management frameworks don’t need to be development methodologies. Regardless of how software is developed, everyone benefits when product management sticks to the who, what and why and product development sticks to the how. That way both parties can work together more constructively to produce solutions that are far better than either party could have come up with on their own.