Dec 16, 2019 - Gabe Weaver    

Optimizing The Value Exchange: A Gentle(ish) Introduction

Part one of a pragmatic, business-driven guide to help teams transition from fixating on output to optimizing the value exchange with their customers.

This blog post is Unfiltered

Reading time: 8 minutes, 28 seconds

The problem

Building software products is really hard. Building an enduring company is even harder. We are constantly looking to hire solutions to help us do this quickly and with as little risk as possible. Companies hire Agile (R.I.P) because they believe it will help them be more adaptable, increase productivity, and accelerate software delivery. They hire DevOps as a natural companion to increase speed, reduce defects, safely deploy code, and improve the resilience of infrastructures.

While these solutions are directionally correct, we have a long way to go:

To get better, we need to fundamentally shift the way we approach building software products and companies. Through a fictitious story about a company called Acme Co., I'm going to provide a pragmatic, business-driven approach of how we can get there. The first step is to change how we define success. We need to move from output to outcomes.

The basics of the value exchange system

I've worked with a lot of companies over the years. Most of them measure the success of product teams by how much they ship. In Escaping The Build Trap, Melissa Perri correctly identifies the problem with this and the root cause – companies misunderstand value. As she succinctly describes in her book:

Instead of associating value with the outcomes they want to create for their businesses and customers, they measure value by the number of things they produce. Let’s go back to the basics to determine what true value is. Fundamentally, companies operate on a value exchange.

She uses a simple diagram to illustrate the value exchange system:


A Simplified Value Exchange System Diagram


Companies build products to serve as vehicles for value delivery. When the customer's problems, needs, and wants are fulfilled, they provide value back to the business. Business value is easy to define, as it typically maps to achieving traditional objectives that are universal to all companies:

  • Sustainable Value: Support the product's core value and create barriers to competition.
  • Growth: Grow market share, fulfill more demand, develop new markets, and improve recurring revenue.
  • Profit: Support higher prices, improve lifetime value, lower costs, and leverage existing assets.

While these are easily measurable, customer value is often more intangible; making it difficult to define and correlate to business objectives. This leads companies to create proxies to represent value that are more straightforward to comprehend and measure – such as things shipped.

As we discussed earlier, companies hire solutions like Agile (long live agility) and DevOps because they want to increase the speed and productivity of their value delivery system. The Value Exchange System is a reinforcing loop, so it naturally follows that if you increase the speed at which you deliver value, you will, therefore, increase the amount of value you capture from your customers. Companies are so fixated on optimizing for speed that a whole market of productivity analytics is emerging to track and report it. For example, the hook on the landing page of a prominent tool on the market promises to help you "measure your team's success" by surfacing velocity data to see how fast your team is going.

While speed and productivity are good things, optimizing for them in a silo will have a minimal overall impact on increasing the positive reinforcement to the system. This is because output does not necessarily result in outcomes. We need to optimize both how we deliver and capture value. To better understand why, let's jump into an all so common dilemma Acme is currently trying to overcome.

Let's Meet Acme Co.

“Bounded rationality means that people make quite reasonable decisions based on the information they have. But they don’t have perfect information, especially about more distant parts of the system.” – Thinking In Systems

Acme is a tech company that provides IoT devices and AI-driven insights to help logistics companies improve the efficiency of their operations. Acme has seen remarkable success over the last several years by leveraging a common growth strategy of steadily increasing investment in R&D, marketing, and selling to capture market share as quickly as possible. While not yet profitable, they believe there is an imminent inflection point where their investment in R&D will begin to pay off, resulting in revenue growth disproportionate to operating expenses. This has been playing out as expected, but the executive team is starting to get concerned given some financial trends over the last few quarters.

  Q1 Q2 Q3 Q4
Revenue 36.7 44.0 48.4 50.9
COGS 2.2 4.0 4.8 4.6
Net Sales 34.5 40.1 43.6 46.3
Margin 94% 91% 90% 91%
         
R&D 16.5 18.3 20.3 22.7
Marketing 4.1 5.2 6.6 7.4
Sales 15.0 17.8 19.9 21.2
G&A 1.6 2.1 2.3 2.9
Total OpEx 37.2 43.4 49.1 54.2
         
Net Profit -2.7 -3.3 -5.5 -7.9
Profit Margin -7% -8% -11% -16%

Acme's board set a -20% acceptable risk threshold for the net profit margin. It believes, that if necessary, it will be able to quickly reduce the deficit through strategic cost-cutting measures. It's clear from the financials that the company is on course to hit the threshold and the executives are scrambling to understand why. They have been easily converting customers from their competitors and are nowhere close to saturating their addressable market. They are investing heavily in delivering new product capabilities and scaling the sales organization to capture the value in return. The executive team decides to create a dedicated cross-functional working group to investigate and solve the problem.

Practicing kaizen with the improvement kata

