I gave a talk at Config a few years ago called Prototype the Path. It was about Slack's product principles, and this one mattered to me because it's something I had long cared deeply about.
You see, throughout my career I've been obsessed with the art of prototyping, and specifically how to close the gap between the idea in the designer's mind, and the coded expression via the engineer's hand. At Adobe I built tools to do this. At Google I attempted to make this a reality. Uber and Airbnb came close. But it was at Slack where the dream became a reality.
The difference wasn't that people cared more. Plenty of teams care. It wasn't that Slack had better taste in some vague cultural sense, though the taste was real. The difference was more practical: Slack teams had a deep bias toward making the thing real enough to experience before deciding what it was.
We didn't presume that we were smart enough to predict, from static images or written briefs, what something would feel like in use. Slack was a living product, used by teams in thousands of contexts we couldn't fully imagine. A paragraph could describe an idea. A Figma mock could make it visible. A prototype could make it tangible, something the entire team could touch, feel, and use. Something we could gather around and use to center our debates.
When a team argues over a written brief, everyone is often arguing with a different imagined product in their head. When a team argues over a static mock, the argument improves, but the real experience is still missing. How does it load? What happens after the first click? What does it feel like on the fifth use? What does the empty state do to your confidence? Where does the user hesitate? What does the product ask of the person when they're busy, distracted, or under pressure?
Those questions don't answer themselves in a deck. They answer themselves when the thing is alive, in a prototype.
A Prototype Is A Question
The first principle is simple: a prototype is a question.
A prototype should begin with a hypothesis. We think this navigation model will make the product feel calmer. We think putting voice in this moment will change the emotional tenor of the interaction. We think this AI workflow needs live data before anyone can judge whether it works. We think this concept will fail, but we need to know why.
At Slack, we would sometimes spend real engineering and design energy building directions we suspected wouldn't survive. That sounds wasteful if you think the goal of prototyping is to validate the team's first idea. It makes sense if you think the goal is to explore the terrain.
Each prototype gets you to the next hill. From there, you can see something you couldn't see before. Sometimes you learn that the original idea was wrong. Sometimes you learn that it was right, but for different reasons. Sometimes you go in a circle and end up back where you started, except now the team has a much clearer map of the surrounding territory.
That process can be tiring. It asks engineers to write code they may throw away. It asks designers to detach from artifacts that took real effort. It asks product managers to keep changing the question as the evidence changes. But it creates a kind of shared knowledge that a spec can't produce.
At Slack, we called one version of this "tasting the soup." On a major information architecture change, the team built multiple live versions of Slack. We worked in them for about two weeks. We didn't just review the product. We lived inside the alternatives. Then we talked about what needed more salt, what needed less pepper, and which direction deserved to keep going.
That kind of decision has a different texture. It isn't abstract preference. It's lived judgment.
The Old Truth
The reality is that none of this is new.
Bill Buxton has been making this argument for decades through Sketching User Experiences (which, by the way, is one of the best books on design). His line between sketch and prototype is useful because it separates purpose from fidelity. A sketch asks. A prototype tests. The medium can be paper, wood, code, animation, a hardware rig, or a rough build on a phone. The point is to create the right kind of artifact for the stage of thought.
Buxton's PalmPilot (old school!) example still holds up. The first prototype was a block of wood cut to fit in a pocket and hand. Could it be carried? Could it be held? Could someone write on it? Before the team built the device, they needed to experience the premise.
Software teams forget this because software can make the wrong thing look finished. A polished mock has the confidence of an answer, even when the team is still asking the first question. A beautiful deck can hide the fact that nobody has felt the interaction yet.
Good prototyping restores the humility of the work.
It admits that design is a squiggly line. You don't move from brief to mock to build in a clean sequence unless the problem is already understood. The more original the product, the less likely that sequence is to work. The team has to move sideways, backwards, and around the edge of the probable. The mess is part of the method.
Apple's product culture, as Ken Kocienda describes it in Creative Selection, was built around this same truth. Ideas became demos. Demos went in front of people. The best versions survived criticism, taste, and repeated use. The iPhone keyboard couldn't have been solved as a static design. It needed to be typed on. The team needed to feel what happened when your finger hit glass, when autocorrect intervened, when the keyboard guessed wrong, when speed and confidence started to compound.
The Apple lesson is often misread as secrecy plus taste plus Steve Jobs. The more useful lesson is that taste had a medium. It showed up through concrete demos. The idea had to become real enough for people to react to it, criticize it, improve it, and kill it.
The best software cultures have always worked this way. The difference now is that the cost structure changed.
The Skill Gap Was The Constraint
For most of software history, prototyping was obviously right and operationally hard.
Designers could see the experience but often couldn't build it. Engineers could build it but were punished, formally or informally, for expensive code that didn't ship. Product managers could frame the question but had to route through other functions to make the question testable. Each function held part of the work. No function held the whole loop.
That created the process most companies normalized: PRD, design, review, handoff, build, QA, release. It wasn't irrational. It was a response to scarcity. Production was expensive, so companies tried to make every handoff more complete before the next team spent time on it.
The problem is that software quality rarely comes from perfect handoffs. It comes from the interaction between people who can see different risks at the same time.
Design sees desirability. What does this feel like? Does it make sense? Does it carry the right emotional weight? Does it respect the person using it?
Product sees value. Why should this exist? Which problem is worth solving? What tradeoff are we making? What customer or business truth gives the work its shape?
Engineering sees reliability. Can this hold? What will break? What is cheap in a demo and expensive at scale? What system are we committing ourselves to?
The best teams bring those questions into the same artifact as early as possible. That was always the dream. The tools just didn't make it easy.
The New Era
AI changes the operating model because it lowers the cost of crossing the boundary.
Designers can make working prototypes without waiting for a front-end engineer. Product managers can make a rough version of an idea before asking design to polish it. Engineers can explore interaction patterns without learning every corner of Figma. Agents can scaffold code, wire up data, and generate variants fast enough that the artifact becomes conversational.
This doesn't make the functions disappear. It changes what each function is responsible for.
DoorDash's recent case study is one of the clearest examples. Two teams, one working on an AI-native restaurant discovery app and another working inside the core consumer app, independently arrived at a prototype-first process. Their designers wrote code. PMs started from prototypes. Engineers helped wire live data into exploratory artifacts. DoorDash's internal Starter Dough repo gave teams a shared starting point for realistic prototypes.
The most interesting part of the DoorDash story isn't that everyone can build. It's that judgment became more explicit once building got easier.
DoorDash names three kinds of prototypes. Exploration prototypes are disposable. Production prototypes are built on real systems and can be hardened. The messy middle is the danger zone: prototypes that look real, carry fake assumptions, and quietly confuse the team about whether they're learning or shipping.
That's the new discipline. When making gets cheap, intent has to get sharper.
A team should say which kind of prototype it's making before it starts. Is this a sketch in code? Is this a production slice? Is this a disposable test of a risky behavior? Are we trying to learn, persuade, measure, or ship?
Without that clarity, the team falls into the speed trap. Every comment becomes a task. Every plausible direction gets one more iteration. The prototype stops being a question and becomes a magnet for reaction.
The fix is lightweight governance. Name the decision owner. Batch feedback. Keep the hypothesis visible. Decide when to throw away the code. Decide when the answer is good enough to rebuild properly.
What Jenny Sees
Jenny Wen, who leads design for Claude and previously led design at Figma, describes the same shift from inside an AI-native product team. The old design process is breaking because engineering itself is changing. Engineers are spinning up agents. PMs and engineers can create prototypes. Designers don't have the same amount of time to make beautiful mocks before the product starts moving.
Her work has changed accordingly. Less time spent making mocks as the primary artifact. More time pairing with engineers, giving feedback on live builds, polishing in code, and helping the team decide what should actually ship.
This is especially true for AI products. You can't mock every state of a nondeterministic system. You can't fully understand an AI workflow through static screens. You need the model, the data, the prompts, the latency, the failure modes, and the user's actual behavior. The prototype has to contain the material.
This last point is critical, so it bears repeating: the prototype has to contain the material.
For a consumer app, the material may be motion, touch, loading, and repeat use. For AI software, it's model behavior. For collaboration software, it's the social context of a team. For financial software, it's trust, comprehension, and the consequences of getting it wrong. If the prototype doesn't contain the material, the team is probably judging a representation of the problem rather than the problem itself.
This is why prototyping is becoming more central. The software is getting more dynamic. The path can't be fully described before you walk it.
Principles For The New Prototype Culture
The new era needs old discipline with new tools.
Start with a hypothesis. A prototype without a question becomes a demo. Demos can inspire, but they don't always teach. Name what you need to learn.
Build fast and throw away freely. Disposable work is only wasteful when the team pretends it's permanent. Throwing away code is part of the economics of learning. With today's tools and models this becomes increasingly easy.
Use prototypes to create shared judgment. The artifact should let design, product, and engineering argue about the same thing. That is the point.
Name the decision owner. When everyone can build, direction becomes the scarce resource. Someone has to call the next hill.
Protect the squiggly line. Fast tools can make teams converge too early. Great prototyping includes divergent paths, wrong turns, and strange builds that teach the team why the obvious answer is wrong.
Rebuild when the answer is clear. Quick and dirty is a learning strategy. It isn't an excuse to ship weak foundations. When the prototype answers the question, take the time to do it right.
Don't ship slop. With today's AI tools, it's easier than ever to spin up something that seems good but is, in reality, mediocre at best. Take the time to craft a truly exceptional experience.
These principles sound basic because the best product principles usually do. The hard part is making the incentives match. Engineers need credit for learning as much as shipping. Designers need comfort in code alongside control in Figma. PMs need to frame questions that can be tested before documents get approved.
The org has to reward the loop.
What Changes Now
The next generation of great software teams will look less like assembly lines and more like studios.
Small groups of people with different expertise will work inside shared artifacts. The designer will prototype. The engineer will make product calls. The PM will build a rough version to clarify a strategy. The AI agent will sit in the middle, turning intent into material quickly enough that the team can spend more time judging the result.
This will feel uncomfortable for organizations built around clean lanes. Some people will hear this as a threat to their craft. I think the opposite is true. Craft matters more when production gets cheaper, because the team can produce far more plausible work than it can responsibly ship.
The scarce skill is no longer making one version. The scarce skill is knowing which version deserves to exist.
That is why prototyping matters more in the AI era. It gives judgment a surface. It turns debate into contact with the material. It lets the team learn from the product before the market has to.
Prototype the path was never a slogan about speed. It was a statement of humility. We don't know enough at the start. We learn by making. We test the idea against reality. We move to the next hill.
Software has always been better when built this way.
Now more people can participate in the loop.
That is the new era.
Source Notes
- Ethan Eismann, Prototyping the path: how Slack builds product with customer love, Config 2023.
- Bill Buxton, Sketching User Experiences with Bill Buxton, RAIC Centre for Architecture at Athabasca University.
- Jenny Wen, The design process is dead. Here's what's replacing it., Lenny's Podcast.
- DoorDash Design, Two Teams, One Shift: How AI Is Rewiring Our Product Design Process.
- Ken Kocienda, Creative Selection, plus summaries of the book's account of Apple's demo-driven product culture.