Thirty-seven minutes
Most of what I read about spec-driven development is about two things: writing better specs, and how fast AI agents can turn them into working code. Both deserve the attention, and the speed in particular isn’t hype: on Signal, the personal agent I’m building to explore job opportunities and contracts, my median time from an approved spec to merged code was 37 minutes during a two-week sprint. That includes work on Servo, the multi-agent development framework I use to build Signal, which shared Signal’s repository until it was split out.
But once building is that fast, “how fast can we ship it” becomes the easy question to answer, which is good news for the marketing team building a go-to-market plan around the date. The harder question that’s left is the one it was always supposed to be:
Did the work matter to the customer?
Most writing on spec-driven development ends at merge or release, once the code matches the spec. Almost none of it asks whether the spec was worth building, and that’s where I’ve spent most of my effort. The rest of this article covers how I’ve put that into practice on a product I’m building and using every day.
Speed moves the risk
When building was slow, the build was the expensive part, so it made sense to measure it. Story points, velocity and burn-down charts all answer some version of “how much did the team get done?” They were never great at telling you whether any of it helped a customer, but the cost of building gave you a natural brake, because nobody committed a sprint to something without thinking hard about it first.
AI-assisted development takes that brake away, because 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 you spent reviewing it, the complexity it adds to the product, and the customer outcome you didn’t move while you were busy shipping.
I’ve seen this movie before. At Intel, in the Pentium II and III days, I worked with speech recognition software vendors, testing their products on faster processors. What we found was that a faster processor just got you to the wrong answer quicker, because the real limits were in the algorithms, not the chip. AI-assisted development is the faster processor in that story, and deciding which customer outcome to aim at is the algorithm.
A mentor of mine taught me that value migrates: over time, it moves away from whatever has become cheap and toward whatever is still hard. In software it’s migrating from writing code to shipping outcomes, and the discipline has to follow it, because the build no longer forces you to choose carefully.
Start from customer outcomes, and cap them
Signal’s customer is a candidate trying to land a role through a warm introduction rather than a blind application. Everything I build is supposed to serve that, so I wrote down six customer value drivers, each one an outcome the candidate actually cares about:
- Introductions made: introductions per fortnight
- People asked: distinct contacts sent a shortlist, per fortnight
- Follow-through: possible intros with no recorded ending
- Ties warmed: contacts who moved from weak ties to people I know
- Reach: companies where I know someone that Signal isn’t searching yet
- Sources working unattended: job sources that are failing, dropping or still checked by hand
The first five form a chain: reach decides who I can ask, ties warmed widens that group, asking leads to follow-through, and follow-through leads to introductions. When one of them reads zero, it shows me which step is holding the rest back.
Six is a hard limit, so adding a driver means retiring one, and that constraint does more work than any of the drivers themselves. Listing a dozen outcomes is easy, but a cap forces you to decide which ones the roadmap is really for. The drivers are also versioned, and editing one goes through the same explicit approval as any other change, so their history is a record of how my thinking about the customer has changed.
Check for the outcome before you plan
“Outcomes over outputs” is a principle almost every product team agrees with, and very few have had the tools to enforce. Without those tools, the principle lives on a slide, and the roadmap fills up with features that are each perfectly reasonable on their own.
In Servo, the multi-agent framework I’ve built to tie every change to a customer outcome, this is a check. Every plan has to name the value driver it’s meant to move. Before I review a plan, a spec review agent reads it, and a plan that doesn’t name a driver gets a finding. Plans that have open findings can’t be approved, so the only paths forward are to name the outcome or to waive the finding on the record, with my name and reason attached.
This check is aimed at reasonable small features, like a button that saves a few clicks, that nobody stopped to connect to a customer outcome. Sometimes the connection is real and writing it down takes a minute. If you can’t name an outcome, the idea isn’t ready to become code.
There’s one honest exception: a bug fix defaults to no driver, since fixing a broken back link doesn’t need a thesis about customer outcomes.
Predict the result before you build
Naming a driver tells you where a feature is aimed, but not whether it hit. For that, every plan in Signal carries a bet, written before any code exists:
- Driver: which customer outcome it’s meant to move
- Expected movement: from what to what, in the driver’s own measure
- Check by: the date I’ll look
- Wrong if: what I could see that would count against the bet
Here’s a real one from Signal: today, when I share a shortlist of roles with a contact, Signal asks them who they know at the company. Four shares have brought two “I might know someone” answers and no introductions. So the next change asks for something more specific: an introduction to the role’s hiring manager, with an introduction paragraph they can copy and use.
The bet says Introductions made will go from 0 to 2 by November 1, and that I’m wrong if there are still no hiring manager introductions by then.
Writing it down this way does two things: it makes me say how big the effect should be, which is usually where a fuzzy idea falls apart, and before I’m invested, the wrong-if forces me to decide what result would make me stop. Once I’ve built something and want it to work, I’m the worst person to make that call.
One more rule: a bet is never edited after it’s approved. If I learn something and want to change it, the new bet supersedes the old one, with the reason, and both stay visible, because a bet that can be quietly rewritten after the fact stops being a bet at all.
Build the measurement with the feature
A bet is only as good as the reading you take on its check date, and this is where most outcome programs quietly fail. If the evidence depends on someone keeping a tally, the tally becomes a separate job. Separate jobs get dropped, and a bet nobody checks is the same as no bet at all.
So the rule Signal now runs on is simple: a bet names a count the product produces, and that count is built as part of the feature. If a change is supposed to increase introductions, the change also records when an introduction happens, and any personal information it captures is anonymized to meet Signal’s stated privacy policy. A feature isn’t done until it records how it performed. That evidence feeds the next round of roadmap decisions.
Signal now has a dashboard that shows each value driver, the bets aimed at it, the date each bet is due and its current reading. On November 1, the result of the hiring manager bet above comes straight from that dashboard.
This measurement is what closes the feedback loop that drives the product lifecycle. It should never have been optional, but it was usually the first thing cut when a deadline got tight. AI-assisted development changes that: when an agent builds the instrumentation alongside the feature, it costs minutes, so it’s easy to keep in scope.
Color for action, not status
KPIs on dashboards are usually color-coded status messages. 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.
Here’s how I’m overloading the colors on Signal’s value drivers to indicate action, in the live drivers board that’s the next piece of Servo I’m building:
- Green: on target
- Yellow: a miss, with work aimed at it
- Red: a miss, with nothing aimed at it
The thing that changes the color is approved work: if a driver is missing its target and there’s planned, approved work to address it, it’s yellow, because someone is on it. If there isn’t, it’s red, however many ideas mention it.
That changes what red asks of you, because it stops being a performance problem to explain and becomes a priority call that needs to be made now. For a product leader, that’s the more useful question, since it’s one you can act on in the meeting itself.
Check the bet and close the loop
A bet earns its keep on its check date. I open Signal’s dashboard, read the count the feature was built to produce, and record the result 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. The result decides what happens next. If the driver moved, the bet held and the next piece of work can build on it. If it didn’t, 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. A driver can be kept, revised or retired, and since drivers are versioned and approved like any other change, the reason stays on record.
The first bets in Signal come due in November, including the hiring manager introduction above. I’ll share what they show, whichever way it goes.
Where to start
You don’t need a framework. First, define your customer value drivers: the handful of outcomes your customers care about, capped so you have to prioritize. Then take three items from your current roadmap and ask 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, not 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.
AI made building fast, and that’s a gift, but only if the time it frees up goes into making sure we’re building the right things. The teams that pull ahead won’t be the ones that ship the most, but the ones that can show what their shipping changed for the customer.
Servo is the framework I’ve built around these ideas. It runs the product lifecycle inside the tools a team already uses, from defining a customer outcome to measuring it in production, and today it works with GitHub, OpenSpec and Claude Code. I use it with the teams I work with, and teams who want to keep running it after I’ve gone can do so under a license.
Tom Meese is a principal at Switchfoot Advisory Group, which helps companies build products and the process that builds them. His writing comes from his own projects or public information. He doesn’t name clients or share anything from their work without their permission.