Start With the Problem, Not the Tool

The operating problem

A business feels its operation straining. Margins thin while revenue holds. Rework becomes routine. Jobs slip between departments. The owner or a few key managers absorb every exception. Systems that were supposed to help sit half-used while the real work happens in spreadsheets beside them.

A common response is to reach for a solution: new software, an automation platform, a reorganization, another hire. Sometimes that works. Sometimes the underlying operating problem remains, with another system or process layered on top of it.

I have spent more than twenty years inside operations, as the executive being sold solutions and as the operator responsible for making them pay. The problem is often not the tool itself. It is the sequence in which the problem and the solution were approached: the solution was chosen before the operating problem was found.

This paper is about doing it in the other order. Find the problem. Redesign the work around what you find. Then decide which tools, if any, the new design needs.

Why operating problems are hard to see

Finding the problem first sounds straightforward. In practice, operating problems can be difficult to see because they tend to hide in a few predictable places.

They hide between the frontline and the reports. Leadership sees outcomes: the missed date, the overtime bill, the thin margin. The fourteen small steps that produced the missed date are visible mainly to the people executing them. The handoffs are often much easier to see from the frontline than from an aggregate report, and most reporting is aggregate.

They hide inside workarounds. Every operation accumulates them: the spreadsheet beside the system, the export-edit-import routine, the person who just handles it. Each workaround was a reasonable fix for one day's problem. Together they become the real process, and nobody designed it.

They hide behind unclear ownership. Work waits when the next step has no clear owner, and waiting rarely shows up as a line item. Some of the most expensive problems I have found were not broken steps at all; they were gaps between steps that belonged to no one.

They hide in designs the company outgrew. Processes get built informally, by capable people, when the company is small enough that shared memory works. As companies grow, the way work moves, decisions are made, and responsibilities are assigned has to change with them. Growth exposes operating structures that no longer fit the business.

And they hide behind the ease of buying. A solution has a price, a demo, and a vendor who returns calls. An operating problem has none of those. A solution is easier to buy than an operating problem is to diagnose, and busy leadership teams take the path that is easier to start.

Five lenses for finding the problem

When I walk into an operation, I look through five lenses. These five reflect patterns I have used repeatedly across my operating career. The examples below are from that career, and they are labeled as such throughout: they are the founder's operating record, not BMG client outcomes.

The Work: follow one real job, end to end.

Not the flowchart version; the actual job, with its waits, repeats, and handoffs. As Chief Customer Officer at MyCarrier, I inherited customer onboarding that took multiple weeks, sometimes more than three. The important part is how the problem was found: not from the dashboard, which only showed that onboarding was slow, but from sitting with the frontline team and tracing one customer's path step by step. What surfaced was waiting: work parked between steps, credentials pending, information requested twice. The redesign that followed brought onboarding to about three or four days, and platform utilization rose roughly 40%. The lesson I carry from it: the dashboard tells you that a workflow is slow; only the workflow tells you why.

The People: find out who owns each outcome, and who can actually decide.

While serving with a larger consulting firm, our team worked with an anonymized carrier division of roughly $150M that ran as thirteen separate offices. Each office optimized locally: its own customers, its own carrier relationships, its own numbers. Locally, every office was behaving rationally. Collectively, the division was competing with itself, because ownership and incentives had been designed around offices rather than around the business. The redesign was not primarily technological: work ownership, incentives, rules of engagement, training for more than a hundred employees, and governance to hold it together. Ten months after the changes took effect, the firm's published case results reported the division at 100% of its revenue goal and 118% of its gross-profit goal. The lesson: individual teams can each optimize their own patch while the whole quietly loses, and no tool fixes an ownership design.

Ownership problems also appear as absences. At project44, I took over an integration ecosystem spanning 350+ carrier API integrations that had been deprioritized; connections were aging and no one owned the layer. The fix began with restoring ownership and building a simple governance loop: prioritize by actual usage, work directly with the partners' technical teams, verify before calling anything restored. Twenty-six new connections shipped in under nine months, and none of the three organizations involved reported to me. Operating problems do not always wait for authority; visibility, priorities, and coordination can carry a long way.

The Systems: list what you own, what is used, and what is bridged by hand.

