Patterns and Predictability

Thoughts on how to improve the expression of value delivery in Tech

Predictability. We obsess over it in Tech. Especially in B2B SaaS. And especially in Sales. There’s a reason that Sales Velocity is not just a conceptual equation but often a way of life. Doing whatever it takes to improve sales efficiency and eke out gain across each component variable.

\( \text{Sales Velocity} = \frac{\text{Number of Opportunities} \times \text{Average Deal Value} \times \text{Win Rate}}{\text{Sales Cycle Length}}\)

High sales velocity signals robust demand, enables you to lock in customer contracts before the competition, speeds up revenue generation and greatly improves forecasting.

Frederick Kerrest puts it¹ elegantly: “Nothing happens until someone sells something”. He’s right: unless there is a buyer for your product, there is no business. You don’t get to continue to work on your idea and you certainly aren’t going to grow.

Given the emphasis sales velocity garners you might expect proportionate focus on product development (and by extension a similar equation). But you’d be wrong. Industry wide it’s still largely a black box, people think in projects and company boards — concerned largely with hard finances — are largely left out of the loop.

My hard won belief is that today’s Tech organizations — especially product and technology teams within — lack a commonly accepted vernacular to describe what I like to call Product Velocity in a similar sense. Even with the tools and prior art readily available.

A quick diversion

You’re at a Casino in Las Vegas. You sit down to play roulette and plan on playing for while — it was smart to bring that hefty bankroll. When you sit down, the pit boss overseeing the table games makes note of your average bet size. It turns out you have an affinity for betting on red — no single, double or triple number bets for you — and like to spend about $50 a spin.

How much, theoretically, will the Casino win from you? Turns out there is a formula for it² — it governs how much they’re willing to comp you to get you to keep playing.

\( \text{Theo} = \text{Bet Size} \times \text{Game Edge} \times \text{Hours} \times \text{Games per Hour}\)

The formula is comprised of four parts that are multiplied together:

• Your average bet size: $50 (which was sampled over time and input into their patron management system)

• The house edge of the game: 5.26% for Roulette

• The number of hours you sit there: 5 in this case

• The number of games played per hour: 30 in this example

No matter how variance plays out and what you actually win, the Casino should theoretically make:

• Theo: $50 x 5.26% x 5 x 30 = $394.5

In this case, the Casino, knowing that the expected value from you, the patron, is just about $400 is willing to comp you up to 30% (~$120) in the form of free drinks, a meal at one of their restaurants, etc. Even with this contra revenue they’ll still be in the black and you in the red given a long enough stay. This formula predictably governs their action and ultimately yours. And over the long run — edge inherent — the Casino always wins.

Back to Reality

What is this, fundamentally? What is its nature and substance, its reason for being? What is it doing in the world? How long is it here for? — VIII. 11

What does theo have to do with Product Velocity (“PV”)? Quite a lot. First, it can be used to govern action and increase alignment³. Second, it has similar variables. Like both Sales Velocity and theo, I define PV as being comprised of four parts:

• Number of qualified product opportunities — Like Sales, your backlog always contains a certain number of opportunities. These can be feature enhancements, bugs, customer requests, non-discretionary tech debt, etc. They should be qualified in terms of priority using a framework like ICE.

• Average product opportunity a priori value — Different than Deal Value in Sales Velocity, it’s impossible to precisely know the impact on the key metric you’re trying to move prior to building and testing the thing. But you can estimate it. Like a good bayesian, these impact values can be updated over time, which is especially relevant as you improve and refine existing product surface area.

• Delivery Rate — Also known as the “say/do ratio”, this is the ratio of how many product opportunities are delivered to customers (internal or external) in a period. Given all organizations differ in how they think about release management and what it means to deliver to a customer, it’s most important to align on a definition and stick to it.

• Quality development throughput cycle time — This part of the equation is quite frankly where the most in terms of measures, their values and benchmarks have been already established. Quality development throughput is essentially an aggregate of the DORA metrics. If your lead time for change is decreasing, your deployment frequency increasing and your change failure rate stable or decreasing, naturally, it takes less time to deliver a quality product without significant regression.

So putting this together yields an equation you’ve seen before under a different guise:

\(\text{Product Velocity} = \frac{\text{Qualified Product Opportunities} \times \text{Opportunity Value} \times \text{Delivery Rate}}{\text{Quality throughput cycle time }}\)

The value in being able to express a number, even if conceptual, should be inherent. One of the biggest caveats here is that it doesn’t directly translate into Revenue like Sales Velocity does.

You and I know that certain product functionality tends to produce non-linear outcomes.

But the expression itself has value. Is Product Velocity increasing over time? Are we making strides to increase each component part? Are we better leveraging our resources? Over a long enough time horizon, especially for larger organizations, if the answer is an undisputed — yes — then like the Casino, you maximize your probability to win ceteris paribus.

Closing thoughts

Having been in the trenches of Software Engineering Measurement for some time, I believe that most leaders in Tech are primarily concerned with answering three fundamental questions:

• Are we building the right thing?

• Are we building the thing right?

• Are we building a sustainable culture to keep building the thing?

But there’s so much noise⁴ and a general under appreciation for how to measure and convey answers to these questions in a consistent accepted way.

Predictability in the consistency of how we take ideas to production and ultimately create value for customers will always be in vogue.

Organizations have a lot to gain by thinking more deeply about this and putting into place simple measures that can build on prior art and accepted formulae from other functions and industries.

Because in this case, imitation might be the sincerest form of flattery.

1. This comes from Chapter 5 “Sales” in his book “Zero to IPO”.

2. In the industry its just “theo” — this is a great, simplistic overview to complement mine. A much more robust treatment can be found in this fascinating textbook (yes, its on my shelf).

3. At some point in your career a CFO might ask you to help justify R&D spend as a percentage of revenue. How would you?

4. Often a focus on whether or not we can measure “developer productivity” or “developer experience” has us missing the forest for the trees.