If you want to be a bad product manager, reject any notion of Agile product development. It’s probably just a ploy by bad engineering groups to take the blame off of them when they can’t finish everything you’ve requested. You’ve spent a lot of time perfecting your requirements documents and then handing them to development. The reason why things go wrong is because they can’t do their job, not because you can’t do yours.
If you want to be a good product manager, keep an open mind about Agile methods in product development. “Agile” is really an umbrella term for a variety of different methods of product development and project management. The Agile Manifesto describes what Agile proponents value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on
the right, we value the items on the left more.
Many companies are turning to Agile methods to help them be more responsive to changes in the market. It also can create better working relationships among all the team members, increase shared accountability, keep projects focused on customer and market needs, and potentially improve time to market.
Some product managers are afraid of doing Agile product management and development. The reasons are varied — it could be lack of knowledge about Agile, lack of interest in working closely with development, lack of ability to appropriately define “requirements,” or fear of what they believe Agile is because of misinformation about what Agile is.
Product managers need to educate themselves about Agile before making a judgment about its appropriateness. Agile processes work for some situations and not for others. The decision to adopt an Agile approach is not one that should be made by a product manager or engineering manager without input from others. Success with Agile is as much about how it is implemented as it is about Agile itself.
As a product manager, you should keep an open mind about Agile product management. Educate yourself. Read articles and books about Agile. Talk with others who have had success (and problems) with Agile. Try it out for yourself on a pilot project. If you decide that Agile is not right for you, fine, as long as you make sure that the decision is made based on practical reasons and not misinformation, misunderstanding, or fear.
Note: There are many resources on Agile product management; here are just a selected few. Please post any other recommended resources in the comments.
- Extreme Product Management: How to deliver products people want to buy in an agile development environment (PDF)
- Agile Methodologies: How Product Management’s role is shifting
- Growing Agile
- Tyner Blain: Various posts on Agile
- Ethniosys: Agile Product Management Coaching
Translations available:
Hi Jeff,
Good article – It seems that the role of the Product Manager is slowly changing as agile product development gains momentum. Firms also want to be more agile as they ever strife to bring competitive products & services to market – this is backed up by a recent survey carried out by McKinsey, who claim that 89% of organizations ranked agility as important to their companies success.
Read more on the topic at How Agile is Your Product Management Derek
I completely agree with this. I’m always surprised at how much resistance product management has to agile methods. There really does seem to be some sort of trust issue involved there.
I’ve spent time on both sides of the fence. Agile methods are challenging for product managers because it forces them to stay constantly involved in development. On the other hand, it keeps the product focused on the true product needs.
I’ve been writing about this subject on my blog as well (http://cmssphere.blogspot.com/2007/07/agile-why-it-scares-management-part-1.html).
tj
Interesting article. Not having worked in software for about 10 years, I was somewhat new to the agile paradigm, and to be honest reading the agile manifesto gave me just a bit of heart-burn. My thoughts are that agile should be about right-sizing the scope and life-cycle of your development, not valuing any one method above and beyond another.
While I have worked for oganizations that apply totalitarian style proccess control to everything, who beat to death innovation and the first signs of life. I have also worked with organizations that worshipped utter chaos (and eventually went out of business) all in the name of innovation.
A savy project manager is going to take the best agile has to offer (responsiveness, collaboration, customer interaction) and marry that to the best of traditional software development (thorough requirements geneartion, planning, process).
Agile is fundamentally changing how we think about ourselves as PMs. Its that important. The interactions, the method of management, and the acceptance of “change” as a necessary part of the overall process (i.e. you get applauded for a good reason for change, not shot at dawn!), are all prescribed as different by agile methods.
To consider that an entire profession might need to look at itself quite differently (even if it is by a few degrees and no more) means there will be those who are excited by the change (early adopters), but there are those who will also be extremely resistant and conservatively hold on to the basic definition of their current role.
That’s just human nature, and we refer to our customers doing it as the ‘adoption curve’.
We just need to accept that change happens and move with it based on the value of what the change will bring. If Agile is to be believed, it is going to cure a lot of ills with the traditional method of delivering IT… which let’s face it has a less than glowing history over the years.
Surely as a profession we have to look at this seriously?
Interestingly, Agile appears to acknowledge (in the guise of something called the “Product Owner”) that the PM function is critical to its success. This is a major change from traditional project-based methodologies where the PM role may or may not be explicitly identified (indeed, PM as a strategic role is only a relatively recent thing).