# What Should Product Teams Optimize?

## 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:

${V}/{E_ {u}}$

($V$ is value delivered and $E_{u}$ is user effort to get the value.)

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, ${V}/{E_ {u}}$, is another statement of my three rules of thumb for a successful product:

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.

nils