Throughput != $$$$

Deconstructing the economics of flow in software development

Flow metrics, as commonly used in software, originated from the applications of queuing theory and operations management in industrial production.

When adapting these ideas to software development, one of the critical pitfalls is simply emulating specific practices that arose in these industries when those theories were applied to improve the ways of working.

It’s always a better idea to apply the theories directly, considering the unique nature of software development.

One area where this matters is the economics of flow.

Economics of flow in industrial production

Flow metrics play a dual role in industrial production: as operational and economic efficiency indicators.

The things we produce in an industrial context have intrinsic economic value.

They can be sold for a price. And typically, you know this upfront.

This lets you reason about the unit economics of production reasonably robustly.

Provided sufficient demand for your product, throughput is a proxy for revenue.

Improving flow efficiency is a driver for reducing the cost of production and maximizing profits, etc.

So the things we measure with flow metrics, the volume of output we can produce, how long it takes us to produce the output, reducing the non-value added portions of the production process, etc., directly translate into economic value.

In this sense, flow metrics double as performance metrics.

Indeed, the whole field of throughput economics is predicated on this assumption.

In software development, I often see people measuring flow metrics and treating them as performance metrics without understanding that their primary purpose is as diagnostic tools to optimize operational processes across an entire system of software design, development, and delivery.

By analogy to industrial production, throughput is equated with “economic productivity” even when, in most cases, this relationship does not hold in software, and it has done lasting damage as a result.

Where does this work in software?

There are specific kinds of software development where throughput-centric thinking applies.

For example, if you work on fixed-bid, project-based, contract software development, build corporate websites, set up e-commerce or marketing portals for small businesses, etc., your economic model is well aligned with producing the greatest project throughput for the lowest capital investment and operational costs.

Traditional corporate IT project delivery, with predetermined funding based on business cases and fixed scope, is also a good fit for this throughput-centric thinking.

In these business models, flow metrics, as used in the industrial production contexts and the associated throughput economics, can be useful for you to analyze and improve service delivery and operational and economic efficiency.

It can help you understand what types of projects to take on, how much to charge or budget for them, and how to promise and deliver projects more reliably and profitably.

And these improvements can be directly tied back to the unit economics of the business.

Developing products is different.

In product development, we are typically building a long-lived tool or set of tools for a particular class of users to do one or more jobs better.

A better economic analogy for software products is commercial real estate (and I mean, in economic terms, not that building software is like construction).

We invest in a long-lived fixed asset (the codebase and the people who build and deliver products on the codebase) and collect rents (subscriptions, licenses, etc.) when people use the capabilities enabled by that asset (the product).

Whether or not your product is economically viable in the long term depends on the relationship between the cumulative capital investment over the product's lifetime and the revenues produced by that income stream.

Any incremental change or improvement you make to the product in the near term may not translate into a corresponding increase in the income stream.

But cumulatively, over the long term, your changes to the product should converge to sustainable growth in revenue and profit streams for your product to make it economically viable.

In general, the link between your flow metrics and your economic outcomes is indirect, tangential, and usually unclear when the measurements are made.

But does this mean that flow metrics are not helpful to measure here?

Absolutely not.

However, they are mainly useful as diagnostic tools that help you execute more effectively on achieving those economic outcomes.

And what you focus on depends on where you are in the product lifecycle.

In the early stages

In the early stages, we are developing features whose effectiveness or payoff are not known upfront until users provide the validation by adopting and buying the product.

Incremental outputs, at this point, often don’t connect to direct economic value in directly measurable or tangible ways, and certainly not in ways that can be reliably reasoned about a priori.

Throughput typically does not equate to revenue, especially not in the near term.

In the early stages of the software product development lifecycle, the key economic driver is flow time, the time it takes to deliver a product change to users.

This is directly linked to two critical economic metrics: feedback time and the cost of delay.

The feedback time measures the time it takes you to validate the efficacy of incremental changes to the product.

Unless you have brilliant and prescient product managers, the feedback time determines the cumulative capital investment you’ll have to make over the lifetime of the product development cycle before the income streams start to pay off on this cumulative investment.

The cost of delay measures the overall delay in converging to solutions that meaningfully differentiate you from your competition in the market.

It represents the opportunity costs of a product or capability being late to the market and losing potential market share.

Startups must constantly navigate this environment for simple survival, and their “systems” are typically small.

They are constantly optimizing processes to do this whether or not they use flow metrics formally.

But if you are a mature company that is trying to introduce a new product in an environment where your processes are optimized for late-stage products, or if you are a corporate IT shop transitioning from a project funding model to a product model, then you have to learn new muscle movements to shift the focus on reducing feedback time.

At this point, you need to understand how to use flow metrics to do this.

There is no avoiding this because the relationship between throughput, flow time, etc, are inexorably linked via the laws of flow.

You cant improve any one of them without understanding how these relationships work in the context of your system.

In particular, you cannot reduce flow time through a system without understanding where the throughput constraint(s) in the system lives, so you’ll end up measuring throughput all over your system anyway, even if none of it translates directly into $$ or even tangible outputs that users can see.

In the growth stages

Throughput becomes as essential as flow time in the growth stages of a company when typically hiring picks up, and a key question is whether or not the capital investments in more people and equipment translate to growth.

Typically, throughput at this stage translates to the ability of the organization to pursue more goals in parallel while staying responsive to the market.

A vital characteristic of this stage is that flow in your systems becomes highly unstable as the organizational silos form to accommodate growth on multiple fronts.

Rising instability leads to higher flow times, and getting feedback on anything delivered takes longer.

For companies transitioning from the startup stage to the growth stage after achieving product market fit, this is the point at which feature factories first appear.

So reducing instability in your process will make it much easier to create roadmaps that will let you continue to iterate with tight feedback even as you pursue growth on multiple fronts.

Measuring and understanding the impediments to maintaining stable flow through your development process is crucial to balancing fast feedback and high throughput goals.

Still, it will involve a much more context-sensitive analysis of impediments to increasing throughput and reducing or maintaining low flow times through the system.

Optimizing product development flow at all granularities of work in your pipeline (portfolio, features, releases, etc..) and across many product lines or value streams is going to be a critical capability at this stage.

At the other end of the spectrum, for some companies where these feature factories have already metastasized, the task is to understand how to break down these functional silos and get products to market faster with lower feedback times.

Flow metrics are still the best analytic tool to achieve this.

In the late stages

Once you have a stable, mature product, you probably can and should optimize for throughput, carefully focusing on why you need to produce anything.

After all, your software is already in the hands of users and creating and growing revenue, so presumably, your problem is not either throughput or flow time per. sSe, but how to continue sustainably growing business with targeted improvements and an eye on long-term economic value.

Bottom Line

If you are shipping a great product, growing profits, and seeing traction in the market, you don’t need to worry about flow metrics.

Until you do.

Then a deep understanding of product development flow in your organization should be part of your toolkit to figure out why you are not.

When it comes to using “flow metrics” in software development, you are always better off focusing on the “flow” part rather than the “metrics” part.

Use them to understand how you can improve flow after understanding your goals for improving flow, rather than thinking of them primarily as “metrics” of any sort.

Unless you prefer flying blind and figuring out that you are in trouble only when the funding runs out, and your company is on the brink of extinction.