Two weeks ago I attended the monthly meeting of the Austin Product Marketing and Management group. The session was titled Agile Software Development and its Impact on Product Management and was a panel discussion with three panelists and 30+ audience members. It was the second largest gathering I have seen in the year I’ve been attending Austin PMM meetings and it had a nice diversity of participants. Overall, I thought the session was a positive and informative experience, but my guess is that anyone who attended looking for clear-cut answers left disappointed. There were interesting explanations of Agile techniques and excellent anecdotes about their application at various companies, but I personally took away very little that I would consider definitively prescriptive in nature.

I am not typically a fan of panel discussions, but one of the things I really liked about this group was that they represented a nice cross-section of Product Management backgrounds. The panelists ran the gamut from a highly technical consultant with a background in software engineering and QA, to an extremely non-technical gentleman who made it absolutely clear that he was not an engineer in any way, shape, or form. Given the wide spectrum of backgrounds I see every day in people who work as Product Managers, I thought it was really effective to bring together participants with such varied experience for this session.

There were four key nuggets that I took away from the meeting and I will address each in turn. These weren’t necessarily lessons but rather pieces of the conversation that I thought were most interesting.

Communication is key. Of course, all good Product Managers know that communication is the sine qua non of their success so this is one tenet of Agile that I think anyone would be hard pressed to find fault with. The panelists each stressed that constant communication with the development team is a key component of their approach to the role. The conversation ultimately turned to communication with customers and the general sense was that Product Managers need to be adept at instantly switching context between external communication (customers) and internal communication (developers).

Keep your eyes on the road. The statement was made by one panelist that a key aspect of applying Agile methods to Product Management for him is that it has forced him to rethink the way he looks at software requirements. Rather than trying to keep an eye on the future and seeking to understand how features will need to evolve over time, he seeks to keep things as simple as possible by focusing on what needs to be built today. He went on to apply a car-driving analogy that I believe he adapted from Kent Beck. His point was that if you are too busy fixating on any point too far in the distance you will always be crashing into the obstacles that spring up right in front of you. From a Product Management perspective, this means you need to put down the long-term product roadmap and worry instead about what your customers need right now. I found both this analogy and its underlying premise to be somewhat faulty, but this criticism is actually an excellent segue into the next topic.

It’s all about balance. One of the aspects of the session that I found most interesting was the fact that it was rarely definitive. Multiple times there were emphatic statements made by the panelists that were later revisited and softened significantly after questioning by the audience. This is not a complaint, but rather is actually high praise for the panelists and their willingness to address the ambiguity of the real world and not dogmatically adhere to any sort of Agile party line. The roadmap example above is a good one since the panelist’s original statement was eventually revised to recognize that there is value in understanding how current requirements will fit into future needs – “you have to strike a balance.” That phrase, used repeatedly throughout the meeting, was probably the most valuable thing that anyone could take away from the session. Effective Product Management, regardless of development methodology employed, will always be about seeking the balance among a million different and often competing variables.

Agile is not for everyone. I know this final takeaway may likely be controversial, but it is one that was repeated in one form or another a few different times during the session.

• “Agile methodologies do not seem to work nearly as well for large project teams.”
• “They are less effective on projects with offshore resources.”
• “They don’t easily handle the huge, distributed efforts so common in many corporate IT organizations.”

I am very interested in seeing evidence that is contrary to the above statements, but hearing them made so clearly during this session was unfortunate since they played right into the thoughts I already had going into the meeting. I wholeheartedly agree that Agile methodologies have a ton of value and can really make a positive impact when they are applied appropriately, but they don’t change the fact that Product Management success will always be dependent on skilled practitioners who are able to strike the most appropriate balance for a given organization and its current situation.