Document Actions
Ask the Expert
How Do You Measure the Results of Product Management? By Jim Foxworthy
I am interviewing for a Product Management position, and the interviewer asked me how one can measure the results of product management to determine how well it is doing. Can you recommend any resources for me?
This is an excellent question, one I found myself considering from both the interviewer and interviewee point of view. But I will respond with the latter, since you are the one who asked!
The measurement of product management results can be seen in both “leading” and “lagging” indicators. Lagging indicators are the more classic business metrics, such as revenue growth, increased customer satisfaction, or even product level profitability. But those metrics involve many more people than the product manager, and take time before they are evident.
So as a VP, I prefer to look at leading indicators of product management success. Metrics such as number/frequency of face-to-face visits with the market, followed by the creation of Buyer and User Personas, drafts of Problem Statements, and eventually statistically valid market evidence that describes those Problem Statements by their pervasiveness and urgency. All that input (Personas with Problems that have Market Evidence) goes into the creation of artifacts. Business Cases, Positioning Documents, Requirements Documents —you get the idea.
So, how do I know when a product manager is doing well? First and foremost I can see that they are outside the building interacting with real members of the market. What they learn gets cranked into documents which in turn empower other groups within the company, like Development, Sales and Marketing Communications. And that is how we get to greater revenue, higher customer satisfaction and product level profit.
Best of luck in your job search.
Jim Foxworthy is an industry veteran with more than 30 years in the computer industry. Prior to joining Pragmatic Marketing, Jim was president of a consulting firm focused exclusively on implementations of the Pragmatic Marketing Framework. Contact Jim at jfoxworthy@pragmaticmarketing.com
Measuring Product Management
Thanks for your thoughtful response. I read your note more than once, because I was struck by how much we AGREE with one another. Then I read my original note some more, and realized that perhaps I had used too much Pragmatic Marketing jargon. Let's get some of that addressed first.
Market Visits. I stressed the importance of this activity, but didn't explain that these market visits are with customers and non-customers. In fact, in our seminars we talk about subdividing the market into three sub-categories, and encourage product management to actively and continuously visit all three. So I would say we are in agreement.
We also stress in our training that market visits and sales calls are not the same thing. So, again, we seem to be in agreement. A product management professional who follows our model will not become a sales engineer.
Last, you talk about having product management provide input to ensure good communications and to increase sales velocity. My mention of 'artifacts' produced by product management speaks to this class of 'input', although I didn't mention all the artifacts we teach. So, we agree!
Balance is the key to life in product management. Balance of activity, and a consistent effort to obtain data from the 'outside-in' and provide that to others so they are empowered.
Get out of the building
Leverage
Agreed. At Pragmatic Marketing we like to say that product management should always "look for ways to get strategic benefit from tactical activities". And the reverse is also true! In other words, leverage each and every trip for all the benefits of field work. Never get on an airplane for just one reason! Because ALL the activities on the Pragmatic Marketing Framework are necessary for the successful marketing of technology products. Not just the ones on the left, or just the ones on the right. We must ensure they are all completed.
But if we must choose (and sometimes we must), the correct priority is to focus first on the discovery of unsolved market problems.
Measuring PM - not just customer visits
However, Jim makes it sound like product management's main value is customer visits and writing trip reports.
While it's critical to get "outside the ivory tower" of the office and interact with customers, a PM who is measured largely on customer visits will quickly become a glorified system engineer, spending most of their time doing Sales Support. They won't have enough time in the office to use the gathered info to help deliver the right product, at the right time, to the right market.
There has to be a balance. Most PM's I know spend only about 20-25% traveling, and get much of their market input from other related sources, like sales reps, industry analysts/consultants, and other 3rd party inputs, not to mention many customer conference calls. That leaves them time in the office to analyze and use the info they've gathered.
A key engineering manager colleague once told me "I don't want a PM that's traveling all the time - I want them right here where they are available to help answer my questions and write requirements specs". So that's the opposite end of the spectrum.
Neither pole is best. There has to be a balance. Yes, PM's need to get out to customer sites to gather requirements. But yes, PM's also need to be sufficiently available to engineering and the rest of the cross functional team to transfer the knowledge they've acquired so the rest of the team can benefit from it and help with key team decisions. An experienced PM knows how to balance factors such as timeframe within the release cycle, product lifecycle maturity and company/team skill set, to determine how best to spend their time to provide the best value to the company.
An example of non-customer-visit value, was at a small company where I once worked. The most visible initial value of product management was the "normalization" of the release cycle, implementing a consistent product definition and release process to ensure that releases would occur regularly and as promised. In that case, there was no shortage of customer input, it was managing that input and being able to deliver solutions to address the needs on a timely basis.
So product management value can come both at the front end of the product release cycle in providing valuable input, but also throughout the rest of the cycle, ensuring product gets to market to address customer requirements and ensuring product communications are developed to best highlight the value that has been developed.