Outcome-Based Development: How to Build Products in the Age of AI
Make this true. And prove that it stays true.
AI changes the question from “How do we build this?” to “What must be true when it works?”
Define the outcome. Let agents handle more of the implementation. Keep checking that the outcome holds.
That's outcome-based development.
Start with a missed call.
An unanswered call appears in the right team's callback queue, attached to the right contact. The team gets notified. A repeated event doesn't create two follow-ups.
Give an agent that promise and checks that enforce it. It can build, test, inspect the failure and repair the implementation. It doesn't get to redefine success to make the tests pass.
A missed call should never disappear.
The call ends. The follow-up begins.
Five promises. One customer journey.
Send robots through the business.
A robotic night shift can exercise the whole journey, including the failures your demo conveniently avoids.
Now let robots try to break it.
Repeat the event. Drop the connection. Inspect the records.
Five customers. Five ways to find a broken promise.
Inspect what actually happened. Anthropic's evaluation guidance distinguishes an agent's account of its work from the resulting state of the system. “Done” is a claim. The call record is evidence.
Run critical checks before release and keep testing afterward. Feed real customer failures back into the suite. When the product itself uses AI, repeat representative tasks to measure consistency.
Passing every night means little if you're checking the wrong things. Defining success and challenging the evidence remain engineering work.
So does recovery. DORA found AI adoption associated with greater throughput and greater instability. Small releases, monitoring and rollback can make some mistakes cheaper. They cannot undo every mistake.
Knowing what to build becomes the advantage.
In my Salesforce piece, the point was that a conversation already contains the information people are asked to enter into a CRM.
An agent can build a beautiful call-logging form. Better judgment asks why the form exists.
As implementation gets easier, customer understanding and taste become more valuable. Which workflow should exist? Which three steps can disappear? What would save the customer from doing the work at all?
The race moves toward discovering the useful outcome first and delivering it reliably.
Make this true. And prove that it stays true.
