There’s a quiet way for a product to fail that never shows up as a failure. The feature ships. The demo lands. Usage of the new thing is even decent. And the number you actually care about — the one about people getting the outcome they came for — doesn’t move at all. Nobody did anything wrong. You just built a feature where a workflow was needed, and the difference is easy to miss until you’re standing in the gap.
A feature is a capability: a thing your product can now do. A workflow is the whole path a person walks to get an outcome they wanted — usually several steps, often across days, sometimes across tools. Users don’t wake up wanting features. They wake up mid-workflow, holding a job that isn’t finished, and they reach for whatever gets them to the end. Your feature is one segment of that path. The question that decides whether it matters is brutally simple: does the outcome actually complete now, or did you just make step three nicer and leave steps one, two, four, and five exactly where they were?
Here’s the shape of the trap.
The reason this is so easy to ship is that features are legible and workflows are not. A feature fits in a ticket, a sprint, a changelog line. A workflow sprawls: it starts before your product opens and ends after it closes, and half of it happens in someone’s head or in a tab you’ll never see. So teams optimize the part they can see. The seams — the copy-paste between steps, the “now go do this elsewhere and come back,” the re-entry after a two-day gap — are exactly where the effort actually lives for the user, and exactly where nobody on your side is looking.
You can feel the difference in the metrics if you know where to look. Feature adoption that’s high while the outcome metric is flat is the classic tell: people are touching the new thing and still not getting where they were going. So is the exit that happens right after your feature succeeds — the user finishes step three in your product and immediately leaves to finish the job somewhere else. That’s not churn from disinterest. That’s a workflow that runs through you but doesn’t end in you.
The fix isn’t “build more.” It’s to draw the whole path before you build the segment. Map the job end to end — including the steps that happen before anyone opens your product and after they close it. Mark where your feature sits. Then look hard at the two boxes on either side of it and ask what the user has to do to get from one to the next. Sometimes the highest-value work isn’t the feature at all; it’s the boring connective tissue that turns five disconnected steps into one motion.
None of this means you must own every step. Owning the whole workflow is expensive, and plenty of good products deliberately do one segment brilliantly and hand off cleanly. That’s a fine choice — as long as it’s a choice. The failure isn’t leaving a seam. The failure is not knowing the seam is there, and quietly assuming that because the feature works, the job is done.
Ship features. Just draw the workflow first, so you know which seam you’re leaving open and whether the outcome can survive it.
Sources
- Diagnosing feature adoption vs. outcome metrics
- workflow seams and the boundary of what a product should own
Liked this? Get the next one in Working Theory.
Going weekly in August (it's in beta now). One genuinely interesting read on building, the brain, and the science most people missed.
Subscribe →