I've been saying for a while now that product managers are a critical component of successful software development. I talked about it in Beyond Story Cards and more recently in my India presentation on distributed agile development (which will be up shortly).

To recap, the product manager is the person on the team who is responsible for maintaining the vision of the product the team is producing. He (or she) must have a strong sense of what value the product brings to the organization or its customers and he has to have the authority and political know-how to tie together many disparate interests and desires. This person also needs to be easily available to the team to make the tough calls about priorities, what goes in to the product, and what stays out. On an agile team, he should also participate in every planning meeting and review every demo.

The product manager isn't necessarily the same as XP's "on-site customer," although this is certainly ideal. I find that the product manager often leads a "customer team" that consists of domain experts and possibly interaction designers. The domain experts need to be on-site with the team in order to answer the nitpicky little questions that come up in a complex product. The product manager simply needs to be readily accessible.

Without the vision of a good product manager, the team is likely to flounder. It will spend time delivering functionality that isn't really important. It will develop low-value, high-cost functionality at the expense of high-value, low-cost functionality. It may spend time "thrashing"--switching back and forth between multiple features, never really completing any of them.

I find that many teams have trouble obtaining the services of a qualified product manager. My response to that remains the same:

Yes! Good product managers are expensive. But let's remember that their involvement is a key success factor. Developing software is even more expensive than a good product manager. If your product isn't worth the cost of a good product manager's time, maybe you should re-evaluate whether your software is valuable enough to be worth doing in the first place.

Beyond Story Cards: Agile Requirements Collaboration (James Shore)

With that in mind, I've been happy this week to find two experience reports that bolster my position:

Jürgen Ahting writes about Effective Project Sponsorship. Jürgen describes his experience as one of executive sponsorship, which it is, but it's also about product management. Jack, his executive sponsor, has a clear vision for the product and a strong sense for the value it provides. He steers the product to success:

Jack was the head of a division of a midrange sized company and member of the company board. His was a service division for the others. He wanted to make the complex planning, execution and accounting process in his division more effective and efficient to be able to act more like a business inside the company.

He had started by changing the organizational structure and processes and looked for an integrated information system eventually to be used by most of his employees. It became evident that no standard software was up to the task and so he opted for a custom build system. He argued for the company to spend millions on such a system (about 1% of yearly turnover at that time spread over 5 years) and he made the commitment that his division would save the company even more millions.

Effective Project Sponsorship: An Experience Report (Jürgen Ahting)

Dave Rooney writes about The Disengaged Customer. Dave talks about how well his team worked when his customer (who, like Jack, is acting as product manager) was engaged and how things went downhill once the customer disengaged:

Suddenly, the Customer wasn't available for meetings. Decisions that once took a couple of hours or a couple of days to be made were taking a couple of weeks. Where once the Customer attended our meetings, the Business Analyst on our team now had to go meet with the Customer when time permitted. All of these issues resulted in a critical loss of feedback.

[...]

We weren't sure what our priorities were. We weren't exactly sure what to work on next. We pulled stories from the overall list, but there was precious little from the Customer in terms of what we should be working on. This went on for a few months.

Then, we found out that the Gold Owner was pissed--really pissed. We hadn't been working on what this person thought we should.

The Disengaged Customer (Dave Rooney) (Part 1; Part 2; Part 3; Part 4.)

So... get a good product manager. If your company won't commit the resources for this critical member of the team, maybe your product isn't valuable enough to be developing in the first place.

(Updated 23 Jan 2008: Dave Rooney's URLs moved.)