Teams that measure delivery velocity without measuring user outcomes ship faster and faster in the wrong direction. The sprint velocity increases. The product value does not. This is the “busy engineering” failure mode: maximum engineering activity, minimum product progress.
The inverse failure is equally common. Teams so focused on user feedback that they cannot build stable systems end up with products that users want but that fail at scale. User value without architectural integrity is a product that breaks when it succeeds.
The most dangerous belief in engineering is that correct systems attract correct usage. A well-designed API will be misused. A carefully documented workflow will be bypassed. A feature built for one user segment will be adopted by a completely different one. Systems that cannot adapt to unexpected usage patterns are architecturally rigid in the most expensive possible way.
Concept: The gap between engineering correctness and user value is not a defect — it is a structural feature of how products are built.
Thread: T11 (Feedback) ← observed usage differs from intended usage → architecture must adapt to the real distribution
Core Idea: Technical excellence and user value are independent dimensions. Optimising one without the other produces incomplete outcomes. The product-architecture feedback loop runs in both directions.
Tradeoff: AT6 (Flexibility vs Simplicity) — designing for the intended usage model is simpler but brittle; designing for observed usage patterns requires flexibility that adds complexity
Failure Mode: FM12 (Architectural Rigidity) — an architecture designed for the intended usage model fails to accommodate the observed one; the cost of correction grows superlinearly with scale
Signal: When users do something with your system that you did not anticipate, that behaviour is a measurement of the gap between your assumed usage model and the real one
Maps to: Reference Book, Framework 1 (Mental Models) and Framework 5 (Review Questions)