Recently, several of my favorite bloggers have debated the role of product management in agile product development:
If you're an executive interested in the debate, here's what you need to know.
First, read a blog entry I wrote in June 2005 entitled "Agile Product Management". In it, I lay out some of the basics of waterfall and agile methods.
Second, read a blog entry I wrote in September 2005 entitled "BUFR". In the entry, I contended that the two main causes of problems with waterfall methods are big up-front design (BUFD) and big up-front requirements (BUFR).
Third, note that the most important set of problems that agile methods overcome stem from BUFR, not just from BUFD. Arguably, this realization renders agile more directly important to product managers than to developers.
An agile product manager works in a fundamentally different way with both developers and customers. It's not just a matter of how and at what pace the requirements are delivered to developers. It's also how the requirements are elicited.
An agile product manager doesn't just interview and observe customers to understand their problems. She involves customers in an iterative feedback loop by "releasing" preliminary versions of the product to them. This feedback loop provides a way of eliciting requirements after implementation has begun but well before the product is officially released into production.
It's unfortunate that the term "agile" originally applied only to development. If you look at agile product management as merely something that a product manager does to co-exist with agile development, then it does seem silly to adopt (or co-opt) the buzzword.
But it turns out agile doesn't just enable developers to design and implement code more efficiently and reliably. It also enables product managers to understand their markets more efficiently and reliably.
So the popular notion that agile methods help developers, and that they therefore need product managers to cooperate, has it backwards. The opposite notion is equally, if not more, valid. Agile methods benefit product managers, and they need developers to fall in line to enable agile product management.
- Adam Bullied asked if the notion of an agile product manager is baloney.
- Enthiosys argued that agile does and should change how product managers do their jobs.
- Saeed argued that agile only need affect product management incidentally and at the margins.
If you're an executive interested in the debate, here's what you need to know.
First, read a blog entry I wrote in June 2005 entitled "Agile Product Management". In it, I lay out some of the basics of waterfall and agile methods.
Second, read a blog entry I wrote in September 2005 entitled "BUFR". In the entry, I contended that the two main causes of problems with waterfall methods are big up-front design (BUFD) and big up-front requirements (BUFR).
Third, note that the most important set of problems that agile methods overcome stem from BUFR, not just from BUFD. Arguably, this realization renders agile more directly important to product managers than to developers.
An agile product manager works in a fundamentally different way with both developers and customers. It's not just a matter of how and at what pace the requirements are delivered to developers. It's also how the requirements are elicited.
An agile product manager doesn't just interview and observe customers to understand their problems. She involves customers in an iterative feedback loop by "releasing" preliminary versions of the product to them. This feedback loop provides a way of eliciting requirements after implementation has begun but well before the product is officially released into production.
It's unfortunate that the term "agile" originally applied only to development. If you look at agile product management as merely something that a product manager does to co-exist with agile development, then it does seem silly to adopt (or co-opt) the buzzword.
But it turns out agile doesn't just enable developers to design and implement code more efficiently and reliably. It also enables product managers to understand their markets more efficiently and reliably.
So the popular notion that agile methods help developers, and that they therefore need product managers to cooperate, has it backwards. The opposite notion is equally, if not more, valid. Agile methods benefit product managers, and they need developers to fall in line to enable agile product management.
Comments
I am completely on-board with showing clients prelim version of a product (potentially even mock-ups to get a feel in some cases) in order to gather feedback early and often.
Most people in the old-guard don't subscribe to this for the simple reason that, "you don't show clients anything until it's done."
Or they are lying during the sales cycle and the client has signed-on under the allusion of vapor ware...
1. Survey Program - customer opts to receive and respond to questionnaires.
2. Interview Program - customer agrees to follow-up interviews.
3. Demo Program - customer agrees to regular or occasional demos.
4. Ethnography Program - customer agrees to be observed in her native environment.
For simplicity, sometimes I present all of these individual programs as part of a single customer advisory board program.
Now, the answer to your question: I draw upon the customers who have opted to participate in demos and provide feedback. The particular customers in any individual case depends on their persona.
Why do you ask?
I'll post a response soon, but just want to point out that I've actually argued on my blog that Product Management has always been "agile" and it's Engineering that is now catching up.
http://onproductmanagement.net/2008/10/30/agile-pm/
Saeed
First, take the typical 50 page requirements thrown over the wall to developers. To the extent that product managers resisted creating such documents, it wasn't because they were agile. It was because they were either lazy or didn't want to get into design details.
Second, I challenge you to find an example prior to the popularity of agile where the product manager pushed for frequent, regular iterations. If product managers were truly agile, you should be able to find numerous examples.
So perhaps those who argue it's only a development methodology are simply not putting interim builds in front of customers.
If you are developing a truly innovative product and carving out a whole new market (as they were), how else can you do it without getting it completely wrong?
I have frequently denied Agile PdM as an accommodation or adapttion to Agile development, and still believe PdM should not get ensnared with,or defined by, whatever is the development process. You put it very well as its own approach, that is complentary to Agile development and quite probably - or in best cases - is the horse rather than the cart.