From System to Product
The previous volume of this series argued that a working demo is not a working system. This one argues that a working system is not a working product. The technical work in volume two is necessary but not sufficient. Most products that ship still fail, and they fail for reasons the code cannot fix.
A demo proves it can work. A system proves it keeps working. A product proves someone wants it, can find it, can use it, and chooses to keep using it.
The ideas in this volume are easy to skip — they live outside the editor, outside the IDE, outside the satisfaction of green tests. They concern the people who use what you build, the laws that govern it, the data it consumes, the team that maintains it, and the day, eventually, when it has to be turned off. None of them are technical in the strict sense. All of them are engineering decisions in the broadest sense — choices made early that compound, for better or worse, for years.
If volume two was about the gap between possible and durable, this one is about the gap between durable and worth keeping.
A solution looking for a problem is, with rare luck, a hobby. With normal luck, it is a cost center.
Engineering culture rewards technical novelty: a clever architecture, a sophisticated model, a benchmark beaten. None of these matter if the thing being built doesn't solve a real, painful, frequent problem for someone willing to change behavior to use it. Most products that fail don't fail in production — they ship to indifference. The technical demo worked. The market shrugged.
The framing that helps: are you building a painkiller or a vitamin? Painkillers solve acute, specific pain. Users find them, adopt them quickly, pay for them. Vitamins are nice-to-have improvements; users say they want them in interviews and never quite get around to using them. Most engineering teams believe they are building a painkiller. Most are not.
Drag the dot to position your feature. The quadrant tells you whether it's a product or a problem.
Cool tech, no demand. The graveyard of clever startups.
Solution looking for problemReal pain, real solution. This is the only square that ships.
Product opportunityDon't go here. Don't pass go.
AvoidImportant problem, technology not yet ready. R&D, not product.
R&D territoryA great tool that doesn't fit the workflow is just clutter — extra cognitive load between the user and the thing they were already doing.
Engineers tend to optimize the central step — the algorithm, the prediction, the transformation. Users live in the whole pipeline. They come from somewhere (an email, a spreadsheet, a meeting), your tool is one step, and they leave to somewhere else (a report, a colleague, a decision). If you don't understand what comes before and after your step, your tool either won't be adopted, or it will be adopted with workarounds that defeat its purpose.
A library nobody can onboard to is a library nobody uses. The threshold for a working product is not "the code runs" — it is "a stranger can succeed with it in fifteen minutes."
Documentation is not a single thing; it is four things, each answering a different question. The Diátaxis framework names them clearly. Most projects have only the third — auto-generated reference — and wonder why adoption stalls. Reference is what an expert needs. Tutorials are what a beginner needs. Most users are not yet experts.
Hand-held learning. Concrete steps, guaranteed-to-work outcomes. The user follows along; the user feels successful. Five-minute "hello world" beats three-hour exhaustive intro.
Goal-oriented recipes. The user has a specific problem; the guide tells them how to do this one thing. Cookbook style. Skimmable.
Exhaustive, accurate, machine-friendly. Every parameter, every return, every edge case. Auto-generated is fine — and is also where most projects stop.
Concepts, design rationale, trade-offs, history. Reads like an essay. Helps experienced users build a mental model so they can extend it themselves.
The happy path is where you sell the demo. The unhappy paths are where the product lives.
Real users hit empty databases on day one. They paste malformed data. They lose connectivity halfway through. They try things you didn't anticipate. A product spends most of its operational time in these edge paths, and the quality of its responses there determines how it feels to use. Three rules for an error message: tell the user (1) what happened, (2) why, and (3) what to do about it.
throw, every error toast, every empty UI state. For each, write the message a calm, helpful colleague would say. Stack traces belong in the logs; users get sentences. Special love for the empty state on day one — that is the user's first impression of an empty database.
A product that works for you and not for someone with a screen reader is not a product, it is a beta — and a quiet declaration of who counts.
Roughly 15% of the world has some form of disability. Color-blindness alone affects ~8% of men. Half the world doesn't read English first. Right-to-left scripts (Arabic, Hebrew) flip every assumption you embedded in your CSS. None of these are edge cases — they are the ordinary distribution of human users. Designing for them well is design done right; designing for them badly excludes a meaningful slice of your potential audience without anyone noticing internally.
You're about to reserve Seat 14B on the 8:45 AM departure. Total: $189.
"We'll add compliance later" is a sentence that has cost more engineering hours than any other in the modern era.
Regulatory frameworks are not paperwork. They have architectural consequences. GDPR's right to deletion implies you can find every copy of a user's data and remove it — including from backups, analytics warehouses, and any model trained on it. SOC 2 implies an audit trail of who accessed what and when. The EU AI Act's transparency requirements imply explainable decisions for high-risk systems. HIPAA implies encryption at rest, in transit, and in audit logs. None of these are bolt-on features. They are properties of the architecture from day one — or expensive surgeries on day five hundred.
Select your context above to see which frameworks apply and what they require.
Where did it come from? What consent covered it? How long can you keep it? When someone asks you to forget them — can you?
Data has a lifecycle, and every stage has obligations. Most teams handle "use" well — that is the engineering they enjoy. The other stages — collection, consent, retention, deletion — get less attention until a regulator, a journalist, or a deletion request makes them suddenly central. The right time to think about how you delete a user is before you collect them.
A model is only as fair as the worst subgroup it serves. The aggregate number is a comforting average that hides the people the system fails.
Performance distributes unevenly. A 95% accurate classifier can be 99% on the majority subgroup and 78% on a minority one. If the dataset under-represents that subgroup, the model never learned them well. If the failure mode is consequential — credit decisions, medical triage, hiring — the disparity becomes a harm. Aggregate metrics let you ship without seeing it. Subgroup metrics force you to look.
A system that costs $200 a month in compute and consumes ten engineer-hours a week in operational toil is not a $200 system. It is a $4,000 system with a misleading invoice.
The cost of a product includes everything it takes to keep running: compute, sure, but also on-call time, incident response, support tickets, postmortem time, the cognitive overhead of a complicated runbook, and the opportunity cost of the engineers tied to it. Most TCO calculations omit the human time, and most cost surprises come from precisely that omission. When in doubt, count the meetings.
A product without a sunset plan becomes a zombie — drifting on, owned by no one, costing money, blocking the next thing.
Software is not built once and forgotten. The team that built it rotates. The dependencies it relies on age out. The use case it was designed for evolves. Eventually — sometimes after eighteen months, sometimes after eighteen years — the most valuable thing you can do for the product is end it cleanly. The discipline of controlled sunsetting is what separates a mature product organization from a graveyard of half-living services.
Two timelines, side by side: the controlled sunset (announce, deprecate, migrate, end-of-life) and the unmanaged decay that happens when no one was assigned to do this work.
A feature is not complete when it works in a demo. It is not complete when it works in production. It is complete when it has been used, maintained, and — eventually, gracefully — retired.
CODEOWNERS, a runbook with the top three failure modes and what to do, and a one-page deprecation policy ("if we sunset this, here is the timeline and the user communication"). Most teams write the third only after they need it. Most teams regret that.