The Value of Product Management
Posted by Program Manager on June 6, 2006
When I started out, I thought that it was critically important for each developer to know all the ins and outs of the end user. If you are writing a financial application, the developer should be able to pass for an entry level accountant. Well, then I got into healthcare, and I realized that it’s impossible for developers to know anything close to what an end user knows. This is when I saw the light on the value of product management.
A great product manager will perform three tasks:
- Drive a product’s strategic road map. This means that the product manager understands the end user’s needs and understands the competitive marketplace. Understands which features are competitive disadvantages, market differentiators, visionary features, and customer satisfaction issues. The road map will align these features by priority and usually group them into 3 releases. A near-term, tactical release, a longer term strategic release, and a long term visionary release. Dates on these releases are irrelevant, since the road map defines what needs to be done, and then the timeline can be wrapped around that.
- Cut features from a release scope. Inevitably, customers, marketing, and product management will want more features than the development team can support in a given time frame. It falls to the product manager to work with the program manager and reduce the scope list (The entire scope planning process is another topic for another day). The product manager must balance the needs of sales, marketing, existing customers, and new customers to prioritize the list and make some tough decisions. A good product manager understands and accepts this. A tell-tale sign of a poor or inexperienced product manager is one who will kick and scream to make it all fit into the scope, rather than accept the constraints of reality.
- Understand the customer’s business. This is the most critical skill above anything else. A great product manager truly understands their customer. Usually, this means that they came out of the field that your product is now servicing. Maybe they were an account if you are developing accounting software, or a nurse if you are developing hospital software. This allows the product manager to converse with the customer in their vernacular, build a repore, and gain insight to new developments in the industry. The other benefit is that they become a key resource for the development team. The development team will not understand all of the intricacies of a particular business function, but the product manager should. And if they don’t, they’ve built relationships with key customers that they can contact to get the exact answer. This allows your team to correct an issue in the design phase, rather than waiting until it is in the hands of customers, and is 10 times more costly to repair.
The key takeaway for anyone in development is that product managers are the ones responsible for the domain expertise, and the rest of the team should leverage and benefit from that.