Pick the riskiest assumption.
The prototype exists to test the assumption that would most change the plan if it failed.
01Context
Learning before launch-readiness.
Iterate is controlled improvisation. I want the product to become tangible quickly, but only around the question that matters. If the unknown is whether a user can feel the core value, the prototype should answer that directly instead of pretending to be a finished system.
That means using hardcoded paths, fake data, narrow flows, or disposable implementation when those choices protect learning speed. The discipline is to write down what changed, what was learned, and what still should not be trusted.
02Model
The learning loop before launch-readiness.
The model is the part of the article where the idea becomes usable: a sequence of decisions, artifacts, or checks that can guide real product work.
Use fake plumbing when plumbing is not the question.
Hardcoded data, a single page, or a manual workflow can be correct when the goal is to feel the core interaction.
Write down what changed.
The learning log preserves what worked, what broke, what should be rebuilt, and what should not survive into production.
The model moves from question to artifact to evidence.
- QuestionPick the riskiest assumption.
- ShortcutUse fake plumbing when plumbing is not the question.
- LearnWrite down what changed.
03Speed with judgment
Iterate protects speed from becoming theater.
AI makes it easy to generate screens, but screens are not learning unless they answer an actual product question.
The stage works because it constrains the build: one core feature, just enough interface, and clear notes about what is fake or temporary.
A useful iteration is a bounded slice: preserve a runnable product, avoid unrelated changes, keep risky operations idempotent, put domain rules in shared places, keep sensitive checks on the server, and update the source of truth when behavior changes.
04Case use
Different products need different prototypes.
For a payment product, the riskiest proof might be contribution trust. For a data product, it might be whether the analysis becomes decision-grade. For a creative tool, it might be output quality and editing control.
The verification path should increase realism in layers: static checks, rule checks, integration tests, visual checks, preview with realistic configuration, provider test events when needed, and finally narrow production smoke checks.
After each slice, the question becomes whether the learning is local or systemic. A one-off fix is right when the behavior is truly product-specific; a reusable rule is right when the same failure can appear across surfaces.
Prototype the riskiest assumption, not always the entire core feature.
From this essay05Artifacts
What this leaves behind.
I use artifacts as evidence of thinking. They make product judgment reviewable, reusable, and easier to connect back to the work.
Working prototype
A narrow build that demonstrates the core path enough for judgment, feedback, or technical learning.
Hardcoded path
A deliberate shortcut that makes the learning loop faster without hiding the shortcut.
Interaction proof
A visible flow that shows whether the user can feel the intended value.
Learning log
The record of what to keep, discard, rebuild, or validate next.