Work

The Story

A client comes to a consultancy with a familiar ask: help us figure out what to build.

They want a product strategy. A roadmap. A backlog. A rough sense of what it'll cost and how long it'll take. They've done this kind of engagement before. They expect it to take eight weeks, end with a stack of polished documents, and produce enough clarity that their engineering team can start building.

This is how product discovery has worked for two decades. It's the model every consultancy runs. It's the model the client is paying for.

And it's the model we stopped running.

What follows is what we did instead, why we did it, and what it changes.

Why The Old Model Stopped Working

The traditional discovery engagement is built around a specific assumption: if we define enough up front, we reduce risk.

That assumption used to be true. When building software was slow and expensive, the cheapest way to reduce risk was to think harder before you started. Workshops, interviews, wireframes, specifications — all of it existed to make sure that when engineering finally began, they were building the right thing.

Three things have changed that calculus.

Building got cheap. AI-assisted development has collapsed the time between "idea" and "working prototype." What used to take a sprint now takes a day. The bottleneck is no longer how fast you can build — it's whether you should be building it at all.

Documents stopped being reliable. A polished strategy deck looks the same whether it's based on real evidence or confident guesses. The artifact doesn't tell you which assumptions were tested and which were just plausible. Clients increasingly receive beautiful, defensible-looking documents that fall apart the moment delivery starts and reality intervenes.

Risk discovered late is disproportionately expensive. When you commit to architecture, scope, and timeline based on assumptions that turn out to be wrong, you don't just lose the work — you lose the months you spent building on top of it. The cost of being wrong compounds.

The traditional model was optimized for a problem we don't have anymore: the cost of building before we're sure. The problem we have now is the opposite: the cost of being sure before we have evidence.

Evidence Work is the operating model that addresses the new problem.

The Core Idea In One Sentence

Work advances when uncertainty has been reduced — not when time has passed.

That's it. Everything else flows from that.

In the traditional model, the calendar drives commitment. Week four arrives, so the roadmap exists. Week six arrives, so the backlog gets estimated. The team produces what the schedule demands, regardless of whether the underlying questions have been answered.

In Evidence Work, confidence drives commitment. A piece of work moves forward when the team has actually validated the assumptions underneath it. If those assumptions haven't been tested, the work doesn't advance — even if the calendar says it should.

This sounds small. It changes everything.

What This Looks Like in Practice

Imagine the engagement we mentioned at the start. Eight weeks. A new product capability. The traditional approach would spend the first three weeks in workshops and interviews, producing a strategy document and a roadmap that tries to cover the whole solution. Engineering would start building from that document in week four or five.

Evidence Work runs differently from day one.

Week one: identify what could make this fail.

Instead of asking "what should we build," the team asks "what would have to be true for this to work?" Every belief that the project depends on gets named. Users will adopt this. The technology can support it at scale. The integration will work within performance constraints. The business case holds at the price point. Each of these is an assumption, and each one is potentially wrong.

The team prioritizes them by a simple test: which assumption, if wrong, would force us to start over? That assumption gets tested first.

Week two: design the smallest possible test.

The team doesn't build the full feature to test the assumption. They build the smallest thing that would generate real signal about whether the assumption holds. If the question is "will users complete this workflow in under ten minutes," the test is an instrumented prototype with a small user group, not a polished version of the final product. If the question is "can the system render this much data on a mobile device," the test is a technical spike with measurable performance criteria, not a working app.

These tests are deliberately disposable. They exist to produce evidence, not to become the product.

Week three: read the signal honestly.

The test produces data. The data either supports the assumption or it doesn't. If it does, confidence in that part of the system goes up, and that capability can move toward commitment. If it doesn't, the team has just learned something critical — early enough to change direction without having committed to the wrong thing.

This is the moment that separates Evidence Work from everything that calls itself "lean" or "agile." The team is not allowed to interpret ambiguous signal as confirmation. If the evidence isn't there, the conclusion is "we don't know yet," not "let's proceed and figure it out as we go."

Weeks four through eight: scale what's earned.

As assumptions get validated, parts of the product move from exploration to commitment. Architecture hardens. Production work begins. But this happens piece by piece, as confidence accumulates — not all at once because a phase boundary arrived.

By week eight, the team has produced the same set of deliverables the traditional model would have produced — strategy, roadmap, backlog, cost estimate — but every claim in those documents is traceable to actual evidence. Where the evidence is strong, the language is definitive. Where it's directional, the document says so. Where assumptions remain untested, those are flagged as risks the delivery team will need to address.

