Most digital problems are systems problems

The presenting symptom is rarely the disease

Most digital projects begin with a complaint about a surface: the website is slow, the shop doesn't convert, the reports don't match, the content takes too long. These complaints are real, and they are also usually symptoms. Underneath each one sits a tangle of technology choices, process gaps, people constraints, data quality issues and incentive structures that produced the surface problem - and will produce the next one too, if only the surface gets fixed.

I arrived at this by working through a sequence of problems that kept refusing to stay in their assigned category. The sequence is the argument.

Stage one: fragmentation

The earliest version of the problem looked like a platform issue: four separate storefronts, each with its own catalogue, its own admin, its own drift. The visible pain was operational - every price change made four times, every product update inconsistent somewhere. The obvious fix was consolidation, and that is what happened: four storefronts merged into a single Magento backend serving 1,570 products.

But the consolidation was never really a technology project. The hard parts were deciding whose product data was canonical, which storefront's conventions survived, and how the people who had each run "their" shop would work in a shared one. The platform migration was the easy half. The governance half - one catalogue, one source of truth, agreed ownership - is what made the technology change stick. That was the first lesson: the system is not the software.

Stage two: unified commerce, and what it exposed

The international Shopify transformation was the same lesson at a larger scale. On paper: 467 SKUs, 4 languages, 5 markets launched. The outcome - 2 new markets created and +52.8% net revenue in roughly five months versus the legacy shop's entire prior year - looks like a platform success story, and the platform mattered. But the numbers conceal the systems work that produced them.

One market was launched and then deliberately let go. That decision was not a technology outcome; it was a commercial judgment made possible because the system finally produced trustworthy per-market numbers. The four languages were not a translation task; they were a content operations problem - who owns localized product information, how it stays synchronized, what "done" means per market. The revenue growth came less from the new shop existing than from the organization around it finally being able to see, decide and act market by market. The storefront was the visible tenth of the work.

Stage three: measurement as a system

With unified commerce came an uncomfortable discovery: the measurement layer could not be trusted. Attribution was inconsistent, events fired inconsistently across markets, and advertising decisions were being made on numbers that different tools reported differently. The visible problem was that measurement was increasingly done by intuition and gut feel, rather than by a clear, data-based structure.

Rebuilding the tracking foundation - server-side where it mattered, consistent event taxonomy, reconciled sources - preceded a +371% year-over-year ROAS improvement. I want to be careful with that number: it is real, but it is not "we improved ads by 371%." A large part of the improvement was discovering what was already working and stopping what was not. Better measurement did not create performance; it created the conditions for correct decisions. That distinction is the whole point of this note.

Stage four: commercial intelligence

Once the organization could see revenue clearly, the next constraint surfaced: it could not see margin and cash with the same clarity. Pricing decisions were being made against supplier documents nobody had systematically analyzed; forecasts were educated guesses. The response was a pair of internal systems - margin and pricing intelligence parsing around a thousand real PDF invoices in 74 seconds, and a revenue and cash-flow forecasting application that closed the year at 2.1% full-year forecast variance.

Notice what category these projects are in. They are not "digital" in the way a website is digital. They are data and decision infrastructure. By this stage, the work had moved almost entirely below the surface - and the commercial outcomes depended on it more than on anything a customer could see.

Stage five: people are part of the system

There is a momentum that many pure developers or technically minded people skip, and I nearly did: the system and the company structure include the people who are supposed to operate and use them. As the operation grew, specialist knowledge concentrated in a few heads. As a counter to key-person risk, I deliberately hired the right people and created 47 SOPs - for recurring operational work, so the company does not depend entirely on any one person's absence.

That many SOPs sound like tedious bureaucracy, and they are - but: documentation is essential to reduce the risk of a few independent operators leaving the company.

Stage six: AI as the operating layer

The most recent stage - specialist AI agents with orchestration and governance - only became possible because the earlier stages existed. The agents read from measurement systems that were trustworthy because stage three happened. They analyze a commerce operation that is unified because stages one and two happened. Their output lands in an organization with documented processes and distributed knowledge because stage five happened. AI layered onto a fragmented, unmeasured, person-dependent operation would have automated the chaos, not the work.

This is why I am skeptical of AI initiatives that start with the AI. The leverage described in AI should create organizational leverage is real, but it is a dividend paid on systems maturity, not a substitute for it.

The interacting layers

Read across all six stages, the same six elements keep interacting: technology, process, people, data, incentives and commercial outcomes. Every failure I have been part of involved fixing one layer while ignoring another that was the actual constraint. Consolidate the platform without fixing data ownership and the catalogue drifts again. Rebuild tracking without changing how ad budgets are decided and the better numbers change nothing. Document SOPs without hiring for the gaps and you have documented an understaffed process. Deploy agents without governance and you have faster mistakes.

The website is where the system becomes visible. It is rarely where the problem lives.

I don't think this framing is original - systems thinking is old. But commercial digital work still gets scoped, sold and staffed as if the surface were the problem, project after project. The most useful diagnostic question I know is also the simplest: if we fix the thing being complained about perfectly, what breaks next? The answer to that question is usually the actual project.