A quick reminder about Productivity

A quick reminder is in order here, because “productivity” is also a word that we often use without thinking about what it actually means:

Productivity is the ratio between units of output per unit of input.

What does that mean in the context of an application development effort?

Let’s agree that the input in any intellectual activity is the number of hours worked (paid, actually, but who’s counting?). Sure there are other inputs, but they are marginal to our argument (electricity, software licenses, cloud spend, computer hardware, etc.)

But what is the output? Here are some options, which one do you think makes more sense?

The number of lines of code
The number of story points
The number of product features (subsidiary question: what’s a feature?)
The usage of the features (number of clicks on it? Number of completed journeys? Number of units output by the feature?...)
The number of product user hours spent in the product
The number of product user hours NOT spent in the product
The amount of time/cost saved by the user/purchaser of the product
Number of new customers of the product
Revenue generated by the product

I could go on. Interestingly, some of these measures seem to make sense on the surface, but when you think about it, it’s hard to figure out whether more or less of each produce more value.

So, unless you are developing software whose job is specifically to influence a number on defined things (e.g. reducing units of input per unit of output in a factory), the simplest proxy for valuable units of output is really the revenue generated by the product that the teams are building. You can assume that increased value (i.e. output) generated by your software is imperfectly but sufficiently reflected by its revenue. Measuring value is really more complicated, but let’s pretend.

OK, so application development productivity will be measured by revenue (R) generated per unit of time (T) spent developing.

Productivity = R/T

Increasing productivity therefore means minimizing T and maximizing R.

Maximizing Revenue

What does it take to maximize R, as a product development team? There are two components to R maximization:

- Demand: R increases with the extent to which the software actually, concretely solves business problems for its buyers and users.

- Supply: assuming a given existing demand for a solution to a list of business problems, R is inversely related to the time elapsed between the identification of the demand and the availability of the solution for sale. In other words, the later the solution is available, the less cumulative revenue will be made over the life of the solution.

OK, so that means that an approach that gives you more opportunities to release marketable value earlier will ultimately make you more revenue. Good.

Minimizing Time

How can a team of experts minimize T? There are three components to T minimization:

- Scope: For any specific business problem to solve, understand the problem well enough to develop only the behaviors that create the expected business value.

- Efficiency: For any given set of lines of code or specific behaviors that the software needs to have, find ways to write the final version of the code faster.

- Design: For any set of behaviors that need to be developed, write the code in such a way that you are not creating useless barriers and unreasonably increasing the time needed later to develop additional behaviors that are on the roadmap.

What does that mean in a nutshell?

Software development teams should adopt a way of working where the experts need to understand the business problem that needs to be solved and organize themselves between experts to minimize the amount of work that they have to do to solve it. In order to do that most effectively, they need to talk among experts, including business experts, without impediments.

That’s what being productive means.