Prototype-Led Discovery
Published June 14, 2026
Prototype-Led Discovery is Zenpo’s approach to discovering the real workflow before architecture, platform, licensing, or implementation decisions harden around the wrong assumption. It is more than a better fail-fast strategy. Failing fast is useful, but the goal is not merely to discover that an idea is wrong sooner. The goal is to make the real workflow visible early enough that the right user experience, data model, operating flow, and platform decision can emerge before expensive commitments are made.
Instead of asking stakeholders to fully specify complex work upfront, Zenpo turns early assumptions into concrete artifacts — mocks, prototypes, workflow options, mocked data models, dashboards, or working slices — so users can react while change is still cheap. A stakeholder who cannot describe a complex workflow on a blank page can almost always react to something concrete in front of them, and that reaction is where the real requirement begins to surface.
Those artifacts do more than expose bad assumptions. They surface the real workflow, data model, operating flow, UX, and platform fit earlier than traditional requirements gathering can — before the organization pays to build around fiction. For complex enterprise software and bespoke workflow environments, this is one of Zenpo’s most practical requirements gathering alternatives: artifact first, reality early, expensive commitments delayed until evidence exists.
Executive Summary
The hardest part of building enterprise software is not writing the code. It is figuring out what the software is actually supposed to do. In bespoke environments — where the workflow is specific to one organization, encodes years of accumulated practice, and lives partly in the heads of the people who run it — the requirement is rarely sitting in a document waiting to be collected. It has to be discovered. And it usually cannot be discovered by asking.
This is the uncomfortable premise behind Prototype-Led Discovery: stakeholders frequently cannot fully articulate what they need before they see something concrete. Not because they are unskilled or evasive, but because the knowledge that governs how their work actually runs is tacit — recognized when encountered, difficult to externalize on demand.1 Ask a program manager to specify a complex reporting workflow in the abstract and you will get a description of the tool they currently imagine, not the outcome they actually need. Show them a mock of that workflow and you will get something far more valuable: a reaction. "No, not that." "Yes — but it also has to do this." "Actually, the whole thing should work differently."
Prototype-Led Discovery is built to provoke those reactions early and cheaply. It is the practice of turning an early assumption into a concrete artifact — a mock, a clickable prototype, a set of workflow options, or a thin working slice against real data — fast enough that users can react to it before that assumption has hardened into architecture, platform selection, licensing commitments, or months of implementation. It is not a phase. At Zenpo it is a philosophy. Prototype-Led Discovery is Zenpo's name for a founder-led instinct that predates the company's current consulting language: when a workflow is too ambiguous to specify, build the smallest useful artifact and let reality answer. That instinct goes back to early custom-application work, where the job was routinely to solve a problem the client had been told could not be solved — and the only honest way to find out what they really needed was to build a version of it and watch them use it.
This guide explains why upfront requirements gathering fails on complex bespoke work, and why Prototype-Led Discovery replaces the document-first ritual with something stakeholders can actually react to. It introduces the mental model Zenpo uses to discover requirements through artifacts rather than documents — Discovery-by-Artifact — and shows how building the real thing in miniature surfaces the right user experience, data model, operating flow, and technical approach faster than a traditional requirements process ever could.
Requirements-First Discovery vs. Prototype-Led Discovery
| Dimension | Requirements-First Discovery | Prototype-Led Discovery |
|---|---|---|
| Primary artifact | A written specification | A concrete mock, prototype, or working slice |
| What the stakeholder does | Reviews and signs a document | Reacts to something they can see and use |
| When the real need surfaces | After build, during testing or rollout | During discovery, before commitment |
| What gets committed early | Architecture, platform, licenses — on assumptions | Nothing irreversible until an artifact justifies it |
| Failure signature | "This is not what we meant" at UAT | "No, not that" in week one, cheaply |
| Cost of a wrong assumption | Rework against shipped architecture | Discarded mock |
| Time to first feedback | Weeks to months | Hours to days |
| Treats stakeholder uncertainty as | A problem to eliminate upfront | A fact to design around |
The Problem: Requirements-Doc Theater
The default discovery model in enterprise software is to gather requirements into a document, review the document with stakeholders, get sign-off, and treat that signed document as the contract for what gets built. It is orderly. It is auditable. It is how most procurement processes are structured. And on complex bespoke workflows, it routinely produces software that technically matches the specification and still fails to do what the organization needed.
The failure is not a coincidence, and it is not new. The Standish Group has tracked IT project outcomes for nearly three decades, and incomplete requirements, changing requirements, and lack of user input have consistently ranked among the leading drivers of project failure.2 The pattern compounds with size: small projects succeed at high rates while large projects succeed far less often, in part because large projects accumulate more requirements decisions made on paper before anyone has seen anything work.3
The requirements literature is even more direct about where the damage originates. According to figures widely cited by requirements engineering practitioners, analysts report that as many as 71 percent of failed software projects trace back to poor requirements management — described as the single biggest factor, ahead of technology problems or missed deadlines.4 That number should be read as a directional analyst claim rather than a precise law of nature, but the direction is not seriously disputed: more projects die from misunderstood requirements than from bad code.
The economics make the problem worse than it first appears. Rework — redoing work that was built correctly against an incorrect understanding — consumes a large share of total project effort, and requirements errors account for the majority of that rework cost. A frequently cited 1997 study found that requirement errors can consume 70 to 85 percent of all project rework costs.5 And the cost of fixing a requirements defect climbs steeply the later it is caught — a direction well supported across decades of software engineering research, even where the exact multiplier is disputed. A frequently cited illustration, attributed to the IBM Systems Sciences Institute, puts the cost of a defect found after release at many times — by some accounts up to 100 times — what it would have cost to fix during design.6 The 2002 NIST study on the economic cost of inadequate software infrastructure put the same idea in macroeconomic terms, estimating tens of billions of dollars in annual cost, much of it traceable to defects caught too late.7
Now layer in the specific reality of bespoke enterprise work. The requirements-document model assumes the stakeholder can read a description of a workflow and reliably tell whether it is correct. That assumption breaks exactly where the work is most complex. A 3,000-page requirements list assembled by dozens of business stakeholders — the kind of artifact that has stalled real enterprise programs for years — is not a sign of thoroughness. It is a sign that everyone is writing down what they think they want, no one can see what any of it will actually feel like in use, and the document has become a substitute for understanding rather than a path to it.4
That is requirements-doc theater: the ritual of producing, reviewing, and signing a specification that gives the stakeholder nothing concrete to react to, while the real requirement stays hidden until the software is built and someone finally says the words that should have surfaced in week one — "this is not what we meant."
Why Stakeholders Can't Tell You What They Need
The instinctive response to a failed requirements process is to blame the elicitation: the analyst asked the wrong questions, missed a stakeholder, did not dig deeply enough. Sometimes that is true. But on genuinely complex bespoke workflows, better interviewing has a ceiling, and the ceiling is set by the nature of the knowledge itself.
Much of what governs how real work runs is tacit knowledge — knowledge the stakeholder holds and acts on but does not, and often cannot, hand over in words. Requirements engineering research describes this precisely: tacit knowledge is the knowledge a customer has but does not pass to the analyst, and its presence shows up as ambiguity in everything they do manage to say.1 People recognize the right answer when they encounter it, yet articulating it beforehand is difficult.8 You can interview a billing supervisor for a week and still not learn the exception they handle so automatically that they have stopped noticing they handle it — until a prototype routes that exception the wrong way and the omission becomes visible.
This is why stakeholders so often describe a tool instead of an outcome. Asked what they need, they reach for the nearest concrete thing they already understand — a report, a spreadsheet, a familiar feature — and describe that. "Give us a report we can feed into our mail merge" is a description of a mechanism, not of the goal. The goal might be something far larger that the stakeholder has never had the vocabulary to request, because no one ever put a version of it in front of them to react to. The request encodes the limits of what they have seen, not the limits of what they need.
Document review cannot reach this. Reading a specification is a low-fidelity, abstract activity; it engages the stakeholder's ability to imagine, which is exactly the faculty that fails on complex novel workflows. The two techniques that reliably surface tacit requirements are different in kind. The first is direct observation — watching the work actually happen, in its real environment, which exposes the workarounds and environmental constraints that no one thinks to mention in an interview. The second is prototyping — putting a concrete, reactable artifact in front of the user, which makes possible the kind of specific correction that abstract description never elicits.1 When stakeholders struggle with abstractions, a prototype lets them react concretely, and that reaction carries information no questionnaire can extract.
Federal modernization guidance has arrived at the same conclusion from the opposite direction. The GAO describes agile development as software that is built incrementally and continuously evaluated on functionality and customer satisfaction, and notes plainly that engaging customers early and reviewing working software regularly reduces the risk of funding a program that fails or delivers the wrong thing.9 The GAO has separately pressed federal agencies to increase their use of incremental delivery for precisely this reason — long requirements cycles that defer working software defer the moment of truth, and deferring the moment of truth is where the money is lost.10
None of this means requirements gathering is worthless. It means requirements gathering on complex bespoke work is not a collection exercise. It is a discovery exercise, and discovery requires something to react to. This is why the most effective requirements gathering alternatives all share one trait — they replace the document the stakeholder cannot react to with an artifact the stakeholder can. The question is what you put in front of the stakeholder. Prototype-Led Discovery's answer is: not a document — an artifact.
The Framework: Discovery-by-Artifact
Discovery-by-Artifact is the mental model underneath Prototype-Led Discovery. It compresses to three layers:
Assumption → Artifact → Reality.
You begin with an assumption — an explicit, stated belief about what the workflow is and what the user needs it to do. You then turn that assumption into an artifact — something concrete enough that a user can point at it, use it, and disagree with it. The artifact provokes the reality: the actual shape of the workflow, including the parts no one could put into words, surfaced because there was finally something specific to react to.
The single sentence worth remembering:
You cannot get an honest reaction to a workflow until there is a concrete artifact to react to. Discovery-by-Artifact builds the artifact first, so the real workflow surfaces while it is still cheap to change.
The power of the model is that it inverts the burden of articulation. Requirements-first discovery asks the stakeholder to do the hard thing — fully describe a complex workflow from imagination — and then builds on the result. Discovery-by-Artifact does the hard thing for them. It commits to a guess, makes the guess concrete, and lets the stakeholder do the easy thing instead: react to something real. Disagreement is cheap to give and rich in information. "No, not that" is one of the most valuable sentences in software, and it is almost impossible to say to a blank page.
Artifacts are not all the same, and part of the discipline is choosing the lowest-cost artifact that will produce a real reaction. They form a short ladder of increasing fidelity and cost, each one de-risking a different commitment:
- Mock — a static picture of the screen or output. Produced in hours. It de-risks the basic question of shape: is this even the right kind of thing? A mock gets a reaction before any design work is committed.
- Prototype — a clickable, navigable version with no real engine behind it. Produced in days. It de-risks flow: does moving through the workflow match how the work actually happens? A prototype gets a reaction before architecture is committed.
- Workflow options — two or three concrete alternatives presented side by side. It de-risks direction: among plausible ways to structure this, which one fits? Options force a choice the stakeholder could not have made in the abstract, and they surface the criteria the stakeholder did not know they had — before a platform or licensing decision is committed.
- Working slice — one real path, built thin but real, running against real data. Produced in a week or two. It de-risks truth: does this actually work against the messy reality of the organization's data and edge cases? A working slice gets a reaction before full implementation is committed.
The escalation is deliberate. You do not build a working slice to answer a question a mock could have answered. You climb the ladder only as far as the next real reaction requires, and every rung is cheaper to discard than the commitment it protects. A thrown-away mock costs hours. A wrong architecture, chosen because the workflow was never made concrete, costs months.
It is worth being clear about what counts as an artifact here, because the obvious examples — screens, clickable prototypes — undersell the model. An artifact is anything concrete enough to be reacted to, and on bespoke enterprise work the thing that most needs reacting to is often not a screen at all. It is the data model.
A historical engagement in a clinical trials environment makes the point.11 A CRM-style platform team was working to model specialized clinical trials concepts in the abstract — care centers, programs, people, roles, the relationships among them, and the reporting those relationships had to support. The risk was a specific domain-modeling risk: a standard CRM data model would harden into the data architecture before anyone had validated that it could represent the real clinical trials workflow. Once a model is committed to architecture, later requirements have to be accommodated within it — and a model that was never validated against the domain increases rework risk as those requirements arrive.
Rather than continue refining the object model in the abstract, the team built mock database tables, populated them with meaningful clinical trials sample data, and exercised real reporting and workflow questions against that mocked model: does this structure answer the questions the program actually needs answered, and can it represent the relationships that genuinely exist between care centers, programs, and people? This was not a throwaway screen produced in an hour. The data model was foundational, so the artifact took longer to build. It remained disposable by design. If the mocked tables, the sample data, and the reports run against them could not represent the real clinical trials relationships, the model would be set aside before it became architecture. Discovery-by-Artifact validates domain models and data relationships, not only user interface screens, and the higher the cost of an incorrect model, the more it justifies the effort of validating it through a mock first.
In one paragraph: Discovery-by-Artifact does not replace asking. It refuses to mistake the first answer for the real requirement. It states an assumption, turns it into the cheapest artifact that will provoke a genuine reaction — mock, prototype, workflow options, or working slice — and uses that reaction to surface the real workflow before any irreversible commitment is made. The artifact is not the product. It is the instrument of discovery, and its job is to be reacted to and, often, thrown away.
Implementation: Running Prototype-Led Discovery
Running discovery this way changes what the early weeks of an engagement look like. The deliverable of the first phase is not a requirements document. It is a reaction — captured, specific, and acted on.
Start by making the assumption concrete
The engagement opens by stating the working assumption out loud and immediately building the cheapest artifact that tests it. If a stakeholder asks for a particular output, the team does not write a specification for that output; it mocks the output and the workflow around it, in hours, and brings it back. The point is not to deliver what was asked. The point is to give the stakeholder something concrete enough to disagree with, because the disagreement is where the real requirement lives.
This is a discipline, not a reflex toward speed for its own sake. The artifact is built to provoke a decision, and it is scoped to exactly the question being asked. A mock that tries to answer every question at once answers none of them clearly.
Put options in front of people
When the right direction is genuinely unclear — and on bespoke work it usually is — the team builds two or three concrete workflow options rather than debating them in the abstract. Side-by-side alternatives do something interviews cannot: they make the stakeholder's implicit criteria explicit. A stakeholder who cannot tell you what matters can almost always tell you which of three concrete options is closest, and why the other two are wrong. That "why" is the requirement, and it would not have come out any other way.
Cut a working slice against real data
Mocks and prototypes answer questions about shape and flow. They cannot answer whether the thing survives contact with the organization's actual data, which is invariably messier than anyone admits in an interview. So the team cuts a thin working slice — one real path, end to end, running against real records — as early as the workflow allows. This is where the last category of hidden requirements surfaces: the exception that breaks the happy path, the data quality problem no one disclosed, the integration that does not behave as documented. Discovering these during a one-path working slice is inexpensive. Discovering them after the full system is built around the wrong assumption is not.
Staff it with people who build, not only people who analyze
Prototype-Led Discovery requires people who can produce a concrete artifact quickly — engineers and designers who can turn an assumption into a mock or a working slice in the time a traditional process spends scheduling the requirements workshop. A discovery team that can only produce documents will, inevitably, produce documents. The composition of the team determines whether discovery happens through artifacts or through paper. This is where Zenpo's lineage in custom application development matters: the same capacity that builds durable enterprise systems is what makes fast, throwaway discovery artifacts possible in the first place. You cannot prototype your way to clarity without people who can build.
Where AI fits — and where it does not
Modern AI tooling compresses the cost of producing artifacts, and that is genuinely useful. In commercial and nonprofit environments, tools like Claude, ChatGPT, Copilot, and Cursor can turn an assumption into a mock, generate plausible workflow variations, or stand up a throwaway prototype faster than was possible a few years ago — shrinking the gap between "we think the workflow is this" and "here is something you can react to." In federal settings, the available toolset differs, but the principle is identical: anything that lowers the cost of making an assumption concrete strengthens the discovery loop.
But AI compresses artifact production; it does not replace the judgment at the center of the philosophy. A model can generate ten prototypes. It cannot sit across from a program team, watch which one makes them lean forward, and recognize that their reaction means the real workflow is something none of the ten quite captured. Discovery is the act of provoking and interpreting a human reaction to a concrete thing. AI makes the concrete thing cheaper to produce. The discovery is still done by people who know what they are looking at.
What this protects
Every artifact-driven reaction lands before an expensive, hard-to-reverse decision. Run this way, a discovery-led engagement surfaces the right answers to the questions that actually drive cost — the user experience, the data model, the operating flow, and the technical approach — and it surfaces them while they are still cheap to change. It keeps a team from forcing a workflow into the wrong platform because the platform was chosen before the workflow was understood, a failure the companion discipline of product-led consulting addresses from the technology-selection side. Prototype-Led Discovery is the upstream half of that story: you cannot choose the right platform for a workflow you have not yet made real.
Common Failure Modes
Prototype-Led Discovery is a discipline, and disciplines fail in characteristic ways. These are the five most common.
Spec-as-contract theater
The original dysfunction. The engagement produces a requirements document, treats it as the binding definition of done, and builds against it without ever putting a reactable artifact in front of a user. The document gets more detailed over time, which feels like progress and is not — detail in an unreacted-to specification is just more assumption, more confidently stated. The tell is simple: if no stakeholder has reacted to anything concrete before the build starts, discovery did not happen.
Mistaking the prototype for the product
The mirror failure. A prototype gets a strong positive reaction, and someone decides to ship it. But a discovery artifact is built to be reacted to, not to be operated, secured, or maintained. Demo-ware promoted to production carries none of the durability the real system needs and all of the shortcuts the prototype was allowed to take. The artifact's job was to surface the requirement. Once it has, it should usually be thrown away, and the real thing built deliberately on what it taught.
Falling in love with the first artifact
The team builds the first mock, the stakeholder reacts well enough, and everyone stops. The first artifact almost never captures the whole workflow — it captures the part that was easy to imagine. Stopping at the first "yes" leaves the tacit requirements undiscovered, which means they will surface later, after commitment, as expensive surprises. The artifact that gets an easy yes is often the one that has not yet asked the hard question.
Choosing the platform before the workflow is real
A decision about the technology — the platform, the licensing model, the architecture — gets committed early, on the strength of an assumption, before any artifact has made the workflow concrete. From that point on, every prototype is constrained by the selected platform, and discovery narrows accordingly: it can only surface requirements the platform can already satisfy. The value of building the workflow first is to select the platform for the real workflow, rather than fit the real workflow to a prematurely selected platform.
A historical clinical trials reporting and decision-support engagement shows how an artifact identifies this in time.11 Power BI was being treated as the natural platform answer for an enrollment projections dashboard. The stated need was framed as a dashboard, and the conventional path would have been to begin building production-grade BI components against that assumption, committing implementation effort to the selected platform before the actual decision problem the dashboard had to serve was fully understood. Instead, the team produced lightweight dashboard artifacts: a single-page app driven by mocked chart data and custom visualization behavior, built to explore what leadership-level and board-level concerns the dashboard genuinely needed to answer. Those artifacts surfaced that the real need was not generic BI visualization. It required advanced enrollment projection behavior and custom modeling that Power BI could not represent cleanly out of the box. The artifact invalidated the premature platform assumption — a platform-fit issue identified before significant implementation effort was committed. The discovery protected the engagement from continued investment in a platform path that was not aligned with the real decision problem.
Prototyping in a vacuum
Artifacts are built, but never against real users or real data. Mocks get reviewed internally; prototypes get demonstrated to sponsors who are not the people doing the work; working slices run against clean synthetic records that hide every messy reality. An artifact that no real user reacts to, and that never touches real data, produces a comfortable illusion of discovery while surfacing nothing. The reaction has to come from the people who actually run the workflow, against data that actually resembles theirs.
Real-World Scenario
The following is drawn from an anonymized engagement; identifying details have been altered.12
A program team came in with a clear, modest-sounding request. They produced an annual report and wanted a better data export — specifically, a report they could keep feeding into a Word mail merge, the way they always had. The ask was concrete, familiar, and easy to write a specification for. A requirements-first engagement would have done exactly that: documented the export format, built it, delivered it, and moved on.
Instead, the team treated the request as an assumption to be tested rather than a requirement to be implemented. They built a quick mock of the end-to-end reporting workflow — not just the export, but what happened around it — and a couple of concrete workflow options for how the annual report could be produced. Then they put those options in front of the people who actually assembled the report each year.
The reaction reframed the entire engagement. Looking at a concrete alternative, the team realized the mail merge was not the requirement. It was a workaround they had built years earlier because no one had ever shown them anything better. The real need was the whole workflow they performed manually around that export: pulling data from the operational system, blending it into recipient-ready report packages, generating the addendum reports that only some recipients received, and producing the populated email outputs that went out with each package. The mail merge was the visible tip of a substantial annual process that lived entirely in people's heads and in a sequence of manual steps no one had ever written down.
Seeing the options moved the conversation from "give us a mail merge report" to "yes — automate the whole annual report workflow." That sentence was the actual requirement, and it had been unavailable to everyone, including the program team, until there was a concrete artifact to react to. No interview had produced it. No specification would have contained it, because the stakeholders themselves did not know to ask for it.
What followed was a genuinely useful system instead of a marginally better export. But the system was not the point of the story. The point is that the right scope surfaced during discovery, from a mock and a set of options built in days, rather than after a literal mail-merge export had been specified, built, delivered, and quietly continued to paper over a workflow that should have been automated all along.
Measuring Success
Prototype-Led Discovery produces outcomes that can be measured, and the metrics are different from those of a requirements-first process. Buyers evaluating how an engagement is run should watch four things.
Time to first artifact
How long from engagement start until a stakeholder reacts to something concrete? In a healthy Prototype-Led process this is measured in days, not weeks, because the first artifact is a mock, not a finished specification. A long silence at the start of an engagement — weeks of interviews and document drafting with nothing concrete produced — is the signature of requirements-doc theater, regardless of what the methodology is called.
Reaction rate
How often do early artifacts produce a decisive reaction — a clear "no, not that" or "yes, that's it" — rather than a noncommittal nod? Decisive reactions are the product of discovery. A process that generates lots of artifacts but only polite, ambiguous responses is usually showing the artifacts to the wrong people, or building them too abstractly to disagree with. The goal is not approval. The goal is information, and disagreement carries more of it than assent.
Assumptions retired before commitment
How many wrong assumptions were caught and discarded while they were still cheap — before architecture, platform, or licensing decisions were made? This is the metric the whole philosophy exists to move. A discovery process that retires a dozen wrong assumptions against throwaway mocks has done its job; the cost of being wrong was a dozen discarded artifacts instead of a rebuilt system. Counterintuitively, a discovery phase that surfaces more wrong assumptions is doing better, not worse — each one caught here is one that did not detonate after the build.
Decisions deferred until an artifact justified them
How many irreversible decisions were held open until a concrete artifact made the right answer clear? The discipline is not to decide the platform, the data model, or the architecture on day one and then validate the decision. It is to keep those decisions open until the workflow has been made real enough to decide them well. A proposal that commits to a platform before any artifact exists is making the exact mistake this approach is designed to prevent.
Costly commitments avoided
This is the metric that translates the others into money, and it is the one a budget owner should weigh most heavily. The value of Prototype-Led Discovery is measured by the expensive commitments it avoids — or defers until an inexpensive artifact has justified them. Each commitment caught early is a cost that did not materialize: a premature platform selection that an artifact invalidated before licensing was procured; a licensing assumption that turned out to be unnecessary once the real workflow was understood; rework avoided because a data model was validated against the domain before it hardened into architecture; a production BI or dashboard buildout deferred until the underlying decision problem was confirmed; and, most simply, building a report when the real need was workflow automation. None of these costs appears in a status report, because the point is that they were never incurred. A discovery process that can name the specific commitments it avoided — and roughly what each would have cost — is demonstrating its return directly.
What to look for in a proposal
Proposals built on Prototype-Led Discovery describe early artifacts, not just early documents. They commit to putting something concrete in front of real users within the first days or weeks. They treat the stated request as a starting assumption to be tested rather than a final requirement to be implemented. And they defer technology commitments until the workflow has been made real. A proposal that leads with a fixed architecture, a chosen platform, and a detailed requirements phase — all before anyone has reacted to anything concrete — is a requirements-first engagement wearing modern vocabulary, and it carries the failure modes this guide describes.
Summary and Key Takeaways
Prototype-Led Discovery is Zenpo's philosophy for discovering what enterprise software actually needs to do. It rests on a single premise: on complex bespoke workflows, stakeholders frequently cannot fully articulate their needs upfront, because the knowledge that governs their work is tacit and surfaces only in reaction to something concrete. A requirements document gives them nothing to react to. An artifact does.
The mental model is Discovery-by-Artifact — Assumption → Artifact → Reality. State the assumption, turn it into the cheapest artifact that will provoke a genuine reaction, and use that reaction to surface the real workflow before any irreversible commitment. The artifacts form a ladder of escalating fidelity and cost — mock, prototype, workflow options, working slice — and each rung de-risks a specific commitment while staying cheaper to discard than the decision it protects.
The key takeaways:
- Stakeholders' inability to specify complex workflows upfront is a property of tacit knowledge, not a failure of effort. Design discovery around that fact instead of trying to eliminate it.
- Build the artifact first. "No, not that" is the most valuable sentence in discovery, and it cannot be said to a blank page or a signed specification.
- Climb the artifact ladder only as far as the next real reaction requires. A discarded mock costs hours; a wrong architecture chosen on an untested assumption costs months.
- AI compresses the cost of producing artifacts. It does not replace the judgment required to provoke and interpret the human reaction that discovery depends on.
- Keep the expensive decisions — user experience, data model, operating flow, platform, technical approach — open until a concrete artifact has surfaced the real workflow. You cannot choose the right platform for a workflow you have not yet made real.