There is a quiet violence we do to early ideas. We civilize them too early.
An idea often begins in a fragile, half-formed state, surfacing in conversation when someone notices a workflow that feels unnecessarily complex, a decision that could be improved, or a tool that seems to be missing. In that moment, before the idea has been shaped or tested in any concrete way, it is already asked to justify itself, to become clear, structured, and respectable.
We ask for a slide,
then an intake form,
then a business case, stakeholder alignment, an estimate, a roadmap, a set of requirements and a place in a backlog.
Each step demands more precision from an idea that no one has made tangible yet. The process creates the appearance of alignment, while each person is still agreeing to a different version in their own head.
Eventually, perhaps months later, a first tangible version appears. Someone tries it and immediately says, “Oh. That is not what I meant.”
That moment is usually treated as a change in requirements. More often, it is the first time the team’s requirements have encountered reality. The distance travelled before that reaction is the prototype gap.
Figure 1. The prototype gap is the distance travelled before anyone has something tangible enough to challenge. Illustration generated with GPT Image 2.
The gap is filled with meetings, documents, estimates and attempts to create certainty. Some of those activities are necessary once an organization decides to build and operate a real system. Production software deserves serious attention to security, data, architecture, integration, reliability and ownership.
The mistake here is the one of timing. We apply production-level seriousness while we are still trying to discover what the thing should be.
We have made an expensive phase out of deciding whether something deserves to become expensive.
A prototype is a way of thinking
We often treat a prototype as an early product, which makes it sound like a delivery activity requiring designers, developers, environments, funding and complete requirements. By the time a team receives permission to create one, much of the uncertainty has already hardened into commitments.
Figure 2. “Prototype to Decide,” from the Stanford d.school Design Thinking Bootleg Deck (2018): when the team disagrees, build low-resolution prototypes and test them with users. Illustration by Kim West.
Design researchers use prototypes as generative objects that help people explore a design space. Stanford’s d.school frames prototyping as a way to move from “I wonder” toward “I know.” The purpose is to make something that exposes what the team may be missing.
A learning prototype can contain one workflow, three screens and a fake backend. It can use sample data. Buttons may lead nowhere. Rules can be simulated by a person. A data pipeline might be represented by a small script and a few prepared outputs.
Its job is to provoke an informed reaction.
An idea can feel complete while it remains private because its missing parts stay invisible. The sentence “the user should be able to submit an integration request” sounds clear until someone has to design the form, at which point the team has to answer specific questions:
- Which user?
- What information do they know at that point?
- What information must come from the instrument owner, the data team or the site?
- Can they save an incomplete request?
- What happens when the instrument is not in the catalog?
- Who decides whether the request is technically feasible?
The prototype may not answer all of those questions, but it puts them where the uncertainty is discussable.
Delaying the prototype therefore delays part of the thinking. We spend weeks improving the description of an idea when we could spend an afternoon discovering where the idea is wrong.
The first artifact has become cheap
For most of software history, the prototype gap had an economic explanation.
Turning an idea into software required scarce technical capacity, and even a rough interface might need a designer, a developer, a configured environment and several days of coordination. Words were cheaper, so organizations used them until they were confident enough to pay for code.
That cost structure has changed.
A person or a small team who understands a workflow can now use a general-purpose AI chat product, a UI generator, a coding agent or a local development environment to create a clickable interface, a simulated workflow, a sample report or a small working application. The artifact may be incomplete and technically naive. It can still be sufficient for a user to react to the shape of the idea.
AI adoption data supports the scale of this shift. DORA’s 2025 survey of nearly 5,000 technology professionals found that 90 percent were using AI at work, while more than 80 percent believed it had increased their individual productivity. The research also described AI as an amplifier of the surrounding organizational system, rather than an independent source of better outcomes.
Working with coding agents can reduce the activation energy required to begin, produce a first draft quickly and handle predictable implementation patterns. Complex work in a mature system still demands context, judgment, verification and integration.
The first prototype no longer needs to be treated as a small software project. It can be treated as a temporary instrument for learning. It should use approved tools, synthetic or non-sensitive data and a deliberately narrow scope. It should also be cheap enough to discard.
The prototype’s value is not the code it contains. It is the assumptions it exposes.
Requirements should follow first contact
Traditional requirements work places an unreasonable burden on users by asking them to translate tacit, contextual and often messy work into precise statements about a system they have never used. They may understand the work deeply without being able to predict every interaction, exception and dependency in an interface that exists only as a conversation.
Requirements also do not pass directly from a stakeholder’s head into a document because the people conducting the interview interpret and help create them. In one empirical study, researchers analysed the work of 30 graduate students who conducted requirements interviews with a fictional customer. Most of the students also worked as professional developers or analysts, but the controlled exercise used students as its formal subject population. Only 30 to 38 percent of the resulting user stories contained content that could be fully traced to the customer’s initial ideas. The researchers concluded that the participants were helping construct the requirements, not merely recording them.
A prototype makes that construction visible by giving everyone the same object to challenge.
Instead of asking a stakeholder, “Should the system support configurable approval routing?”, we can show a proposed handoff and watch what happens.
Figure 3. Sharing the prototype gives users somewhere precise to correct the proposed workflow. Illustration generated with GPT Image 2.
The user may say:
- approvals are rare;
- two groups must review in parallel;
- the apparent approval is really a technical assessment;
- the decision depends on data the requester does not have.
That reaction can give the teams something far more useful than agreement with an abstract sentence.
Researchers studying collaboration across different professional groups use the term “boundary object” for an artifact that is adaptable to several viewpoints while retaining enough identity to coordinate work. By analogy, a prototype can play that role between domain experts, users, designers, engineers, data teams and architects. Everyone can challenge the same object rather than defend a private interpretation of a document.
Consider an internal service request.
A conventional requirements exercise might produce fields for the request type, business need, owner, urgency, dependencies and desired outcome. All reasonable.
A first-contact prototype might reveal that different teams use different names for the same service. The requester may understand the outcome they need but not the system or dependency involved. Ownership may shift between intake, assessment and delivery. “Urgent” may mean three different things to the requester, service team and approving manager. A field marked mandatory may ask for information that does not exist until the request has been assessed.
None of those discoveries require a production application. They require a visible workflow that people can attempt to use.
Requirements written after that contact will not be perfect. Perfect requirements do not exist.
They will be materially less fictional.
They can describe what users tried, where they hesitated, which information was unavailable, which exceptions changed the workflow and which assumptions survived contact with the people doing the work.
Requirements should then become a record of learning rather than a wish list.
Before Build, Measure, Learn
In the late 2000s, Eric Ries gave product teams a durable model for operating under uncertainty: Build, Measure, Learn. The method turns ideas into products, measures how customers respond and uses the result to decide whether to pivot or persevere.
The goal of the minimum viable product is to begin validated learning with the least necessary effort. The team creates something, observes how people respond and uses that evidence to decide what should happen next.
Many large organizations never enter that loop.
They remain in an unofficial stage that comes before Build: permission.
They explain, align, estimate, prioritize and fund. They attempt to remove uncertainty before making the object that would reveal the uncertainty.
The resulting sequence often looks like this:
Idea → deck → alignment → estimate → funding → backlog → build → first meaningful reaction
A learning-first sequence looks different:
Idea → learning question → rough prototype → reaction → revised workflow → requirements → engineered product
Some of these prototypes may eventually become an MVP. Others are pre-MVP experiments. Their purpose is to test whether the proposed workflow, interaction or value proposition deserves a product at all.
The prototype gap is the missing prequel to Build, Measure, Learn. It is the hesitation before the learning loop begins.
Lean Startup taught us to learn faster once building starts. GenAI allows more people to start learning before a formal delivery project exists.
This changes the role of alignment as well. Teams usually try to align before building.
A lightweight prototype allows them to build enough for alignment to be grounded in evidence.
People can disagree about something visible. They can identify the precise point of disagreement. They can compare alternatives. They can watch a user perform the task.
That is a better form of alignment than unanimous approval of a sentence broad enough to support five different interpretations.
The learning question must remain explicit. Without it, rapid prototyping can become another form of theatre.
A prototype designed to impress will accumulate polish. A prototype designed to teach will focus on the smallest uncertain decision.
What are we trying to learn?
- Can the user complete this workflow without asking for help?
- Does this view contain enough information to make the decision?
- Are these categories meaningful to the people who produce the data?
- Will the handoff work inside the real process?
Cheap to try, expensive to trust
A convincing prototype creates its own risk.
Because the interface looks real, people assume the system is nearly finished. A functioning button can conceal missing authorization, incomplete business rules, hard-coded data, absent error handling and an integration that has never been attempted.
That misunderstanding has become more common as AI-generated interfaces improve.
A production system carries obligations that a learning prototype does not. It must handle identity, data contracts, business logic, security, performance, observability, failure recovery, deployment, support and long-term maintenance. It must work beyond the narrow path used in the demonstration.
DORA’s research describes this as a workflow gap. AI can make the initial prototype arrive quickly, while precision, edge cases, verification and integration consume much of the remaining effort. Higher AI adoption can increase delivery throughput while also increasing instability when the surrounding engineering practices are weak.
The prototype reduces product ambiguity. It does not remove technical complexity.
That is why this approach does not diminish the role of engineers. It gives them a better starting point.
Domain experts can help make the desired experience tangible. Users can validate the workflow. Product teams can identify which decisions matter. Engineers can then concentrate on whether the idea can operate safely and reliably within the real environment.
They still have to write the difficult logic.
They still have to connect the backend.
They still have to understand the data, model the exceptions, choose the architecture and make the system maintainable.
The difference is that they begin with requirements shaped by contact rather than speculation.
The form of the prototype should also match the uncertainty. A visual interface works when the risk concerns interaction or workflow. For a data-heavy product, the first prototype might be a sample data contract, a simulated pipeline or a set of expected outputs. For a service or operating process, it might be a storyboard or a role-play. For an AI system, it may be a small evaluation set and a manually operated version of the proposed experience.
Polished screens are useless when the real uncertainty sits in data availability, model behavior or system integration.
Engineers should enter early where technical feasibility is itself the risky assumption. They should challenge the prototype before its visible choices harden into accidental architecture. That can happen without requiring a fully staffed project before anyone is allowed to explore the idea.
Figure 4. An engineer can test the risky assumptions while the prototype’s visible choices are still easy to change. Illustration generated with GPT Image 2.
A different rhythm of work
- Start each idea with a learning question.
- Create the cheapest artifact that allows someone to act, decide or react.
- Use realistic examples and synthetic data. Mark the prototype clearly as non-production. Give it an expiry date.
- Put it in front of people who perform the work. Watch where they pause, disagree, ask for missing information or invent a workaround.
- Revise the workflow. Remove the parts that do not matter. Document the assumptions that remain untested.
- Then write the requirements.
- Then decide whether the idea deserves real engineering.
The sequence becomes:
Question → Artifact → Contact → Learning → Requirements → Engineering
The first artifact should arrive while the idea is still easy to change. That is when criticism is cheapest and curiosity is still stronger than commitment.
This approach has little to do with reckless speed. Early work and late work require different disciplines. Early work should be rough, reversible and explicit about what it is trying to learn. Late work should be secure, reliable and engineered for its actual environment.
Confusing those stages creates two common failures. Teams either burden early exploration with delivery machinery, or they allow experimental code to drift into production.
Stage-appropriate seriousness avoids both.
The deeper organizational effect of AI may be that it gives us a new medium for thought. It lowers the cost of admitting, “We do not know yet,” because we can make something that helps us find out.
With agentic AI, the first prototype has become so cheap that the bottleneck has moved. It now sits in permission: permission to create a first version before certainty has been performed.
The next time someone says, “We should build a tool for this,” do not begin with the complete requirements.
- Ask what can be made visible this week.
- Ask which uncertainty the artifact should expose.
- Ask who needs to react to it.
Build that much. Observe what happens. Then write the requirements and bring in the engineering team.
They will begin from a shared experience instead of five different systems hiding behind the same sentence.