Product management, at its essence, deals with the economic problem of unlimited wants and scarce resources. You will never have enough time, money or people to do what everyone wants, so how do you prioritise that never-ending backlog? One approach that’s been gaining increasing traction has its origins in the work of Don Reinertsen, and in particular his fantastic book, The Principles of Product Development Flow.

To give you an idea of how important he thinks this concept is, he states that “If you only quantify one thing, quantify the Cost of Delay” (Reinertsen, 2009). In its simplest form, Cost of Delay (CoD) looks at a project, feature or initiative and asks how much money it would make the business over the life of the product, assuming that everything goes to plan. It then goes on to ask how much it would lose if it was delayed by a certain amount of time.

The difference between those two numbers is the Cost of Delay, and it’s usually expressed over time. For example, if you have a project that you think will generate £3m over it’s lifetime of 5 years, and you delay that project by a month, then it’s going to cost the business £3,000,000 / (5 * 12) = £50k per month. CoD aims to understand the economic impact of product delivery, and it does this by combining two important factors: value and urgency.

Weighted Shortest Job First (WSJF) or Cost of Delay Divided by Duration (CD3)

According to agile and Scrum principles, the main role of the Product Owner is to maximise value, that is, to produce the maximum benefit per unit cost consumed by the team. WSJF takes the CoD and divides it by the duration (CoD / Duration) to provide clarity on how we should sequence items that we want to deliver. When we talk about duration, we’re talking about the total elapsed time to get the item live. The higher the score, the higher the priority.

Calculating the cost in Cost of Delay

How do you calculate costs though? These costs can be tangible, such as lost revenue or increased expenses, but they can also be intangible, such as loss of customer goodwill or a damaged reputation. The CoD can be calculated using various methods, but one of the most common is based on the following four key factors:

1. User-Business value: This factor represents the value that a particular initiative or project provides to the end-user. It can be measured in various ways, such as revenue potential, customer satisfaction, or market share. The higher the user value, the higher the cost of delay.
2. Time criticality: This factor represents the degree of urgency associated with a particular initiative or project. It can be measured in terms of time to market or time sensitivity of the initiative or project. The higher the time criticality, the higher the cost of delay.
3. Risk reduction or opportunity enablement: This factor represents the impact that a particular initiative or project has on reducing risk or enabling new opportunities. It can be measured in terms of risk mitigation or market opportunity. The higher the risk reduction or opportunity enablement, the higher the cost of delay.
4. Job size: This factor represents the size or complexity of a particular initiative or project. It can be measured in terms of development effort, team size, or project duration. The larger the job size, the higher the CoD.

SAFe and Cost of Delay

The Scaled Agile Framework (SAFe) is used for implementing agile methodologies at scale in large organisations. It has also adopted the CoD framework, but abstracts the cost components from their absolute values using a modified Fibonacci scale to assign a numerical value to each of these factors.

The idea here is to make it easier for teams to come up with estimates for value, but I’m not sure that this is the right approach. Don Reinertsen’s aim with Cost of Delay was to get engineering teams talking the same language as business execs, and in my experience non engineers can end up rolling their eyes whenever you start talking about abstractions like story points. In the past I’ve used ranges for the financial cost for value, and sprints for duration.

The formula for calculating CoD in SAFe is as follows:

CoD = (Business-User Value + Time Criticality + Risk Reduction or Opportunity Enablement) / Job Size

Once the numerical values have been assigned to each of the four key factors, they are multiplied together to calculate the total cost of delay. The resulting number represents the potential economic impact of delaying the initiative or project. By understanding the CoD, businesses can prioritise work based on the value it provides and make informed decisions about which initiatives or projects to pursue.

The wider implications of using Cost of Delay

Using CoD to prioritise work based on the value that it generates while being explicit and transparent about the process is in itself a big step forward compared to more opaque approaches such as the MoSCoW method. However, there are a number of other benefits to CoD:

1. It improves decision-making: Using a transparent framework like CoD helps people to gain a better understanding of the trade-offs and options available.
2. It incentivises smaller batch sizes: Duration is the denominator in the calculation, so if you want to increase the score for a given piece of work then one of the best ways to do this is to reduce the batch size. There are many benefits to this.
3. It helps to limit work in progress: CoD’s focus is to get to market as quickly as possible by completing one task before moving on to the next, and to limit the number of items being worked on at the same time.
4. It helps to identify bottlenecks and dependencies: When elapsed time is such an important component in your prioritisation, it draws attention to areas where the elapsed time is long due to long lead times, queues and dependencies on other teams. There will be a tendency to address those issues that reduce speed.
5. It improves collaboration: Since CoD focuses on getting products to market quickly, cross-team and cross-functional collaboration is incentivised.

The cost of delay is an interesting concept that product managers and owners should be aware of, particularly in today’s fast-paced environments in which teams need to prioritise and re-prioritise their backlogs based on changing customer needs, market conditions and company goals. It enables teams to prioritise and sequence features or projects based on a transparent framework that emphasises the delivery of the most valuable and urgent items first.

How Peak Interval can help

At Peak Interval, we can help you unlock the full potential of your marketing and data technology stack. Whether you’re looking to integrate new tools, optimise your existing systems, or develop a tailored customer engagement strategy, our team of experts will guide you every step of the way.

From selecting the right platforms to ensuring seamless data integration and effective product development, we help you make the most of your technology investments. Get in touch today to explore how we can help you achieve your business objectives with a customised approach to your MarTech needs.