Measuring the Performance of a Product Development Team

Good product development teams rightly focus on outcomes (such as moving a key metric) and validated learning.

But if a team isn’t hitting goals or generating valuable learning, it can sometimes be difficult to know why. Is it because of something outside of the team’s influence? Is it because the team isn’t performing well enough? Or even if they are hitting goals, could they have hit them sooner, or exceeded them?

A Focus on Process

In sport, elite athletes and teams don’t solely aim for the result — they improve the things that will produce it. For example, the coach of a 200 meter runner doesn’t just say “run fast enough to get the gold medal”. They’ll get them to focus on the right technique for the start, for the bend, the home straight and dip on the line.

It’s for this reason you should measure the performance of product development teams in other ways too. Measure what leads to the outcomes, not just the outcomes themselves.

To do this I send regular ‘pulse’ surveys to the teams I work with, asking them to rate how well they’re performing against some of the key principles of good product development. Some examples include:

• Their understanding of the customer
• How their day-to-day work related to the current product strategy
• How good they are at defining and tracking success measures
• Whether they’re consistently delivering value to the customer

What’s Measured Improves

It’s important to stress that the purpose is not to compare performance across teams. Environmental factors (mood on the day, how well the company is doing) as well as things like the Dunning–Kruger effect — where inexperienced team members believe their performance is better than it actually is — will mean a team’s perceived performance typically differs from reality.

Perceived performance can also dip even when a team starts doing the right things. For example, in one recent survey I saw the team’s score for understanding of the customer actually drop after we did a huge amount of customer interviews for the first time in months. Why? Because the team realised they knew a lot less than they thought they did…!

That said, asking these questions provide a benchmark, and more importantly provides the team with stimulus to debate and improve their own process. Each time I implement this I see teams improve their process against at least one of the key principles of good product development.

As Peter Drucker said, “what’s measured improves”.