There is a kind of engineering output that pretty directly links to profit, namely reducing the cost-per-use of the product. But somehow, I feel like the industry pays a lot less attention to that than to creating new features. I would guess it's because it feels less exciting.
Using an analytics stack such as Heap Analytics, it's possible to track feature use and understand their effect on profit. It's important, of course, to design and evolve the tracking framework as the product grows.
*More Features* does not always mean *More Profit*
When additional features make the system less reliable, or more difficult to use, then popularity, usage, value, and profit may decline.
There is a kind of engineering output that pretty directly links to profit, namely reducing the cost-per-use of the product. But somehow, I feel like the industry pays a lot less attention to that than to creating new features. I would guess it's because it feels less exciting.
I tried to capture that by talking about profit but you’re right that it needs to be there explicitly.
"Cost-per-use"—interesting distinction! Thank you Petter.
Using an analytics stack such as Heap Analytics, it's possible to track feature use and understand their effect on profit. It's important, of course, to design and evolve the tracking framework as the product grows.
And to be careful about the incentives you create. I published here about the Pie Problem. https://tidyfirst.substack.com/p/the-pie-problem
Just because something doesn’t appear in your model to affect profit does not mean it doesn’t affect profit. It’s just not part of your model.
To quote a question that James Coplien asks during his workshops: "What do you value?"
I like the notion of treating profit as a signal and not (just) a goal :)