Not every frustration is a systems problem. This is an unpopular thing to say in a piece about workflow infrastructure, but it is true, and pretending otherwise leads founders to over-build things that needed a much smaller fix.
A missing filter in a project tool is a feature request. A client record that will not let you add a second contact is a feature request. A calendar integration that is one click away from existing is a feature request. None of these need a rebuild. They need an email to support, a plugin, or a five-minute workaround. Treating them as evidence of a broken workflow is its own kind of noise.
What actually distinguishes the two
A feature request is contained. It lives inside one tool. Fixing it does not require touching anything else the business does. A systems problem is not contained, it shows up across multiple tools, repeats on a schedule, and cannot be resolved by any single vendor because it lives in the space between platforms, not inside any one of them.
- If the fix is one setting, one plugin, or one support ticket away, it is a feature request.
- If the fix would require three different vendors to change how their products talk to each other, it is a systems problem, because that coordination is never going to happen on your timeline.
- If the friction happens once and is specific to an unusual situation, it is a feature request, or possibly not a problem at all.
- If the friction happens every week, follows the same pattern, and involves you personally bridging two or more tools, it is a systems problem.
“A feature request lives inside one tool. A systems problem lives in the space between tools, which is exactly where no vendor is responsible for fixing it.”
Why the distinction matters
Founders who cannot tell the difference make two mistakes, both expensive. The first is treating every feature request as a sign the whole stack needs replacing, commissioning a rebuild for something a plugin would have solved in an afternoon. The second, more common mistake is the reverse: treating a genuine systems problem as a collection of feature requests, filing support tickets with five different vendors for years, waiting for a fix that will never come because no single vendor owns the gap between their product and the next one.
That second mistake is the expensive one. It is the slow accumulation of years spent hoping the next update from a platform will finally close a gap that was never that platform's problem to close, because the gap exists between it and something else entirely.
How to tell, in practice
The reliable way to tell the difference is to trace where the friction actually happens. If you can point to a single screen, a single tool, a single missing setting, it is contained, and it is probably a feature request. If tracing it means following a piece of information across three or four different places, watching it get copied, translated, and manually reconciled along the way, that is not a feature request with a five-vendor waiting list. That is a systems problem, and it will keep costing you the same amount of time every week until something changes the shape of the workflow itself.
The Business Systems Diagnosis exists partly for this reason: trace friction to its actual source before deciding what kind of change it needs. Getting that distinction right keeps custom implementation reserved for problems that genuinely justify it.