Throwaway Prototyping To Discover The Product
Build disposable prototypes on real data to feel what works before writing any production code.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 88%
Yehoshua's lesson from Stuart Butterfield: a mockup can't tell you how a product will feel, so you must build and try it. The method depends on an engineering stack and mindset built for disposable code—engineers who happily write things that will never ship, plus deliberately extreme prototypes that strip the interface bare to reveal what's actually essential.
Origin
Attributed to Stuart Butterfield (co-founder/CEO of Slack), who Yehoshua calls the best product thinker in the valley; she implemented it with design lead Ethan Eidenberg on the Slack redesign.
Core principles
- 01A mockup doesn't tell you what a product is going to feel like—you have to build it and feel it.
- 02Done right, prototyping is faster, not slower, because you reach the working end-goal sooner.
- 03Prototyping requires a tech stack with a layer of abstraction that makes it easy, plus engineers with a throwaway-code mindset.
- 04Product, engineering, and design must share the prototyping mindset—design is in it as much as engineering.
- 05Extreme, deliberately-unshippable prototypes surface what you truly need in the interface.
How to run it
- 1
Build the prototyping infrastructure
Ensure your engineering stack has a layer of abstraction light enough to prototype quickly. If a surface (e.g. mobile) is too heavy to prototype, redesign it until prototyping is easy.
Pro tip Hire dedicated prototypers or design-engineers—one Google front-end lead called his prototyper hires 'my secret weapon' for moving faster.
Watch out Some engineering infrastructures are too heavy and actively prevent prototyping; that's a problem to fix, not tolerate.
- 2
Write code you'll throw away
Have engineers write code they know will never reach production, so they can crank it out much faster and see what works before investing in production code.
Pro tip Start with figma prototypes, then move to prototypes running on real data for the honest feel.
- 3
Run the extreme version to find the essentials
Deliberately over-strip the design to expose what's actually needed. Butterfield told the team to put everything in the interface behind one button—not to ship, but to reveal what really needed to be visible.
Pro tip Push past 'that will never work' objections; the extreme prototype is a discovery tool, not the shipping plan.
Watch out Don't confuse the discovery prototype with the final product—it was never going to ship; it was the beginning of the redesign.
- 4
Build the production version
Once you've felt what works, build the real production code toward the validated end goal.
In the wild
For the Slack redesign, Butterfield told design lead Ethan and the front-end prototypers to take everything in the interface and put it behind a single button. Everyone said it would never work; he insisted 'do it, just do it.' It was never meant to ship—it was a way to see what the interface truly needed.
→ The exercise became the beginning of the new Slack architecture and redesign.
Is it for you?
Best for
Product and design leaders shaping a new product or a major redesign where the feel matters more than the spec
Not ideal for
Small incremental feature tweaks where a mockup already conveys the experience and throwaway code is overhead
From the transcript
“a mockup doesn't tell you what it's going to feel like”
“you write code that you know is never going to make it to production so you can get you can just crank it out much…”
“I want you to take everything in the interface and put it behind one button”
“this is how you're going to see what you really need in the interface”
From the episode
Lessons in product leadership and AI strategy from Glean, Google, Amazon, and Slack
Tamar Yehoshua (Product at Glean, ex-Google and Slack)