The Product Manager in a Software Product Company


We once led a workshop for an online service provider confronting requirements challenges. When we got to the part of the tutorial emphasizing the notion of the product champion, the room got very quiet, and the mood changed noticeably. We asked the 25 people present, including developers and senior engineering and marketing managers, how these tough decisions were made in their environment. After a few tense moments, it became clear that no one made these decisions. After discussion among themselves , the best the group could describe was a " group grope," with input waxing and waning like the tides. No one had accountability for the tough decisions. No one decided when it was good enough.

Eventually, the team looked back at the senior marketing executive for answers, perhaps because that individual had the most input in the process. He looked around for a moment and then said: " You know what scares me the most about this team? I can ask for any new feature to be added at any time in the process, and no one ever says no. How can we ever expect to ship a product? "

It's probably clear from this vignette that this company had not been able to ship a product for some time. It's also true that history demonstrates that an extremely painful "nonability" affected the group. The company had evolved from a traditional IT background and had moved to providing online services over the years . The notion of an application as a software product was new. The team members had no precedents to guide them though the process. They ultimately failed in their quest.

Creating a whole product solution from a set of bits and bytes is not a trivial activity. It requires a reasonably in-depth knowledge of the technology (for example, "Can we really rely on vectoring to a hosted Web-based external Help system?") as well as market factors (for example, "This may not seem like an important feature to you, but our competitors have positioned it as necessary, and we will not be successful without it").

Who makes the tough decisions to help guide teams to commercial success? Who takes the time to understand what supporting services and other user conveniences might be necessary to assure customer success? In most commercial product companies, the product manager is empowered to make these decisions.

Stated more simply, the role of the product manager is

to help software teams build products that customers want to buy.

As Figure 17-1 shows, with two parts requirements management, one part development experience, one part commercial practices, and one part marketing, along with a big dose of common sense, the successful product manager crafts a whole product plan that addresses the real market needs. Although there is no one right way to organize and assign a product champion, perhaps we can look to our case study for a suggestion. After all, we did model it on a true-life and effective project team.

Figure 17-1. Product manager's recipe for success


In our HOLIS project, Alyssa takes on the role of product manager (Figure 17-2). Note that, in this case, the product manager reports through marketing rather than through the engineering organization. This is fairly typical for software product companies since, in theory at least, product managers need to be closest to the customer, who will ultimately determine the success or failure of the project.

Figure 17-2. Case study: software team organization


Perhaps more importantly, product managers often report to marketing because marketing management ultimately shares responsibility for "The Number," that is, the revenue associated with the product line. This is as it should be. Marketing is ultimately accountable for helping the sales team meet its goals and must be correspondingly empowered to make the hard decisions; otherwise , accountability will be lost. However, we have seen a variety of organizational models work, and you can usually recognize a champion or a potential product manager when you see one.


Managing Software Requirements[c] A Use Case Approach
Managing Software Requirements[c] A Use Case Approach
ISBN: 032112247X
Year: 2003
Pages: 257 © 2008-2017.
If you may any questions please contact us: