Product Velocity

What is product velocity?

Product velocity is how fast a team turns a decision about the product into something a customer can actually use. It is the elapsed time and throughput of the path from decision to production, plus how much of that throughput gets consumed cleaning up after itself.

It is not the number of tickets closed, the number of features on a roadmap, or the size of the engineering team.

Is there a standard way to measure it?

Not under that name. There is a standard way to measure the delivery half of it, and it comes from DORA.

DORA's current model has five metrics in two groups.

Throughput:

• Change lead time, the amount of time it takes for a change to go from committed to version control to deployed in production.
• Deployment frequency, the number of deployments over a given period or the time between deployments.
• Failed deployment recovery time, the time it takes to recover from a deployment that fails and requires immediate intervention.

Instability:

• Change fail rate, the ratio of deployments that require immediate intervention following a deployment, likely resulting in a rollback of the changes or a hotfix.
• Deployment rework rate, the ratio of deployments that are unplanned but happen as a result of an incident in production.

Note what the grouping does. Throughput without the instability metrics is a number a team can game by shipping carelessly, and the two instability metrics are the correction. A team doubling deployment frequency while its change fail rate doubles has not gone faster; it has moved work from before the release to after it.

What product velocity is not

Three substitutions do most of the damage.

Velocity is not story points. Sprint velocity measures internal estimates against internal estimates and is invisible to customers.

Velocity is not feature count. A team can ship weekly and learn nothing if none of the shipped changes are decisions about anything contested.

Velocity is not the same as growth. Graham's framing is that a startup is a company designed to grow fast, and growth is the outcome; velocity is the search rate that makes finding growth possible. A team can have excellent delivery metrics and a flat growth curve, which is a strategy problem, not a delivery problem. That is exactly why the delivery metrics are worth having: they tell you which of the two problems you have.

Worked example, arithmetic shown

All figures are hypothetical.

A team's delivery profile for a month:

• Deployments: 200.
• Median change lead time: 26 hours from commit to production.
• Change fail rate: 6 percent.
• Deployment rework rate: 3 percent.

Step one, convert the ratios into work.

• Deployments needing immediate intervention: 0.06 x 200 = 12.
• Unplanned deployments caused by production incidents: 0.03 x 200 = 6.
• Total instability-driven deployments: 12 + 6 = 18.
• Share of all shipping activity: 18 / 200 = 9.0 percent.

Step two, read it. Of 200 deployments, 182 were intended work and 18 were repair. If the team wants more product throughput without hiring, the 18 is the cheapest place to find it, and the change fail rate is the metric to attack first because failed deployments also consume failed deployment recovery time.

Step three, compare cadences rather than counts. Suppose a competitor ships on a quarterly release train.

• Weekly cadence: 52 chances a year to put a change in front of customers.
• Quarterly cadence: 4 chances.
• Ratio: 52 / 4 = 13. Thirteen times as many attempts per year, at the same headcount.

Step four, connect it to the growth arithmetic that makes it matter. Graham's rates are 5 to 7 percent a week as good, 10 percent as exceptional and 1 percent as a warning. Compounding those weekly rates over 52 weeks:

• 1.05 to the 52nd power is about 12.6, so 5 percent a week is roughly 12.6 times in a year.
• 1.07 to the 52nd power is about 33.7.
• 1.01 to the 52nd power is about 1.68.

The gap between 1.68 times and 12.6 times is what a team is searching for. Thirteen times as many attempts is how it finds it.

Where it shows up in diligence

Investors rarely ask for DORA metrics by name at seed. They ask questions that are proxies for them, and knowing which metric each question is reaching for lets a founder answer with a number instead of an adjective.

• How often do you ship? Deployment frequency.
• How long from a decision in a meeting to a customer seeing it? Change lead time, plus whatever product decision latency sits in front of it.
• What happens when a release breaks? Failed deployment recovery time and change fail rate.
• What did you learn in the last quarter that changed the roadmap? This is the one that separates velocity from motion, and it is not a DORA metric at all.
• What is your on-call load? Deployment rework rate, asked sideways.

A founder who can produce the first three from a dashboard and answer the fourth with two examples has demonstrated more about the engineering culture than any architecture diagram.

Common mistakes

• Reporting sprint velocity as product velocity. Different measurement, different audience, no customer in it.
• Optimizing deployment frequency while ignoring change fail rate, which moves effort from before release to after it and eventually reduces throughput.
• Measuring lead time from ticket creation rather than from commit to version control, which mixes queueing into a delivery metric and hides how long work sits before anyone starts it.
• Treating a big launch as evidence of velocity. Velocity is a rate, so a single event cannot demonstrate it.
• Claiming velocity as a moat. It is a search advantage, which compounds only if the team is searching for something specific.
• Comparing your numbers to a benchmark band you cannot cite. If you quote elite or high performance, quote the report and year you took the band from.

How it relates to adjacent terms

Product velocity is the mechanism underneath speed of execution, which is the judgment-level version of the same idea, and it is the process that produces shipping as an observable event. It is upstream of product-market fit, because fit is found by iteration and the iteration rate sets how long the search takes. And it is the reason an MVP is worth building at all: the point of the minimum version is to shorten change lead time for the first real customer decision.