Product Practice #299: Understanding Input and Output Metrics

Published:

Estimated Reading Time:  Minutes

Independent of the specific metric “framework” (think ​NSMs or OKRs​), companies need a clear understanding when asking teams to work on their Input or Output Metrics.

From my perspective, two approaches exist to develop shared language: The deterministic definition and the relative position of metrics.

Personally, I associate the deterministic definition with the work of ​Josh Seiden​ (and ​others​). Outputs are shipped features, produced artifacts, or completed activities to drive an Outcome. Inputs describe the allocated resources (people or time) to produce an Output. Let‘s use a made-up Miro example below.

Relative position considers a metric’s relationship to another. ​Brian Balfour, Shaun Clowes, and Casey Winters describe them like this:​ „Input metrics are leading indicators and output metrics are lagging indicators. By definition, it can take time for the output to reflect positive or negative changes in the inputs.“ 

But what is an Input or an Output is a question of perspective, as shown on the simplified KPI tree below. Make sure to consider that when choosing metrics.

No matter the approach, the ​leading and lagging nature​ of each metric determines how useful the metric is for the product team. Don‘t just paint by the numbers, but check the potential metrics against ​your criteria for usefulness and value​.

None of these approaches is „better“ or more correct than the other. What matters is that your company agrees on a set of terms and definitions for a shared understanding. This comparison might help with the confusion when some thought leaders say, “Outputs are bad.” Outputs are often ​helpful starting points​ for metrics discussions and can mean two different things.

HOW TO PUT THIS THEORY INTO PRACTICE

  • Establish a shared understanding within your company. Are „Output Metrics“ always the result of a driving action at any level or the description of delivered artifacts/activities?
  • Map out your „metrics landscape“ to understand the relationship between metrics and connect language to reality and your sphere of influence (more on that in two weeks).

That’s (almost) all, dear reader. If you enjoyed today’s issue, please share it on LinkedIn or Twitter to help more people discover it.

Thank you for Practicing Product,

Tim


Content I found Practical This Week

Outcomes as Leading & Lagging Indicators

When you’re trying to become more outcome focused, one of the big challenges is figuring out exactly which outcomes you should focus on. One technique is to find the leading indicators — things that customers and users do that predict a valuable result — the focus the work of your team on those leading indicators. For example: increased foot traffic to your retail store predicts an increase in sales. So how might you increase foot traffic?

Read it here

A Primer on Product Metrics

Not only do metrics help measure progress toward a goal, but they also help unite a team and empower members of that team to operate with increased autonomy. To achieve this, a metric needs to be understood by a large and diverse group of people. If they can’t, it isn’t a good metric. There are some exceptions for highly technical teams (e.g., search), but as a general rule, keep it simple — could you quickly explain a metric to your CEO?

Read it here

ICED Theory – Growing Infrequent Products

(In) Frequency refers to the gap between the transactions in a user’s lifetime. Increasing the frequency benefits the product with the increase in penetrability. For example, Glassdoor is well known for its company reviews. Users may visit Glassdoor during the job change, which will be, on average, let’s say, two to three years. Furthermore, not everyone in the market is looking for a job simultaneously (low penetrability). To reduce the hiatus between visits, Glassdoor has salary information prospected regularly (increase in frequency). Salary information appeals to anyone who is working, whether looking for a job or not (increased penetrability).

Read it here


{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
>