I think the idea is that input is things that you absolutely, directly control, and output is more like "outcomes". You can control the price and certainly you can impact revenue by setting a price and, like, doing the whole rest of your job, but you still don't directly set the revenue.

My understanding of why they make this distinction is that if you focus on output metrics and you don't meet the target, you can be rationalize it as "well, we did a really good job but we failed to meet the goal because of circumstances beyond our control/market conditions/...", but if you focus on an input metric you're more directly accountable on whether you did what you said you'd do, and you come up with more actionable steps on how to fix it if not.

Output metrics are things you can't control. For revenue, you can't force people to by your products. Inputs metrics are the things you can control. You can (to a degree) control price and selection. And you've established via analysis that those inputs metrics are associated with the output metrics.

A key part I think people miss is to make _sure_ your input metrics and output metrics are correlated. You would intuitively think that, say, lowering outage minutes would be correlated with revenue. And as a result, you should invest engineering and other resources in reducing outage minutes. But maybe experimentally or via some other type of analysis it isn't. Maybe users will tolerate some amount of outage minutes without materially impacting revenue. You can then utilize that knowledge to prioritize. Rather than investing in resiliency to improve outage minutes, you invest in something else because that will have a bigger impact on revenue.

goals.

taking a different example, you might have a goal to lower outage minutes by 50%, so your output metric is “outage minutes”. in order to change the output, you need to identify what projects/mechanisms you can use to change the output. More often i’ve seen these be referred to as input goals (increase test coverage, adopt feature flagging, etc.) but you could always associate a metric to them.

Ok but "outage minutes" is itself an input to something else, like customer satisfaction or whatever. So that label isn't really clarifying anything.

What you're saying sounds the same as "The output of one service is the input to another, so the label isn't really clarifying anything".

There's plenty of value in breaking apart all of the interactions between various parts of the system and looking at their outputs and how they intend to change those outputs through which inputs.