AI made building fast. Now prove it mattered.

Servo is a multi-agent framework that runs the product lifecycle inside the tools your team already uses, from defining a customer outcome to measuring it in production, and it’s how we work with the teams we lead.

Works with GitHub, OpenSpec and Claude Code today.

Read the article: AI Made Building Fast. Now Prove It Mattered.

The problem

Once building is fast, the question that matters is whether the work helped the customer.

When building was slow, the cost of the build was a natural brake, because nobody committed a sprint to something without thinking hard about it first. AI-assisted development takes that brake away. When a change goes from approved spec to merged code in about half an hour at the median, building the wrong thing barely costs any time. It costs something harder to see: the attention spent reviewing it, the complexity it adds to the product, and the customer outcome you didn’t move while you were busy shipping.

Servo's pipeline from Capture to Check the bet. MTSC, 37 minutes median per change, covers Approve through Merge, including code review, CI tests and the merge decision. The bet is named at Capture and its result is checked at the end. A person decides at Capture, Approve, Merge, Release and Check the bet; agents write the spec, review it, write the code and review the code.

Median Time Spec-to-Code (MTSC) times the middle of the pipeline. Whether the work mattered is decided at the two ends: a person names the bet at the start, and on the check date the result is read from production and a person decides what to do with it.

How it works

Every change is tied to a customer outcome, before it’s built and after it ships.

The examples come from Signal, a personal agent for finding the next job or contract, which we build with Servo and use every day. Its customer is a candidate trying to land a role through a warm introduction rather than a blind application.

Start from customer outcomes, and cap them at six

A product gets up to six customer outcomes with targets, which we call customer value drivers, and each one has to be something the customer actually cares about. Six is a hard limit, so adding a driver means retiring one. Listing a dozen outcomes is easy, and the cap forces a decision about which ones the roadmap is really for.

Drivers are versioned, and editing one goes through the same explicit approval as any other change, so their history is a record of how the team’s thinking about the customer has changed.

Signal's value drivers as a chain: Reach, People asked, Follow-through and Introductions made, with Ties warmed widening who can be asked and Sources working unattended outside the chain.

In Signal, five of the drivers form a chain toward introductions made, so when one of them reads zero it shows which step is holding the rest back.

Make the outcome a check, not a principle

“Outcomes over outputs” is a principle almost every product team agrees with and very few enforce. In Servo it’s a check: a spec review agent reads every plan before a person does, and a plan that names no driver can’t be approved until it names one or the gap is waived on the record, with a name and a reason.

The plans this stops are usually good small features, like a button that saves a few clicks, that nobody connected to a customer. Sometimes writing the connection down takes a minute, and when there isn’t one, the team has learned that before any code exists. A bug fix can say it moves no driver and explain why.

Which customer outcome does this plan move? One plan from Signal's backlog names Introductions made and is ready for approval; another names none and is blocked until it names one.

Write the bet before anything is built

Naming a driver says where a feature is aimed, but not whether it hit. So every plan carries a bet, written before any code exists: the driver it should move, the expected movement from what to what, the check date, and what would count as wrong, which we call the wrong-if.

Writing the size of the effect down is usually where a fuzzy idea falls apart, and the wrong-if decides what result would make the team stop before anyone is invested in the feature. An approved bet is never edited. A changed bet supersedes the old one with its reason, and both stay visible.

A bet written before any code, for a shared list that asks for an intro to the hiring manager. Driver: Introductions made. Expected movement: from 0 introductions to 2. Check by: November 1, 2026. Wrong if: no hiring manager introductions by then.

Build the measurement with the feature

A bet is only as good as the reading taken on its check date, and this is where most outcome programs quietly stop. If the evidence depends on someone keeping a tally, the tally becomes a separate job, and separate jobs get dropped. So a bet names a count the product produces from production usage, and that count is built as part of the feature, with customer data anonymized under your privacy policy before Servo reads it. The feature isn’t done until the thing that proves it worked is in place.

Check the bet on its check date

On the check date, the driver’s count is read from production usage data and the result is recorded on the work itself: whether the driver moved, whether it moved the way the bet said it would, and whether the wrong-if came true. A person then decides whether to keep, revise or retire the driver, with the reason on record. Today a person reads the count from the product’s dashboard and records the result, and we’re adding the step where Servo takes the reading automatically.

When a driver doesn’t move, either the feature missed or the driver was the wrong measure of what the customer cares about, and the second finding is the more valuable one because it changes what the roadmap aims at.

Where Servo is going: make the colors a call to action

On most dashboards, red tells you something is wrong but not whether anyone is doing anything about it, so the meeting that follows is mostly spent finding out. In Servo the color of a driver comes from approved work. A driver that’s missing its target with planned, approved work aimed at it is yellow, because someone is on it. Without that work it’s red, however many ideas mention it.

That turns red from a performance problem to explain into a priority call to make in the meeting itself. The live drivers board that colors each driver this way is the next piece of Servo we’re building.

What the colors mean: green is on target, yellow is a miss with work aimed at it, red is a miss with nothing aimed at it. Red isn't a performance problem; it's a priority call to make now.

Evidence from Signal and Servo

What it looks like on a real product.

These figures cover work on Signal and on Servo itself, which shared one repository until Servo was split out. They move as more work goes through. Signal’s first customer bets, including the hiring manager introduction above, come due on November 1, 2026.

37 min

median time from approved spec to merged code (MTSC), per change, over 58 changes during a two-week sprint; the mean was 1 hour 34 minutes

12 of 14

known problems caught by a stronger reviewer model on the same 7 past changes, against 6 of 14 for a cheaper one, October 6, 2026

Working with us

Fractional product and delivery leadership, with Servo as how we work.

We take on a small number of clients at a time, most often a founder who needs a product team, or the person who owns product development and the lifecycle at an established company. Servo comes with us. Its core is the same for every client, and the glue that connects it to your tools is built for you.

Core

The method, the same for every client

Customer value drivers. Up to six, each with a target, written with you in your terms along with your review criteria.
The outcome check. A plan that names no driver can’t be approved.
The bet. The driver, the expected movement, the check date and the wrong-if, before any code.
Check the bet. A reading from production on the check date, and a decision on the driver.
The pipeline. An independent review agent at each stage, and a person at every gate.
The measures. MTSC, what each reviewer agent catches, and what it costs.

Glue

The connections, built around your tools

Tracker and repository. GitHub today. Other trackers are connected as part of the engagement.
Approval process. Who signs at each gate, in the way your team already works.
Where the counts come from. The product analytics or business systems each driver is read from.
Spec tooling. OpenSpec today.
Agent runtime and models. Claude Code today, with the models matched to the work.
Hosting. Servo’s pages run in your own cloud account.

Teams that want to keep using Servo after we’ve gone can run it under a license.

Where to start

You don’t need a framework to start, just three items from your roadmap and three questions.

Which customer outcome does this move? If the answer takes more than a sentence, or there isn’t one, that’s worth knowing before the work starts.
From what to what, by when? If you can’t say how big the effect should be or when you’d look, you have a hope rather than a bet.
What would tell you it didn’t work, and will anything in the product record it? If the answer is “someone will check,” plan on nobody checking.

If you’re a founder without a product leader yet, these three questions are the job, and someone on your team needs to own them. Defining your drivers and their targets is also the first thing we do together, and it needs no tooling.

Is your team shipping faster than ever without knowing whether it’s moving the outcomes that matter?

We’d like to hear about it. Bring the outcome you’re trying to move and we’ll talk through how you’d know.

Start a conversation