Using product metrics to build the right features in the right way

It’s well understood that product leaders should use metrics to guide their efforts, so why do so many teams struggle to do so effectively?

According to Hubert Palan, a common misunderstanding relates to what granularity of metrics to use. Following the rise in popularity of Dave McClure’s pirate metrics, many PMs focus on high-level business metrics like revenue, customer acquisition, referral rates, churn, and engagement. Each is a valid barometer of success. But as with all metrics, they’re just numbers — numbers that can be compared with historic/benchmark values to verify whether you’re on track ✅, or in need of corrective action ?.

In other words, all metrics share a fundamental shortcoming:

Metrics can tell you *what* is going on, but always fall short of telling you *why*.

Metrics perform the same job as a bot that can only tell you if you’re exceeding expectations, slightly off track, or very off track.

And this little guy seems awfully helpful until the day he says:

If this bot happens to be reporting on a high-level metric like churn, what do you do?

Well, it’s not so clear, because the churn could be due to any number of factors:

• The main need your product is solving isn’t important enough to users. ?
• The product addresses a significant need, but existing functionality is insufficient for addressing it. ?
• The product offers sufficient functionality to fully address the user’s need but is lacking in speed, reliability, UX, or security — leading to functional or emotional painpoints that drives users away. ?
• The product meets all functional and emotional needs but is not good enough to justify the expense over a competing/homegrown solution. ?
• The product is excellent on all counts, except users don’t know about all of the valuable features available, so perceive it as being insufficient for their needs.❓

If your churn rate grows, it’s clear something is wrong, but it could take weeks or months of investigation to learn why so you can do something about it.

“Focusing your team’s efforts around a high-level business metric like churn is a bit like a general who sends troops into battle after voicing the strategy: ‘Let’s win the war!’”

— Hubert Palan

Wouldn’t it be better if our bot could localize his alert to a specific product area? Even though he’d still only be able to tell you the basics ? ?, the scope is narrow enough to identify problems and develop solutions in the span of hours/days, not weeks/months.

What’s more, it’s up to you what areas of the product KPI bot reports on, because you get to decide which product metrics to track. For example, if you’re working on a task management solution, you might find that a number of tasks completed per user per week is an actionable indicator of whether people are getting value out of the tool. Some metrics may come and go as you start and complete various initiatives, but a metric that measures usage of your flagship feature is likely to be around for the long haul.

And those other product metrics? They may be brought into focus for a quarter or two at a time as you shift the team’s focus toward different strategic objectives, but then they may be replaced as new initiatives come to the fore. So for the team building a task management solution, one quarter’s initiative could involve differentiating the solution from other run-of-the-mill task lists with poor support for multimedia. If the team goes on to ship features that helps users add high resolution graphics, gifs, and videos right to their tasks, the key metric could be number of file uploads per user per week.

Another example is straight from our team at Productboard. This quarter, we’re working on an initiative to help our users (product managers) leverage user inputs to make more data-driven decisions around what to build next. We’ll know we’ve succeeded if the number of user insights linked to related feature ideas goes up. To be precise, our goal is to increase the average number of user insights per project per week by 20%.

Maybe this quarter your team’s focus is on solving some new user need, solving an existing need, or reducing users’ painpoints in today’s product. For each of these initiatives, which features will you be introducing or enhancing? Once your work is complete, what type of usage or measurable user behaviors would indicate success? Those are the metrics you should be tracking day-to-day and week-to-week. Doing so will guide your team’s efforts and boost your chances of shipping a truly excellent product.

Join the discussion!

I recently sat down with Productboard CEO Hubert Palan to get his take on what makes a good product metric. Check out his full response below. ? ?

We’d love to hear how you’re putting metrics to use with your team. Drop us a note in the comments! ?