Engineering excellence and product success pursue different objectives, and confusing them is the most expensive mistake a technical leader can make.
A system that maintains 99.99% availability, handles one million requests per second, and deploys without downtime is an engineering achievement. If the system solves a problem users do not have, it is also a business failure. Reliability and scalability are properties of a system. Value is a property of the relationship between a system and its users. These are independent dimensions, and optimising only one of them produces incomplete outcomes.
This chapter examines the gap between technical correctness and user value — how it opens, why it persists, and what it costs when it goes unaddressed.
You have seen feedback before in its technical form: circuit breakers that adjust retry behaviour based on error rates, monitoring systems that route traffic away from degraded nodes, load balancers that recalibrate based on response times. In each case, the system observes its own output and adjusts its behaviour accordingly. This chapter applies the same logic to the product layer. The system is no longer a circuit breaker — it is a product team. The feedback signal is no longer a latency metric — it is the gap between how users actually use the product and how the team intended them to use it. The adjustment is no longer an automated failover — it is a product decision.
Technical teams measure quality in terms they can control: latency percentiles, error rates, test coverage, deployment frequency. These are proxies. They are proxies for the underlying goal, which is that users accomplish something they wanted to accomplish, faster or more reliably than they could before.
The gap opens because proxies are easier to measure than outcomes. An engineer can verify that a function returns the correct output for a given input in milliseconds. Verifying that a user accomplishes their goal requires watching the user, which is slow, qualitative, and uncomfortable for people trained in precision.
The result is a systematic bias. Technical teams over-invest in properties they can measure and under-invest in the ones they cannot. A codebase with 95% test coverage may have zero tests that verify the user actually completed their task. A CI/CD pipeline that deploys twelve times a day may be deploying features that users ignore.
This is not a competence failure. It is a measurement failure. What gets measured gets managed.
The product-architecture feedback loop runs in both directions, and understanding both directions is essential for technical leaders.
In the first direction: user behaviour reveals architectural reality. When a messaging app ships a group video feature and discovers that it generates ten times the expected database writes, that is not a product miscalculation — it is evidence that the usage model was wrong. Users joined group calls and left them running in the background. The intended use was a short focused call; the observed use was ambient presence. The architecture was designed for the intended use. The product succeeded because of the observed use. These are not the same thing, and the delta exposed an architectural constraint that would not have appeared in any load test.
In the second direction: architectural limits constrain product decisions. A team that wants to build a real-time collaborative editing feature discovers that their database is transactional and single-writer. The product decision — “we will add collaboration” — triggers an architectural decision — “we must change the storage model.” Every major product capability has a corresponding architectural requirement. Technical leaders who understand this translate product intent into infrastructure investment before the product team hits the wall.
Users are, in systems terms, the external input to the system. Their behaviour is variable, unpredictable, and not subject to the technical team’s control. A common engineering failure is to design systems for an assumed usage model rather than the observed one. The assumed model is tidy: users follow the happy path, use the documented features in the documented order, and stop when they reach an error. The observed model is not. Users copy-paste URLs into contexts the URL was not designed for. They open thirty browser tabs simultaneously. They leave sessions open for days.
Design for the observed distribution, not the intended one.
Twitter’s early architecture was designed for a fan-out model where a user’s timeline was assembled by reading from a central feed. When celebrity accounts with tens of millions of followers arrived, the model broke: a single tweet required tens of millions of write operations to fan out to all followers. The architectural model had been designed for the median case. The product succeeded beyond median expectations, and the architecture had to change.
Slack’s growth exposed a different problem. The product was designed for teams of tens to hundreds of people. When it reached enterprises with tens of thousands of employees, search became unusable. The search index had been designed for a bounded message corpus. Enterprise-scale usage produced an unbounded one. The product’s success created the architectural problem.
In both cases, the engineering teams had built correct, well-tested systems. The systems failed not because the engineering was wrong but because the usage model that materialised was different from the usage model that was assumed.
Optimising for technical correctness without user value produces robust systems that nobody uses. Optimising for user value without technical correctness produces engaging products that eventually fail under their own success. The tension is real, and resolving it requires holding both objectives simultaneously rather than alternating between them.
The compounding nature of this tradeoff is important. Early architectural decisions that correctly model user behaviour are cheap to maintain. Early architectural decisions that incorrectly model user behaviour accumulate as technical debt that grows faster than the product does. A team that discovers at scale that their core data model does not match how users actually use the product faces a rewrite under time pressure, with live users on the system.
The most expensive architectural decisions are not the ones made under constraint. They are the ones made under incorrect assumptions.
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 (Generality vs Specialisation) — designing for the intended usage model is simpler but brittle; designing for observed usage patterns requires flexibility that adds complexity
Failure Mode: FM12 (Split-Brain) — 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: Book 0, Framework 1 (Mental Models) and Framework 5 (Review Questions)
Identify a system you have built or worked on where the actual usage pattern differed from the intended one. What architectural assumption was exposed? How long did it take to detect the discrepancy?
For a product you currently work on, list three technical metrics you track and three user outcome metrics. How are they related? Is it possible to improve the technical metrics while degrading the user outcomes?
How would you explain to an engineering team that 99.9% uptime on a product with 0% user adoption is not a good engineering outcome? What measurement system would you propose instead?
The chapter argues that users are the external input to the system and that their behaviour is variable and unpredictable. What design principles follow from treating users as an uncertain external signal rather than as a predictable fixed input?