Product & Design

The right unit of product work is a validated learning loop, not an output. Discovery must precede formulation: the question "what should we build?" is only answerable after the question "what do we need to learn?" has been answered and the evidence gathered.

last checked All thinking

This domain has good coverage (~18 notes) covering the full span from epistemology of product work through software architecture. It is effectively the applied layer of the Epistemology and Strategy domains.

Discovery: learning before building

Discovery delivery separation - Discovery (what to build) and delivery (building it) require different modes of work, different team compositions, and different success criteria. When they are conflated - when delivery teams are expected to be simultaneously resolving whether they should build this - neither works well. Discovery answers: is this the right problem? Delivery answers: is this the right solution? The questions must be sequenced.

BDD discovery precedes formulation (BDD/ATDD) - Behaviour-Driven Development’s deepest insight is not about test format but about sequence: shared understanding must precede scenario formulation, which must precede implementation. The “three amigos” conversation (product, dev, test) is a discovery process, not a planning process. Moving to formulation before understanding is reached produces specifications that are technically correct but practically wrong.

BDD as shared understanding - BDD scenarios function as communication artefacts, not just test artefacts. They encode the shared understanding of the team about what the system should do, making implicit assumptions explicit and surfacing disagreements before they become bugs. The value is not in the tests themselves but in the conversation that produces them.

Output vs validated learning - The most important unit economics distinction in product development: output (features shipped, velocity) is a proxy metric that is only valuable if the output produces validated learning about user behaviour. Teams that optimise for output without measuring learning can be highly productive by all internal metrics while making no progress toward product-market fit.

MVP as minimum learning test - The MVP is not the smallest thing you can ship and still call a product - it is the minimum experiment needed to test the most critical assumption. The right question is: what is the cheapest way to learn whether this assumption is true or false? Shipping a product is often not the cheapest path; a landing page, a concierge service, or a conversation sometimes is.

Customer archetype provisional - The customer archetype (persona) is a hypothesis, not a discovery. Treating it as fixed produces product development that serves the imagined customer, not the actual one. It should be explicitly marked as provisional and updated when evidence contradicts it - exactly the calibrated-belief discipline applied to the user model.

Persona as living hypothesis - The same point sharpened into a discipline: every element of a persona is a claim that discovery interviews exist to test, and the teams that use personas best are the ones that edit them most often - a persona that is not updated becomes confident misunderstanding, worse than none. Build it by abstracting upward from individual observation rather than averaging downward into a demographic. The construction and quality tools arrived with it this session: React persona quality (Real/Exact/Actionable/Clear/Testable, with the screener test as the fastest proxy) and Aidaor customer journey (storyboard the full Attention→Retention arc, not just acquisition).

Conversational vs terminal validation - Two modes of user research: conversational (open-ended, discovers surprises) and terminal (tests specific hypotheses). Both are necessary but at different stages and for different questions. Using terminal validation too early produces confirmation bias; using conversational validation too late provides no discriminating evidence.

Sequencing and prioritisation

Breadth before depth MVP - In early-stage product exploration, breadth (covering the full problem space shallowly) produces better learning than depth (solving one part completely). Depth before breadth produces a complete solution to a subset of the problem that may not be the right subset - and this is only discoverable after the investment.

Roadmap as strategic prototype - A product roadmap is not a commitment - it is a strategic prototype that shows the team’s current best hypothesis about what to build over time. It should update as learning accumulates. Treating it as a commitment produces defensive roadmapping (adding everything to avoid later criticism) and reduces honest learning about which directions are viable.

Risk vs schedule sequencing duality - (Cross-listed from Strategy) The fundamental sequencing choice: do you resolve the biggest risk first (risk-first sequencing) or do you deliver incremental value early (schedule-first)? The decision depends on the cost of being wrong and the shape of the uncertainty - and confusing the two modes produces suboptimal sequencing in both directions.

Software architecture

Hexagonal architecture ports adapters (Alistair Cockburn) - Hexagonal architecture (Ports and Adapters) separates the application core (business logic) from the infrastructure (databases, APIs, UIs) through ports (interfaces defined by the core) and adapters (implementations provided by the infrastructure). The benefit: the core can be tested without infrastructure; the infrastructure can be replaced without changing the core. This is the structural form of the separation-of-concerns principle.

Leaky abstraction across boundaries (Spolsky’s Law) - Every abstraction leaks: the abstraction that is supposed to hide complexity inevitably exposes the underlying complexity at edge cases. The law has two implications: you cannot rely on the abstraction to prevent you from understanding what it abstracts, and building on leaky abstractions compounds the problem. The practical move: understand what’s below your abstraction stack, even if you don’t usually operate at that level.

Ubiquitous language and model drift (DDD) - The domain model and the code should share a language: when they diverge, the code no longer expresses the business logic, and every change requires a translation step that introduces errors. “Model drift” is the progressive decoupling of the code’s conceptual model from the business reality it is supposed to represent.

Representation vs dynamics architectural split - (Cross-listed from Systems) In any software system, the static model (what things are) and the dynamic behaviour (what things do) must be architecturally separated. When coupled, changes to either require changing both - and both degrade faster. The hexagonal architecture and the domain model are implementations of this principle.

Persistent process failure as representation mismatch - When a process keeps failing at the same point, the proximal cause is usually a representation mismatch: the mental model of the process held by the people running it doesn’t match the actual process. The fix is not to work harder at the problematic step but to update the model - which requires discovery of what the model actually is and where it diverges from reality.

Design and user experience

Action cycle and two gulfs (Don Norman) - Norman’s Action Cycle: Goal → Plan → Specify → Perform → Perceive → Interpret → Compare. The Gulf of Execution (the gap between what the user wants to do and what the system allows) and the Gulf of Evaluation (the gap between the system’s state and what the user perceives). Good design minimises both gulfs. The cycle is a diagnostic tool: identify which step is failing before proposing a fix.

Product engineering possibility space - Product development operates in a three-dimensional possibility space: desirability (do users want this?), feasibility (can we build it?), and viability (does it create/sustain a business?). Most product failures are desirability failures (misunderstood user need) rather than feasibility failures. The implication: invest discovery effort proportionally to where the uncertainty actually lies.

Connecting to other domains