When you measure someone on something specific (unambiguous, easy to measure, atomic, etc), they become biased towards doing the thing that most effectively improves that metric.

When you focus on the metrics that really matter, not only is there too much (time) lag in the system before you get useful information back, but you can’t isolate the variables.

If someone is not spending enough time in the field (easy to measure) what it probably means is that they don’t have sufficient insight into the problems that are important to customers (easy to query, subjective to evaluate, impossible to quantify). I prefer to have that conversation as part of an ongoing dialog, not a performance review (or at least it is only a recap of past discussions during the review).

There really shouldn’t be any surprises during the annual-review meeting (except the $ amount of the raise/bonus).

The best way to manage product managers, imho, is the same as the best way to manage any knowledge worker – through ongoing dialog, coaching and mentoring – NOT to measure them with an assured-to-be-inaccurate ruler.

“In release X, we will address problem Y, and improve the (customer experience | value proposition) for Z”

They should not be “We will implement widget M” or even “feature N” or “capability O” (although you might need to talk about capabilities, from an outbound standpoint in a B2C situation – you can manage your sales force to handle this “contextual translation” in B2B or B2B2C scenarios).

Also – Rich, yet another great article!

@mathurabhay

What are your thoughts on how a VP Product position is different in a company where the CEO has a sales/marketing background versus a company where the CEO has an engineering/product background?

For instance, in speaking with a colleague recently, she pointed out that a CEO with a sales/marketing background is less likely to keep engineering and product under separate leadership, because he/she (the CEO) is unable to mediate effectively between them.

Thanks!
Dan

You are right that measuring individual performance for product managers is hard. You can make a legit argument that it takes up to 24 months to gauge if a new PM is good or not. When I hire a new PM, I might send them into the market to learn for 3 months, then they will spend 3 months writing some requirements, then engineering will build something for 6 months, then we have a 6 month sales cycle, then we have to spend time evaluating results. Hopefully we’d be more agile than that but it’s possible it would take this long. But as a manager of product management, you can’t wait 18-24 months to assess an individual’s performance – that’s horribly inefficient.

To make it worse, in my experience most companies judge their product managers individual metrics on what you describe as product metrics above: product revenue, margin, or customer sat. A product manager might have (indirect) control of these metrics, but there are a lot of factors that impact them way outside of the PM’s control. What if the PM is measured on revenue and halfway through the year the company makes an acquisition and redirects Sales resourcing? Huge impact to the PM’s metrics through no fault of the PM him/herself.

What I have settled on for measuring individual performance is to measure the activities required for a PM to be market-driven. Namely: 1) a quota for market visits (10/quarter is a good start IMO), 2) being able to defend an updated business plan in front of me and their peers every quarter, without using the phrases “I think,” or “In my opinion” (which requires higher order thought and research), and 3) keeping their finger on the pulse of the business by defining and measuring the right product level metrics and communicating them in the form of a dashboard report monthly. I like these metrics because they require a PM to get out from behind their desk and be outside-in focused, and the PM can control them, as opposed to revenue, margin or CSAT which the PM cannot control.

All things being equal, I’d prefer to measure outcomes as opposed to activities, but as you put it, it’s wicked hard to separate and quantify the inputs of a PM vis-a-vi all the other variables that go into making a product fly. So until we crack that code, I’ll use activities as a proxy.