The prototype is the spec now.

There is a version of the product review meeting that most teams know too well.

The PM walks in with a PRD. The doc is thorough: context, goals, personas, user stories, acceptance criteria, edge cases, dependencies, open questions, and a few diagrams that looked better in the tool where they were created. Everyone reads some of it. Nobody reads all of it.

The discussion starts at the right altitude for ten minutes. Then it drifts.

One stakeholder argues about a requirement they understood differently. Design clarifies a flow. Engineering asks if the system really needs to support the edge case in section 6.3. Someone suggests the current version is "fine for now" and asks to capture follow-ups in a next steps slide.

The meeting ends with alignment. Or at least the kind of alignment that looks fine in a meeting recap.

Then engineering starts building. A few weeks later, the team sees the first real version. Suddenly the misunderstandings are no longer theoretical. The product behaves in a way that someone did not expect. A workflow that made sense in the document feels strange in practice. The team was aligned on the words, but not on the thing.

That used to be normal.

It does not have to be normal anymore.

The cost curve collapsed

The cost of producing an interactive artifact has collapsed.

A product manager with senior judgment can now build a clickable, software-shaped prototype during discovery. Not a static wireframe. Not a deck with screenshots. A thing that runs. It can have states, flows, sample data, fake authentication, conditional paths, and enough UI behavior to expose whether the idea survives contact with use.

This matters because product work has always had an alignment problem. The more abstract the artifact, the more interpretation it requires. A PRD can be precise and still fail to create shared understanding because humans don't experience software as prose. They experience it as a sequence of actions, interruptions, states, errors, and moments of recognition or confusion.

When the team can click the intended experience before engineering commits real capacity, the prototype becomes the primary alignment artifact.

The PRD stops carrying the full burden of describing visible behavior. Its job gets smaller, sharper, and more important.

The prototype shows what the product is supposed to feel like.

The PRD documents what the prototype cannot safely prove.

That distinction is the whole shift.

The old order

For a long time, the common product sequence looked roughly like this:

1. Discovery.
2. PRD.
3. Design.
4. Engineering.
5. Review.
6. Rework.
7. Ship.

The PRD sat near the center because it had to. It was the artifact that tried to hold the product together before the product existed. It described the user, the problem, the requirements, the desired behavior, the dependencies, the tradeoffs, and the acceptance criteria.

That made sense when building a believable prototype took a designer, a front-end engineer, a meaningful chunk of time, and a lot of coordination. The written spec carried the load because the alternative was expensive.

But that constraint has changed.

Modern prototyping tools, design systems, front-end frameworks, and AI-assisted development have made it possible to build a working representation of the idea much earlier. Not production-ready. Not architecturally clean. Not safe to ship. But real enough to click.

Once that is true, the old order starts to look strange.

Why should the team argue for three weeks about what the workflow might mean when a senior PM can build a rough version in two days and let people react to the thing itself?

Why should engineering discover interaction ambiguity after sprint planning when the ambiguity can be exposed during discovery?

Why should stakeholders bless a document when what they actually care about is the experience?

The answer is usually habit.

The reorder

Once a prototype exists by the time the PRD is reviewed, the artifact hierarchy changes. The PRD no longer sits at the center. The prototype does.

The prototype becomes the source of truth for visible behavior. It shows the intended flow and the interaction model. It shows the happy path, the obvious branches, and the places where the user has to make a choice. It lets the team feel the difference between a workflow that sounds clean and one that actually moves.

The PRD becomes the annotation layer.

This is not a demotion. It is a correction.

The PRD should stop trying to carry what a prototype shows better. It should carry what the prototype cannot show reliably:

• Business rules: Eligibility logic, thresholds, and exception handling.
• System dependencies: API requirements, data contracts, vendor constraints, and integration boundaries.
• Permissions: Role-based access, privacy considerations, and audit requirements.
• Instrumentation: Analytics events, reporting needs, success metrics, and experiment design.
• Operational handoffs: Support paths, escalation logic, compliance constraints, and human review points.
• Non-functional requirements: Performance, availability, maintainability, security, and ownership.

The prototype shows the believable paths. The PRD documents the dangerous paths.

The old PRD tried to be both the movie and the contract. The new PRD can be the contract because the prototype is the movie.

Specific disagreement is progress

Disagreement is not the enemy. Late disagreement is the enemy.

If a stakeholder hates the workflow on day three of discovery, that is useful. If engineering says a simple-looking step crosses three legacy systems, that is useful. If customer support sees the prototype and points out that the proposed flow creates a new escalation queue, that is useful.

A clickable product has to survive the click.

A deck can glide past an unresolved dependency with a clean diagram. A prototype cannot. Eventually someone clicks into the missing step. They ask where the data comes from. They ask why the flow needs a login. They ask what happens if the customer is not eligible. They ask whether the "submit" button creates a ticket, sends an email, calls an API, or just makes everyone feel better for a moment.

Those questions are the work.

A prototype makes the work visible earlier.

This change also resets the engineering partnership. Engineering teams are often asked to build from text that leaves too much room for interpretation. A prototype reduces that burden. Engineering can see what the PM thinks the user is supposed to do. They can challenge the flow earlier.

"This part looks simple, but it crosses three legacy systems."

"This state needs an owner. Who clears it?"

"The API doesn't return that field. Is that a requirement or sample data?"

"This can work, but not if the SLA is real-time."

