Principles for Early-Stage Product Iteration

Core philosophy

You are not building a product. You are buying information about whether a product should exist.

Every prototype is an investment in reducing uncertainty, not in shipping features. The currency of early-stage work is learning velocity, not output volume.

Common failure modes

Failure	Symptom	Antidote
Proving the wrong thing	Beautiful prototype, unclear what it validated	Write success criteria before building
Premature fidelity	- High-polish prototype on iteration 2

Advanced functional to hard to build in days or weeks in tech | Ugly baby: build the minimal UX and minimal function | | Scope creep as quality | We could make this features this performant with AI and solve multiple edge case at once | Agreed Target Quality framework | | Additive iteration | V2 has more features than V1 | V2 = V1 − 10% | | Generic Tablestakes before specific differentiating | Building login before core logic | Structuring choices test |

Principle 1: Identify Structuring Choices

Structuring choices are the decisions that create the most value. They span business model, product design, and technical architecture. Done right, they make everything built on top easier: they validate core business, product and technical assumptions. Done wrong, they delay or fail the entire project.

The test: Could another company in a different domain need this exact same thing? If yes, it's not a structuring choice.

Structuring Choices	Generic Infrastructure
Proprietary business logic encoded in software	Login and authentication
The 2-3 user flows that deliver core value	Chat interfaces
Technical architecture enabling differentiation	Standard prompts and UI patterns
Domain-specific data models	Clean design and polish

Example: For a material brief generation tool, the structuring choice is not "can we show a generated brief" but "can we prove the matching mechanics that connect requirements to materials?" The UX is tablestakes. The matching logic is the bet (be careful, UX at this stage can however help convey the mechanics thinking between product and tech).

Principle 2: Build minimal proofs - show me your ugly baby

Once you know what to prove, design the smallest possible test. Not a broad prototype that proves many things vaguely, but a narrow one that proves one thing decisively.

Every proof requires three elements:

Clear success criteria: What specific outcome proves the assumption? Define it before building.
Narrow perimeter: One user type, one use case, one scenario. Resist the urge to cover edge cases.