Extreme Product Management
Dave’s one of the guys on my team. He’s the Tagspace guy – among other things. A recent post of his fairly expresses some of what we’re experiencing as we define our “product manager” jobs in the context of a team pursuing an Agile development methodology. Do check out his post. In it, he points to Scott Bellware and his views regarding the value of product managers. Dave focuses his comments on the “voice of the customer.” My two cents follow:
It pains me to say that I agree with Scott on many levels, but must disagree with his conclusion. At the same time, I think you (Dave) understate your role vis-à-vis the "customer" and the development of software.
The means of software development, in fact, the means of accomplishing any series of related tasks is eventually expressed in a more or less fixed process – at least traditionally. Two problems emerge. The first is the misapplication of the process. In other words its application to problems that are not sufficiently similar to those that gave rise to the process/methodology in the first place. And the second is the fact that all processes, or paradigms, have a lifespan. The first and second are often related in that misapplication tends to happen with greater frequency toward the end of the life of a particular paradigm. This occurs because of the very real fact that there are fewer problems to which it applies, and perhaps worse, lives (or at least careers) have been built around successful corporate contribution within the context of a now failing paradigm. Exhausted processes are applied by people that only know how to work one way. Many of them are product managers. However, just as many are software developers, and program managers, and public relations specialists, and general managers, and VPs, and whatever.
In any case, some things will remain true: what needs built will have to be determined, and then it will have to be developed. When it comes to things that are broken and need fixing, we need the voice of the customer. When it comes to innovation, we need more than the voice of the customer -- we need his imagination, his deep understanding of the situation well beyond appearances, his knowledge of relevant trends, his understanding of historical precedent, his appreciation of business relevance, his willingness to consider alternatives, and his willingness to experiment, to risk, to ask the wild and shocking questions, and to keep pushing forward in the face of old paradigm complaints and threats. And then the distillation of all that must be expressed in code.
Should developers do all of that? Hmm, perhaps today and perhaps to some, the answer to that is yes. But as a person that has focused his career on enabling, refining, extending, and enhancing the ways and means by which people discover one another, form community, and solve knowledge problems through association, I think that is a rather narrow view and one that is largely without merit. (Yes, I'm aware of the Google model -- or at least the mythology that surrounds it -- and I stand by my view that "developer only development" is largely without merit. Lots of things are shiny when you first bring them home. Maintaining the luster is another matter altogether.)
You, Dave, are a product manager in title, but you are also researcher, planner, and business development manager -- oh yes, and designer, and project manager, and agile business owner, and whatever other hat needs wearing. You're a recently evolved breed of product manager at Microsoft. Perhaps we should call you an Extreme Product Manager.
