Next WrldThe phrase appears in a meeting, almost always the same.
Someone sustaining operations says: “we need a system”. Everyone nods. Nobody asks what it means. The meeting continues, but the request is already floating.
It is born from tiredness of fixing errors, chasing information, coordinating by message what should flow orderly.
The problem is “we need a system” describes a feeling, not a problem. With a feeling you can’t evaluate, prioritize nor build.
This article proposes translating the symptom into an observable problem, with measurable friction and expected outcome.
A generic request can’t be quoted nor decided
When someone asks for “a system”, each person imagines something different.
For one it is a more ordered spreadsheet. For another, notices going out alone. For another, controlling what today isn’t seen. Same word, different things.
That is why that request is unbuyable and unquotable. No vendor can price it without inventing assumptions. No owner can prioritize it. No team can build it without guessing.
What if it costs little and solves much? What if it costs much and solves little? Without definition, both options look alike.
A good problem, instead, allows comparing. It lets you say what it costs today in time, errors and rework. And decide whether to act now or later.
The question is which problem deserves attention.
Where it hurts, when, whom and what it costs today
Every symptom clarifies with four simple questions.
Where does it hurt? When does it appear? Whom does it affect? What does staying like this cost today?
Where it hurts forces locating the process, not “the company”, but a concrete place like building shifts, covering absences, recording attendance or closing payroll.
When it appears forces locating the moment. Does it always hurt or in peaks? With last-minute changes? At month close, without margin to fix?
Whom it affects forces setting roles. Who builds shifts? Each site’s owners? Whoever settles payroll and must rebuild what happened?
What it costs today forces describing friction. Constant coordination, repeated errors, hand checks, decisions without information.
None asks for technology. They ask for observation, and calmly observing is usually worth more than any demo.
The problem isn’t the requested solution
Many requests deviate here.
Someone says “we need a shift app”. That is an assumed solution. It can be right or not, but there are still no elements to know.
Separating problem from solution requires asking what would change if that solution worked. What would stop hurting? What would look different in the week?
If the answer is “nobody would have to call three people to cover a shift”, the problem is coordinating replacements. If it is “closing payroll wouldn’t take days”, the problem is missing reliable attendance information.
The requested solution usually touches the real problem, but doesn’t name it.
A mature company first asks “what is happening and why does it cost us?”.
A well-written problem can be evaluated
A defined problem has a recognizable shape. It says which process, which friction, which impact and which expected outcome.
Observable process: which work part we watch, start to finish. Who participates, which information enters, which decision exits.
Measurable friction: what breaks today. Late information, rules in one person’s memory, unrecorded changes, hand controls.
Impact: what that friction costs. Coordination hours, settlement errors, badly covered shifts.
Expected outcome: how it would look if it worked, in operations language. Less improvisation, timely attendance, settlement without rebuilding history.
When that is written in simple language, anyone can evaluate it. It can be discussed, prioritized or postponed.
A problem that can’t be explained without jargon isn’t ready yet.
The path is chosen afterwards, not before
Only with the defined problem does choosing how to solve it make sense.
Ordering, integrating, automating, buying or building aren’t the same, and not every problem needs new software.
Ordering is agreeing rules. Who builds shifts, how in advance, how a change is communicated, who approves it, where it is recorded. Many frictions drop with just this.
Integrating is better using what already exists. Sometimes information is already there, but in separate places.
Automating is removing repetitive work where criteria are already clear. Notices, summaries, controls today manually reviewed.
Buying or building comes last. Sometimes an existing tool solves well. Sometimes something custom must be created. Building is valid, but the last option.
The rule is simple. The least complexity needed to correctly solve the problem. A good defined problem sometimes concludes “no need to build”.
Before and after: shifts, attendance and settlement in a multi-site company
See transformation in staff control and shifts in a multi-site company.
The before sounds like this:
“We need a shift system. Each site handles differently, there are constant phone changes, nobody really knows who came and who missed, and settling at month end is chaos.”
All that can be true. But like this nothing can be decided. What hurts most: building shifts or controlling attendance? Changes or settlement?
The after demands observing the complete circuit.
The circuit is this: each week shifts are built per site. During the week changes appear from absences or peaks. Each site records attendance their way. At month end, admin rebuilds what happened to settle.
The defined problem could be written like this:
Each week, owners build shifts per site in separate spreadsheets, without common anticipation rule nor approval. Changes are coordinated by messages and calls, and often aren’t recorded. Attendance is noted on paper or from memory, differently per site. At month end, settling demands calling, comparing versions and fixing.
Friction is visible: scattered information, unrecorded changes, different criteria, manual verification at the end. Impact is operational: constant coordination and settlement errors.
Expected outcome is said in operations language: shifts published with known anticipation, changes recorded with owner and time, attendance noted the same day with equal criteria, settlement closed without rebuilding history by phone.
It doesn’t say which screens it must have, which tool to buy nor what to automate first.
With this, decisions change. Maybe ordering rules and unifying records suffices. Maybe integrating what exists suffices. Maybe automating notices suits. Maybe building something custom is right. Each option is compared against the same problem.
That is the difference between asking a symptom and defining a problem.
How to know if it is already defined
There is a simple test. If defined, it answers these questions without doubting.
Can it be observed in real operations? Is it known in which process it happens and when it hurts most? Is it known whom it affects? Can what staying like this costs be described? Can how it would look if it worked be described, without talking features?
If any answer is vague, definition is missing. The vague isn’t unimportant, it just signals it can’t yet be prioritized nor responsibly built.
Another test: ask two people to explain it. If they tell different stories, it is still open. If they tell the same, there is base to advance.
Defining is not moving resources until operations are understood.
Three mistakes returning everything to start
First is defining the solution instead of the problem. “We want an app with such features” closes conversation before understanding.
Second is quoting the symptom. The vague request is sent, incomparable prices arrive, each assumes something different, and deciding becomes impossible.
Third is adding everyone’s requests when defining. Each site adds its wish and the problem grows until unmanageable. Defining is also cutting. One process, one friction, one outcome.
Avoiding these three mistakes saves months and avoids building something nobody ends up using.
If it can’t be evaluated, prioritized and built, definition is still missing
Back to the opening meeting.
The phrase “we need a system” was the honest warning of someone seeing operations cost. The mistake would be taking it literally and going out to buy or build.
Serious work is translating it and turning feeling into observable process, complaint into describable friction and wish into expected outcome.
If the problem can be evaluated, it can be prioritized and decided, and then it can be built (or decided not to build) calmly.
That is the bar. What doesn’t reach it is still symptom. Every symptom deserves listening, but none should be quoted.