Thoughts on Product Management

A lot has been written about the constantly evolving disciplines of development, test and project management. As software engineering matures and moves towards more agile approaches, many people have shared their thinking and experiences on how to do their jobs better. It occurred to me that I've seen practically nothing on the web or in books that describes the job that I do, which we call Product Management. I can think of a few reasons for this - many teams don't have anyone doing this job at all, some teams use the same title for something quite different, and since the patterns & practices is not a typical team, the requirements and approaches we follow are not always relevant to other teams. But that said, I think our team has enough in common with other development teams that it is worthwhile sharing a few things I've learned after doing this job for the last 3 years or so. I'm not claiming that this is the right or the only way of doing things - in fact it would be great to hear from other people who perform similar roles to find out what they do differently.

What is Product Management?

As I mentioned before, the term "Product Management" tends to mean different things to different teams, even in Microsoft. In many teams, the Product Manager is essentially the marketing person for a particular deliverable. I've got nothing against marketing people - it's an important and difficult job - but it's not the primary responsibility for Product Managers on our team. Our definition of Product Management is based heavily on the Microsoft Solutions Framework Team Model, which was defined a number of years ago in the days before MSF was so closely tied to VSTS. A paper on the MSF Team Model from 2002 nicely describes the role as follows:

I like to describe the role as being the primary interface between the engineering team and the customer. This means acting as an advocate or proxy for the customer for all important team decisions. It also involves acting as an a proxy or advocate for the team when dealing with customers. In our group we believe it's critical for everyone in the team to deal with customers, and the Product Manager should not be the only interface between the team and the customers - however for the Product Manager it is the primary responsibility.

How does this relate to other team roles?

One of the key properties of this team model is that there is no one "project lead". Instead, there are a number of key roles that are equally important, each addressing different aspects of the project. The MSF Team Model describes the roles as Product Management, Program Management, Development, Test, User Experience and Release Management. In the p&p team, we also have a dedicated Architect role.

Most of these roles should be pretty self explanatory, but many people are often confused about the differences between a Product Manager (PdM) and Program Manager (PM). In fact in many teams, both roles are played by the same person. The MSF guidance explicitly advises against this, and I strongly agree with this advice. To understand why, I'll give the MSF definition of the Program Manager's responsibilities (I greyed out the points that are covered primarily by the Architect in our teams).

As you can see, the PdM's primary responsibility is to deliver the right product. The PM's primary responsibility is to deliver the product right. On a good day, these goals are completely compatible. However in all projects there are times when very difficult trade-off decisions need to be made, such as deciding whether to implement an important feature that may result in the project missing its deadlines. Having one person drive that decision results in an inherent conflict of interest. The PM/PdM division means that different people will be fighting for different things - the PM will fight for meeting the agreed plan, and the PdM for delivering necessary customer value. Even if a compromise is not possible, the role division results in increased transparency which normally results in a better decision.

Staying connected to customers

The most critical part of Product Management is figuring out who your customers are, and staying connected to them. I came from a consulting background, in which case it was usually obvious who your direct customer was, since they were the one that signed your timesheet. In a situation where your team is producing software for the masses (which is the case for p&p, and is also true for ISVs and even some framework or infrastructure teams inside enterprises or system integrators), things get much trickier. Even in a consulting situation, you probably have many indirect customers who are harder to identify and build relationships with.

As a new Product Manager in p&p, the hardest part for me was bootstrapping the entire process - even though we had a large installed base of people using the pre-Enterprise Library blocks, I had no systematic way of finding them. I literally started with people I knew, and gradually expanded my contacts with the people they knew, and so on. But the thing that really allowed us to find and communicate with customers were blogs and community sites (first GotDotNet, now CodePlex). To me, it's not only very cool, but critical to our group's success that we can have a many-to-many, many-to-one or one-to-one conversation with anyone in the world who uses our stuff. Now I know that our team is in a unique position, and it isn't realistic to expect communities of thousands of people around the types of projects you may work on. But the one thing I think you can take away is that, with few exceptions, being as transparent and open as possible with as many of your customers as possible will help you get a much better result.