The challenge before the working group is daunting. Acme is an incredibly complex system with hundreds of people and moving parts. They decide to adopt a management processes from the Toyota Product System developed by Taiichi Ohno. The group reviews what it means to practice continuous improvement - kaizen - by employing a technique called the Improvement Kata.

Diagram of the Improvement Kata

The first thing the group needs to decide is which direction to focus on first. If the challenge is to increase profits, that could be accomplished in a few different ways - increase the growth rate of revenue or decrease operating expenses. Looking at the financials, revenue growth has declined from an average of 20% per quarter to only 5% in the most recent. Given Acme has a sizeable market left to capture, and decreasing R&D spend at this point could hurt their long term growth targets, the group sets a target condition of getting revenue growth back to 10%. This feels like an obtainable goal within the quarter and will demonstrate forward progress to the executives.

With a target condition in hand, their next task is to identify the root cause of the decline in revenue growth and conduct experiments to reach their goal. They set out to connect with the sales team to begin their investigation.

Why is revenue growth declining?

As the working group sits down with the sales team to review numbers, they use the 5 why's to try to understand where things are going wrong:

  • Why is revenue growth declining? The sales team shares that conversion rates from new revenue are holding steady, but their conversion rates from up-sells have fallen dramatically.
  • Why are up-sells declining? According to the sales team, Acme is not delivering capabilities fast enough that it had promised during the sales cycle.
  • Why did the sales team set expectations for capabilities that weren't built yet? The sales team explained that enterprise customers have complex needs that aren't supported in Acme's core product capabilities yet. To keep up with sales quotas, they found that walking prospects through Acme's product roadmap usually gets the deal over the line. Based on the roadmap and the planned release dates, they had not seen this as a risk because things were expected to be delivered within the customer's acceptable time ranges.
  • Why weren't things delivered within the customer's acceptable time range? In further discussions, the sales team reveals that they feel R&D is delivering new features at an increasingly slower rate quarter over quarter.
  • Why is R&D slowing down on value delivery? At first glance, R&D's output metrics are consistent month-over-month relative to headcount. While the sales team helped the working group see that lost opportunities in up-sells were driving lower growth rates; it didn't make sense. The group decides to head over to R&D to better understand the value delivery system.

The importance of measuring the value delivery stream

To prepare for collaborating with the R&D team, the working group spends a few minutes reviewing the team's productivity metrics. To the surprise of the group, R&D only has one primary metric everyone on the team tracks consistently - the count of work items delivered. As the working group starts discussions with R&D, they explain that the executives set output objectives as a means of measuring the team's success. The rationale for this was due to the way the product is bundled and priced. The categories all roll up into one pricing model and it was difficult for the finance team to figure out a way to attribute revenue to the various categories. They had ultimately decided that measuring productivity was the next best thing.

So if work item output is the goal and R&D's output has been consistent quarter over quarter, why was the sales team convinced R&D was slowing down on value delivery? To understand this, the working group needed to better understand the flow of items through the value delivery process within the Value Exchange System. To do this, they generated a simplified value stream map to visualize the stages a work item goes through as it is converted from requirements to a production feature.


Acme's Value Stream Map

Acme's Value Stream Map. Cycle Time = Time in queue + active time + time waiting once started

The value stream map reveals that the total lead time for a work item is 2,132 hours (88 days). This is an astonishing revelation to the working group; especially since they didn't include the time a work item spends waiting between when a customer requests a feature and the team starts the planning process. Even though the R&D team delivered ~3,100 work items last month, it took well over three months to satisfy customer requests. The working group needs to collect more data, but they know they are on the right track. Before synthesizing a hypothesis, they finish collecting additional historical metrics to confirm their suspicions.

  Q1 Q2 Q3 Q4
Items Delivered 2,275 2,524 2,800 3,131
Lead Time 31 52 69 88
Cost Per Item Delivered 7,250 7,250 7,250 7,250

Based on the data, the working group notices the strong correlation between the increase in lead time and the decrease in up-sell revenue growth. Given their target condition for the upcoming quarter, they create the following hypothesis:

Decreasing the lead time by ~35% will enable customer requests to be completed 18 days earlier, resulting in a 5% increase in revenue growth

With a falsifiable hypothesis in hand, they shift their attention to figuring out the best approach for running an experiment.

Continue reading:

Giving credit where it is due: In Escaping The Build Trap, Melissa Perri discusses the Value Exchange System at length and provides unparalleled wisdom for modern-day product managers. The Improvement Kata, Kanban, and Toyota Production System would not exist today if it weren't for Taiichi Ohno. His work has been foundational to many other systems and processes that have evolved over the years.

Cover Photo by Cristina Gottardi on Unsplash

Try all GitLab features - free for 30 days

GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

Try GitLab for Free

Try GitLab risk-free for 30 days.

No credit card required. Have questions? Contact us.

Gitlab x icon svg