A systems problem is not automatically a missing-tool problem. At MyCarrier, support ran on email queues with resolution times averaging around 26 minutes, while the company already owned the systems a better workflow needed. Redesigning intake and routing and connecting those existing systems brought resolution time to roughly 90 seconds. Before pricing new software, it is worth writing down every point where a person re-types, exports, or reconciles information between systems by hand. That list gives you a much better picture of the actual systems gap than starting with a software wish list.

The Management: ask how a problem becomes visible, and to whom.

As COO of Freightclaims.com, a venture-stage company, I installed the operating cadence from nothing: annual planning, quarterly rhythms, 13-week execution plans, KPI dashboards. What a cadence buys is not paperwork; it is earlier visibility with a named owner, so problems surface while they are still small and someone is accountable for acting on them. Without a consistent management rhythm, priorities and escalation tend to be driven by whatever problem is most visible in the moment.

The Money: turn every finding into an economic statement.

A finding without a cost attached is an observation; with a cost attached, it is a decision. During a capital-constrained period at that same company, I led a restructuring that reduced monthly operating expenses 30 to 40%, through vendor renegotiation, tool consolidation, and financial controls. What made that possible was visibility built first: knowing what each vendor and tool was actually doing for the operation, and separating necessary operating capability from accumulated expense. Quantify the impact of what you find as rigorously as your data supports, and be honest where the data stops.

Across all five lenses, the working pattern is the same one, and it is simple to state: go to the people doing the work, follow the real workflow, find where work waits or changes hands, identify the ownership and decision problems, quantify what they cost, redesign the work, align the systems to the redesign, install the management rhythm, implement, and measure. None of that requires a framework. It requires the discipline to do it in that order.

Where technology fits

Nothing above is against technology. Two of the five examples are technology stories; the 26-minutes-to-90-seconds result is one. The difference is that the technology was applied to a workflow that had been understood and redesigned first.

The research on business technology adoption points the same direction. McKinsey's State of AI surveys found workflow redesign to be the practice most strongly associated with reported bottom-line impact from AI, and reported that the organizations seeing real financial impact were far more likely to have fundamentally redesigned individual workflows; only about a fifth of surveyed organizations had done so (McKinsey, March and November 2025; survey-based association, not proof of causation). IBM's study of two thousand CEOs found only 25% of AI initiatives had delivered their expected return, and 64% of CEOs acknowledged investing in some technologies before having a clear understanding of their value (IBM, May 2025). And a large Danish study of 25,000 workers found that AI chatbot adoption was associated with average time savings of about three percent and little measurable effect on earnings or recorded hours in the period studied (Humlum and Vestergaard, NBER working paper, May 2025): real tool, modest measured effect.

The honest counterpoint belongs here too: a peer-reviewed study of customer-support agents found an AI assistant raised productivity 15% on average, with the largest gains for newer agents (Brynjolfsson, Li, and Raymond, The Quarterly Journal of Economics, May 2025). Tools can create task-level value on their own. The question an operator has to answer is whether task-level value will become business results in your operation, and that answer usually lives in the surrounding workflow, ownership, and measurement, which is exactly what a diagnosis maps.

AI raises the same operating question as any other technology: what problem is it solving, and is the surrounding workflow designed to use it? We use AI daily in our own work. It amplifies whatever process it is pointed at, which is precisely why the process deserves attention first.

A first pass you can run yourself

You can run the first pass of this diagnosis in about a week, without buying anything.

• Pick one workflow that matters and follow one real job through it, end to end. The actual job, not the documented version.
• Write down every place it waited, and for how long. Waiting is often one of the largest sources of delay, and it can be hard to see in aggregate reporting.
• For each wait, ask who owned the next step, and whether that person knew it. Unclear ownership is worth checking early because it can create delay without requiring any technology change.
• List every system the job touched, and every point where information moved between systems by hand. That list is your systems reality.
• Put a rough cost on what you found. Hours, delay, rework, customer impact. Even a rough number turns a complaint into a decision.

Some findings may be straightforward for your team to address directly. If the problem crosses several functions, requires data your team cannot easily reconcile, or needs sustained implementation leadership, outside help may make sense. Whoever provides it, hold them to the standard this paper argues for: diagnosis before solutions, fixed scope, findings you could act on without buying anything else, and measurement defined before the work starts. That standard is what the BMG Operations Diagnostic is built around.

Conclusion

The sequence is the whole argument. Diagnose the operation. Fix what the diagnosis found. Prove it with measurement. Software, automation, and AI all have their place, and that place is inside a workflow that was designed on purpose.

Start with the problem, not the tool.