How Agile Broke Product Management 02/26/2009
Posted by johndex in Product Management.Tags: Agile
trackback
I have a confession. I used to be an MRD machine. Early in my career I was part of a huge effort at MCI project managed by PRTM, one of the world leaders in process management. This discipline called for the writer of marketing requirements to systematically incorporate corporate strategies, competitive analysis, customer needs, and service interoperability in their result. I introduced these ideas to eBay and we used streamlined versions in our methodology there.
This is patently waterfall, and as proponents of Agile/SCRUM development will tell you, it is full of waste on the development cost side. I can’t argue with that assessment. In my experience converting a waterfall shop to Agile, it improves quality of code and improves time to market. But this doesn’t come for free. Adopting Agile has a huge resource-draining impact on your product management group.
Two things to understand and appreciate:
- The “product owner” role in Agile does not define the boundaries of product management
- Product owner duties adds operational overhead to product management
There is a tendency in Seattle to segregate product program management from planning, marketing, and business development aspects of the discipline. That works for Microsoft, who made this model popular, but in a smaller Agile shop, you run the risk of having a product owner/product program manager without covering the other bases. This leads to a predominantly tactical approach that can damage your long term success. Product management should be a coordinated strategic discipline.
Complicating this further is that the Agile product owner role actually takes more time than waterfall. Where you theoretically save cost on the dev side you should expect to increase cost elsewhere. Of course this makes sense as this is an iterative process by design. They don’t publicize this in their training, but when you ask, SolutionsIQ and NetObjectives will tell you that a typical result of the adoption of Agile is that the product management team gets overloaded. What gets shortchanged is anything that doesn’t feed the beast–leading to further imbalance in favor of tactical decision making.
John…great observation regarding the increased costs of agile and the necessity to focus on tactical decisions, often at the cost of strategic thinking. Successfully managing the tension between “feeding the beast” and making good strategic decisions is tough, particularly when each sprint is as short as 2 or 3 weeks.
great article, sure i’ll be back.
good day
It is indeed a problem when a product manager has to assume all of the responsibilities of a product owner. Many of a product owner’s responsibilities more appropriately should be assumed by an interaction designer or architect.
Not that it’s not really agile methods per se that “broke” product management. It’s the particular arrangement of equating the product manager and product owner that’s the problem.
Agile is not really about cost savings, it is more about adaptability. The real cost of the big MRD is that it prevents you from rapidly responding to changing markets. When you are locked into static requirements, someone will come along and eat your lunch.
I’ve often wondered whether we ask whether customers benefit from short cycles with the same energy that we ask whether products benefit from them. The answer is, of course, “it depends” – which is why I never generalize (whoops).
[...] one of her posts on agile. John Dex got a spike in traffic at his blog when he posted that “Agile broke product management“. Dean Leffingwell has a very good series on this topic alone. The product management [...]