The real target of product optimization
As a product team we should focus on maximizing the ratio of value the product delivers divided by the user’s effort to get the value. Or to put that mathematically, the objective function we want to optimize is:
(
Development activities that result in more value, while not increasing the user’s effort, are desirable, as are activities that reduce the user’s effort while not decreasing the value. Obviously, if you can do both you might have a winner.
But development teams naturally gravitate to another, pernicious type of optimization. Here’s an example that happened to me recently. As a side effect of improving a feature, an engineer modified a report, making it worse from the user’s perspective – harder to use and understand. The reason was “It was easier [for the developer] and eliminated a join.” The problem was that the engineer was optimizing the wrong thing – his time. Time is certainly a constraint on a product team, but it’s not what we want to optimize.
Product optimization, put another way
My new proposed objective function, 
- It has to improve something by an order of magnitude (this is
- It has to work (this means that the ratio is meaningful, and isn’t NaN, in mathematical parlance – and it’s one aspect of
)
- It has to connect to the other business processes around it (this is the other component of
The most important takeaway (I wrote about this a few months ago) is that you can’t get order of magnitude performance improvements by simply tweaking the existing code. Instead, to get improvements that are more than percentages, you need to change your algorithm. This applies to product value as well – you can’t get an order of magnitude more value by simply doing things the same old way but faster. You need to create something new – and that’s not easy. And optimizing the product team’s time usually works against that goal.
Optimization is an important goal for product teams, but we have to focus on optimizing the right thing.