That is a better conversation than waiting for review cycles to expose a mismatch after code is written.

The prototype forces tradeoffs

A written spec can keep too many options alive. That can be useful early. It becomes dangerous late.

A prototype is less patient with unresolved choices. It forces the team to pick a path, even if the path is temporary. Where does the user start? What does the primary action say? What happens after submission? What information is visible? What is hidden? What does the system do when something is missing?

These choices may seem tactical. They are not.

Product strategy often hides inside small interaction decisions. A button label can reveal whether the product is promising information, action, or commitment. A loading state can reveal whether the system is synchronous or asynchronous. A review step can reveal whether the business trusts automation or needs human control. A required field can reveal whether the team understands the data reality or is inventing a clean world that operations will have to fake later.

The prototype makes these assumptions visible.

That does not mean every assumption gets resolved immediately. It means they stop hiding.

In practice

The value of a prototype-led discovery is not that the prototype looked impressive. It probably did not. Most useful prototypes are ugly in places. They have fake data, narrow paths, and rough edges that would make a production engineer twitch.

The value is that the prototype creates a better argument.

Instead of debating whether the requirement was clear, the team can debate the behavior. Instead of asking whether the workflow was "intuitive," they can watch where the user stopped. Instead of treating engineering concerns as late-stage implementation details, they can attach those concerns to specific screens, states, and data needs.

That is the difference between a prototype as decoration and a prototype as a spec.

Decoration says, "Here is what it could look like."

A spec says, "Here is what we think should happen. Now let's find out where we're wrong."

The traps

A prototype is not a product. It can clarify a decision, but it does not make the production system simpler.

Modern tools can get a team to a believable 80 percent very quickly. The last 20 percent of a production system might take a year. That gap is not a failure. It is the difference between demonstrating intent and operating at scale.

The PM has to be honest about what the prototype proves. It might prove that the user understands the flow. It might prove that the internal team agrees on the experience. It might prove that a stakeholder's favorite idea becomes awkward when clicked.

It probably does not prove that the integration is easy. It does not prove that the data exists in the right shape. It does not prove that compliance will approve the workflow. It does not prove that operations can support the exception path. It does not prove that the production team should inherit the prototype code.

"It works" is not the same as "we can own it."

Prototype code optimizes for "see it work." Production code optimizes for "keep it working." PMs must respect the difference between proving a decision and proving an implementation. When that line gets blurry, teams either over-trust the prototype or under-value engineering. Both are bad.

Over-trusting the prototype creates magical thinking. The demo works, so the build must be close. The screen renders, so the data must exist. The workflow moves, so the org must be ready.

Under-valuing engineering creates a different problem. The PM shows a prototype and treats legitimate implementation concerns as resistance. That is amateur hour. A senior PM uses the prototype to make engineering concerns more specific, not to bulldoze them.

The prototype is a discovery instrument. It is not a way to bypass the people who know how production systems fail.

The PM's craft changes

The PM's craft moves from describing the thing well to building enough of the thing that the spec can be committed.

That does not mean every PM needs to become a production engineer. It does mean the bar for artifact quality is changing. A senior PM should be able to move an idea out of abstraction earlier. They should be able to turn a fuzzy workflow into a clickable path, even if the prototype is built with low-code tools, AI-assisted code, a design system, or a rough React app with fake data.

The craft is not the tool. The craft is judgment.

What is the smallest prototype that exposes the decision?

What can be faked safely?

What must not be faked because faking it would hide the real risk?

Where does the prototype need sample data, and where would sample data create a lie?

Which path needs to be clickable, and which path only needs to be documented?

A junior prototype tries to impress. A senior prototype tries to learn.

That distinction matters. The goal is not to create a polished demo that makes everyone feel good. The goal is to create a useful artifact that makes the right disagreement happen early.

Discovery with teeth

In a TMB-style discovery engagement, the output should be a working prototype plus a focused PRD.

The prototype carries the experience. The PRD carries the risk. Together, they support a real decision: build, kill, or redirect.

A useful discovery cycle runs in loops:

1. Frame the decision: What are we trying to learn?
2. Prototype the surface: Build the smallest version that exposes the decision.
3. Test the artifact: Put it in front of users, operators, and engineering early.
4. Document the risk: Capture what the prototype cannot prove.
5. Decide: Use the evidence to commit, kill, or redirect.

The point is not to leave behind a beautiful demo. The point is to leave behind a decision the team can defend.

That is also where the distinction between diagnostic and discovery work matters.

A diagnostic engagement may end with a decision memo and no prototype. The question may be about viability, ownership, vendor fit, or whether the organization should proceed at all.

A discovery sprint goes one step closer to the product. It should produce a working artifact that lets the team test behavior, not just assumptions.

Both are decision-oriented. They just operate at different altitudes.

The point

The best teams will not stop writing specs. They will stop pretending the spec has to be the first real artifact.

Written requirements still matter. Business rules still matter. Acceptance criteria still matter. Data contracts, permissions, analytics, support paths, and operational constraints matter even more once the prototype makes the surface look easy.

But the center of gravity has moved.

Engineering aligns to what it can see and run, not to what is described. Stakeholders react more honestly to a product-shaped artifact than to a tidy paragraph. Users reveal more when they click than when they are asked to imagine.

The prototype does not replace product judgment. It exposes whether that judgment is ready to be committed.

That is why the prototype is the spec now.