The client receives something different from what traditional discovery produces: not a polished plan that simulates certainty, but an honest map of what's known, what's likely, and what's still unresolved.

What Changes for the Team

In a traditional engagement, the team is divided by function. Strategists strategize, designers design, engineers wait for specifications. Each role produces its own artifacts, and the engagement progresses through a sequence of handoffs.

Evidence Work breaks this structure in three places.

Engineering participates from day one. Feasibility isn't something to validate after a strategy is defined. It's one of the first things tested, because feasibility risk is often the highest risk. Engineers in an Evidence Work engagement are not waiting for a spec — they're running technical spikes alongside the strategists running stakeholder interviews. Both kinds of work produce evidence. Neither is more important than the other.

Strategy is generated by signal, not by synthesis. Traditional strategists produce a strategy document by interviewing stakeholders, reading research, and writing a coherent narrative. Evidence Work strategists do something narrower and more rigorous: they identify the assumptions the strategy depends on, design tests for the riskiest ones, and let the strategy emerge from what gets validated. The output looks similar. The path to it is fundamentally different.

Design becomes a tool for testing, not just a deliverable. A prototype in Evidence Work isn't a vision of the finished product. It's an instrument — built to generate signal about a specific question. Sometimes the prototype is polished, because polish is what the test requires. Sometimes it's deliberately rough, because the question being tested doesn't need polish to answer. Designers are not producing the look-and-feel of a future product. They're producing the artifact that resolves the next critical uncertainty.

The team is smaller because there's less artifact production. The work is harder because every claim has to be defensible. The output is better because nothing in the final deliverables is there because someone had a plausible opinion.

What Changes for the Client

From the outside, less than you'd expect. The engagement still runs eight weeks. The deliverables list still includes a strategy, a roadmap, a backlog, and a cost estimate. The client doesn't have to learn a new methodology or adopt a new vocabulary.

What they receive at the end is different in one important way: it's honest about what's known and what isn't.

The strategy document doesn't claim conviction it hasn't earned. The roadmap distinguishes between capabilities that have been validated and capabilities that are still hypotheses. The cost estimate carries confidence levels — what's tightly bounded because the technical constraints are confirmed, what's a range because the integration risk hasn't been fully resolved, what's a placeholder because the underlying assumption is untested.

For clients used to receiving documents that read with uniform confidence, this can be initially unsettling. It looks less polished. It admits more uncertainty.

But the value is in what happens next. When delivery begins, the team isn't surprised by what they find. The risks the discovery flagged were real risks. The capabilities marked as validated actually deliver. The places where the document said "we don't know yet" are where the engagement saved the client from committing prematurely.

The client paid for confidence. They received it honestly mapped, rather than uniformly performed.

What Evidence Work is not

It's worth being precise about a few things this approach is sometimes confused with.

It's not faster discovery. The engagement isn't shorter. The number of meetings isn't reduced. What changes is what the time is spent on — testing assumptions instead of producing documents.

It's not "lean" or "agile" rebranded. Lean methods focus on customer validation. Agile focuses on iterative delivery. Evidence Work is about something different: governing investment depth through validated confidence. It draws on those traditions but its core mechanism — confidence as the gate for commitment — is its own thing.

It's not a way to skip planning. Architecture still gets defined. Backlogs still get built. Cost estimates still get produced. What changes is the order: tests run first, plans get built on top of validated constraints, not on top of assumptions that no one has questioned.

It's not anti-document. Documents still exist. They're generated from the underlying evidence rather than written from synthesis, and they reflect confidence levels honestly. The deliverable isn't the document. The deliverable is the evidence the document expresses.

Why this matters now

For most of software's history, the constraint on building good products was building. Engineering capacity was scarce, expensive, and slow. The right operating model was one that protected engineering from wasted effort by defining everything carefully before they started.

That world is over. AI has collapsed the cost of building. The cheapest part of producing software is now writing the code. The expensive part is figuring out whether you should.

The teams that win in this environment aren't the ones with the fastest delivery. They're the ones that reduce uncertainty fastest — that build the right thing because they spent their time learning, not documenting; testing, not synthesizing; validating, not assuming.

Evidence Work is what that operating model looks like in practice. It's not a methodology. It's not a process improvement. It's a different answer to the question every product team is now asking, whether they realize it or not:

In a world where building is cheap, what's the discipline that makes sure we build the right thing?

The answer, in our model, is this: let confidence govern commitment, and let evidence — not opinion, not documentation, not stakeholder enthusiasm — be what produces confidence.

That's the whole idea. Everything else is mechanism.