Software implementation always teaches us something. Real systems expose edge cases. Real users behave differently from workshop assumptions. Performance characteristics become measurable. Integrations reveal constraints that documentation did not make obvious.
The mistake is not learning during implementation.
The mistake is using implementation as the first place to discover basic facts about the product.
When teams begin building before they understand the problem, actors, domain concepts, constraints, workflows and required capabilities, code becomes a discovery instrument. It is a very expensive one.
Unknowns Are Not All Equal
Every product begins with uncertainty, but teams often treat all uncertainty as if it deserves the same response.
Some questions are cheap to answer:
- Who performs this action?
- What information do they need?
- Which system is authoritative?
- What happens when a request is rejected?
- Can a child perform the same action as a guardian?
- Does a record represent current state or historical state?
Other questions genuinely require implementation:
- Can this algorithm meet the latency target on real workload?
- Will a vendor API behave reliably under production concurrency?
- Does the chosen storage model remain economical at scale?
- What failure modes appear only under distributed execution?
The first group should rarely require production code. The second often does.
Good product formation reduces the first category before expensive engineering commitments begin.
Code Hardens Assumptions
An assumption in a document is cheap to change.
An assumption embedded in code is not.
Once an idea becomes database schema, authorization logic, API contracts, event formats, analytics pipelines, tests and UI flows, changing the idea means changing a system.
Consider a simple modeling mistake:
A student belongs to one school.
That statement may look harmless during early implementation. Then the team discovers that students change schools, may be linked to historical institutions, can participate independently of a school, or need records that outlive their current enrollment.
The assumption is no longer a sentence. It may exist in foreign keys, queries, access rules, reporting logic and user flows.
The cost of correcting the product model has become architecture work.
Premature Backlogs Create False Certainty
A common failure mode is to convert an early idea directly into a backlog.
The backlog becomes detailed enough to look executable:
Epic
→ Feature
→ Story
→ Acceptance criteria
But detail is not understanding.
A backlog can contain hundreds of precise statements built on the wrong domain model. It can create the organizational impression that discovery is complete because implementation tasks exist.
This is dangerous because teams become psychologically invested in the artifact. Questions that should change the model are reframed as "scope changes." Evidence becomes an interruption to delivery rather than the purpose of early product work.
A better sequence is closer to:
Problem
↓
Actors and context
↓
Domain and constraints
↓
Capabilities
↓
Critical workflows
↓
Risks and assumptions
↓
Evidence
↓
Architecture implications
↓
Delivery slices
The backlog arrives later, when it can represent a product that is sufficiently understood to build.
Discovery Is Risk Reduction
Product discovery is sometimes reduced to user interviews or UX testing. Those are important, but the deeper purpose is to reduce the important uncertainties before committing the full cost of delivery.
SVPG frames product discovery around value, usability, feasibility and viability risk. The usefulness of that model is not the taxonomy itself. It is the discipline of asking what could make the idea fail before investing heavily in implementation.
Evidence needs depend on the risk.
A reversible internal workflow change may justify a low-cost test and quick implementation. A new identity model, regulated data flow or externally visible contract deserves stronger evidence because reversal is expensive.
The point is not to eliminate uncertainty. That is impossible.
The point is to avoid spending engineering effort to answer questions that could have been answered more cheaply.
Prototypes and Production Code Serve Different Learning Goals
Prototypes are useful because they allow teams to be intentionally incomplete.
A prototype can test whether a workflow makes sense without implementing the full authorization model. It can test user comprehension without production-grade observability. It can validate an integration with a throwaway adapter before the interface becomes a permanent boundary.
Production implementation has different obligations:
- security;
- maintainability;
- observability;
- failure handling;
- performance;
- supportability;
- data integrity;
- migration;
- operational ownership.
Using production code for early concept learning means paying for those obligations before the idea has earned them.
That is why fast discovery techniques are economically important. They create evidence without prematurely creating long-lived system state.
Domain Discovery Is Often the Missing Layer
Teams can have strong UX discovery and still misunderstand the product because the domain underneath the interface is unclear.
Imagine a procurement workflow that appears simple in UI:
- create a request;
- invite suppliers;
- receive proposals;
- choose a winner.
Underneath that flow are domain questions:
- Can suppliers offer partial quantities?
- Can price vary by delivery date?
- Is freight separate?
- Can the buyer split an award across suppliers?
- What happens when a supplier revises a proposal before the deadline?
- Is the "best" bid lowest price or lowest total landed cost?
- Which terms are comparable and which require judgment?
- What becomes contractually binding?
A polished screen can conceal these questions. Implementation eventually exposes them, usually after data and workflow choices have already been made.
This is why Capabilities Before Screens matters. The interface should express a domain and capability model, not substitute for one.
Architecture Debt Can Begin as Product Uncertainty
Technical debt is often described as an engineering consequence. Some of it begins much earlier.
When the product is unclear, engineering has to invent missing rules.
Developers choose a data model because no one has defined historical behavior. They make an integration synchronous because failure semantics are unknown. They give a role broad permissions because authorization boundaries have not been explored. They encode state transitions directly into UI logic because the workflow has not been modeled.
The code works, but architecture is now carrying unresolved product questions.
This creates a subtle form of debt: technical structure built around assumptions that were never consciously chosen.
Later, teams call the resulting work "refactoring." In reality, part of the work is delayed product formation.
Implementation Feedback Is Still Essential
The argument for stronger discovery can be misused.
Teams can spend months modeling a domain that real users would invalidate in days. They can create elaborate product documentation that delays contact with evidence. They can mistake conceptual completeness for actual confidence.
Implementation should begin when the most important unknowns have been reduced enough that building is a rational next experiment.
The key phrase is "reduced enough."
The threshold depends on reversibility, risk and cost.
A useful model is:
| Situation | Better response |
|---|---|
| Cheap to reverse, low risk | Implement and observe |
| High UX uncertainty | Prototype and test |
| High domain uncertainty | Model actors, rules and state |
| High feasibility uncertainty | Technical spike or proof of concept |
| High external-contract risk | Validate contract and failure semantics |
| High regulatory/security impact | Research and review before commitment |
| High data-model irreversibility | Spend more time on invariants and history |
Discovery and delivery are not sequential departments. They are different modes of learning with different cost structures.
Reversible and Irreversible Decisions Need Different Treatment
Some teams attempt to solve premature implementation by adding more governance to every decision. That creates a different problem.
Not every decision deserves a workshop.
The goal is to identify which choices become expensive once encoded.
A color palette is reversible. A database tenancy model may not be.
An internal route name is reversible. A public API consumed by customers may not be.
A prototype's fake data is reversible. A production system's canonical identity model may not be.
The more irreversible the decision, the more useful it is to move learning earlier.
Architecture is therefore part of product discovery, not something that begins after it. Architecture Is a Product Decision, Not a Technical Afterthought develops that relationship in more detail.
Discovery Should Reduce the Cost of Being Wrong
A good discovery process does not prove that a product will succeed.
It makes the organization wrong more cheaply.
That may mean learning that the problem is not important enough. It may mean discovering a role or permission boundary that changes the workflow. It may reveal that a vendor integration cannot support a required guarantee. It may show that the product is valuable but economically unviable under the current model.
Those are successful discovery outcomes because they prevent larger commitments based on weak assumptions.
A useful measure of discovery quality is not how many artifacts it produced. It is whether important decisions became better informed before they became expensive to reverse.
Understanding Before Implementation Is Not Waterfall
"Understand before you build" can sound like a return to large up-front specification. It should not.
The goal is not to fully define the future system. The goal is to make the next set of decisions with enough understanding to justify their cost.
A healthy cycle looks like:
Understand
↓
Form a hypothesis
↓
Choose the cheapest useful test
↓
Learn
↓
Decide
↓
Build the next meaningful slice
↓
Observe real behavior
↓
Update understanding
Implementation remains part of the learning system. It simply stops carrying questions that cheaper methods could have answered first.
The strongest product organizations do not choose between discovery and delivery. They understand the economics of both.
Production code is excellent at discovering production reality.
It is an unnecessarily expensive way to discover what the product was supposed to be.
References
- Marty Cagan. The Four Big Risks. Silicon Valley Product Group, 2017. https://www.svpg.com/four-big-risks/
- Marty Cagan. Discovery, Judgement. Silicon Valley Product Group, 2020. https://www.svpg.com/discovery-judgement/
- Silicon Valley Product Group. Product Success. https://www.svpg.com/product-success/
- Silicon Valley Product Group. Product Discovery: Pitfalls and Anti-Patterns. https://www.svpg.com/product-discovery-anti-patterns/