While our broad community activities are the most visible, it certainly isn't the only way we work with customers. Data from a large community is extremely valuable in showing trends and getting answers to focused questions, but it's very difficult to get a detailed understanding of what any given person is trying to achieve or why they made a certain decision. To get this kind of data, it's necessary to form deeper, personal relationships with certain customers so you can really understand what makes them tick. But you can't be overly dependent on this kind of data either, as you can only have so many relationships at the level and it can't be taken for granted that these customers are representative of the broader customer base. As such, I've found that best way of understanding what customers need is to use a spectrum of "depth" to "breadth" techniques. In our team, this includes the following, ranked roughly from depth to breadth. Different kinds of teams will almost certainly warrant different approaches, but I'd say the breadth/depth concept should still apply.

• Personal experiences
• On-site visits to customers
• Conference calls with "expert advisor" customers
• Workshops
• Meetings and conference calls with individual customers
• Events and Webcasts
• Discussions on community forums
• Blog posts and comments
• Online surveys

How does Product Management fit into an Agile team?

As you may know, the patterns & practices team takes a lot of pride in our success in implementing agile development processes. However there wasn't any one day when a decision was made to "go agile" - it kind of crept in over the last 3 years. I had no previous experience working in agile teams, so the whole process was extremely interesting but also quite difficult since I didn't really know what was going on or how I was meant to fit into this new process. I still don't know the official answer (if there even is one), but I can tell you want I've found.

There are many aspects to p&p's interpretation of Agile that make the Product Management discipline even more important than it would be in teams following different processes. Most importantly, there is a need to set the scope priorities up-front, and continually refine them throughout the project. The priorities need to be refined to keep them in sync with our changing view of reality as the project progresses, such as technical dependencies and complexity, and our ability to execute. An agile project treats dates and budgets as fixed (unless the person paying the bills decides they want to change them), so scope is the major variability point. Determining which features are in and out, and how deep to go into each feature, can only be done with extensive customer input throughout the project, so it's a core responsibility of the Product Manager.

Another key aspect of agile projects is that you don't pretend to know all of the answers up-front. You certainly need to have an idea on what you want to achieve, but detailed requirements and design questions can only be adequately answered once a lot of other pieces have fallen into place. From the Product Management perspective, this means you don't finish gathering requirements until the day you ship (and then you start gathering requirements for vNext :-). For example, in Enterprise Library 3.0 we decided very early on that a Validation Application Block was a top priority, and that it needed to provide a technology-independent way of specifying validation rules and validating data. We did not know which exact validator implementations we would provide, or which technologies we would build integration adapters for - these decisions were made only after we already had the core validation engine in place. In order to deal with these questions "just in time", the Product Manager needs to be deeply engaged with both the engineering team and customers throughout the project (which, in my view, is far more interesting than delivering a requirements specification paper upfront and leaving the team to figure out what it means and how to resolve inconsistencies).

Breaking the rules

One more important thing I've learned is that, while it's good to understand the formal division of responsibilities across different roles in a team, the best results can come when the boundaries are blurred. The "products" that our teams build consist of source code given to other development teams, rather than finished applications that address real business requirements, and practically everyone in p&p comes from an architecture/development background. We also have a culture that puts a lot of value in customer connection from everyone in the team. All of this means that many day-to-day tasks can be handled by many different individuals with different job titles. Oftentimes this means that key decisions, whether on scope prioritization, architecture or development are made jointly by different people in different roles. And sometimes certain tasks are done entirely by someone in the "wrong" role. I've personally completed many tasks that technically are owned by Architecture, Program Management, Development, Testing, User Experience and Release Management (yes, that's every role we have!). Many key Product Management tasks in our projects have been done with great success by people who aren't Product Managers. This flexibility is not just acceptable, it's often necessary as teams have differing workloads and individuals have their own strengths and weaknesses. All in all, the role responsibilities are better seen as a model for ownership, rather than a rigid rule on who does what. For example, if there is a need for a QuickStart sample to be developed and I'm willing and able to do it, then I should go ahead - but if the development lead isn't happy with my work then they get the final say on whether it's checked in.

I hope you found this valuable - I'd love to hear your feedback on which aspects of this are and aren't relevant to your teams, whether or not you are a Product Manager in name or responsibility.