The 5-Step System: Building Businesses from the Ground Up

Most businesses I meet start in the wrong place. They choose a tool, an app or a new hire, and only then try to work out what was actually wrong. Operational systems thinking reverses that order. Before deciding what to build or buy, I look at how the business really runs: who does what, with which information, under which constraints, and where it breaks. Only then do I decide what needs to exist.

Over the years I have reduced this way of working to five steps: Understand, Structure, Build, Operate, Improve. I use them for companies, for internal processes and for software alike. This note explains each step, the questions behind it, the mistakes it prevents, and why I think it is the cheapest form of risk reduction available to anyone who builds or runs a business.

Key points

• Operational systems thinking means describing reality before designing a solution.
• The five steps are Understand, Structure, Build, Operate and Improve, and they loop.
• Most failed projects skip the first two steps and start at Build.
• Evidence from real operation, not opinion, decides what changes next.

Why I stopped starting with software

When someone tells me their business needs a new system, my first question is not which one. It is: what is actually happening here?

The answer is rarely what the request suggests. A company that asks for a CRM often has a follow-up problem, not a software problem. A team that asks for an ERP often has three people keeping three different versions of the same stock figure. A founder who asks for automation often has a process that nobody has written down, so there is nothing stable to automate yet.

Software bought before the reality is understood tends to fail in one of two ways. Either it encodes the wrong process and people work around it, or it forces a process the business does not actually follow and people stop using it. In both cases, the money is spent and the original problem is still there, now hidden under a new layer.

I grew up around aggregate-crushing and quarry operations, and I spent my first entrepreneurial years running e-commerce businesses. Neither environment forgives guesswork for long. A crushing line with a bottleneck does not care how good the plan looked on paper. A cash-on-delivery store with a broken confirmation process loses money every single day. Those years taught me that real systems have constraints, dependencies, failures, inputs, outputs and people operating them. Ignoring any of those is how projects fail. Operational systems thinking is simply the habit of not ignoring them.

What operational systems thinking means

Operational systems thinking is the habit of looking at a business as a set of connected flows rather than a list of separate problems. Orders, materials, cash, information and decisions move through the business. Each flow has inputs and outputs, people who touch it, rules it follows, and places where it slows down or breaks.

The broader field of systems thinking has studied how parts of a whole influence one another for decades. What I add is the operational angle: I care less about abstract feedback loops and more about the concrete Tuesday morning when a truck is waiting, a document is missing and someone has to make a decision with incomplete information.

In practice, operational systems thinking asks five kinds of question:

• Flows. What moves through this business, and in what order?
• People. Who touches each flow, and what do they actually need to do their part?
• Data. Which information travels with each flow, and where is it recorded?
• Constraints. What limits the flow: capacity, time, money, rules, skills?
• Failure points. Where does it break today, how often, and what happens when it does?

None of these questions mentions software. That is deliberate. Software is one possible answer. It is never the first question.

The five steps at a glance

Each step has a central question, a concrete output and a typical mistake. I find it useful to keep the whole sequence on one page.

Step	Central question	Output	Typical mistake
Understand	What is actually happening here?	A written description of reality	Trusting the org chart instead of watching the work
Structure	What is the underlying structure?	Process map, data list, dependencies, failure points	Mapping the ideal process instead of the real one
Build	What needs to exist?	The smallest thing that fixes the real problem, built properly	Building everything at once
Operate	Does it work in real conditions?	Daily use by real people	Launching and walking away
Improve	What does the evidence say?	Targeted changes based on facts	Changing things because of opinions

Step 1: Understand

The first step is the one most people want to skip, because it feels slow. In operational systems thinking, it is the step that saves the most time.

To understand a business, I go where the work happens. Lean manufacturing calls this the gemba, the real place. I sit with the people doing the work before I open a laptop. I follow one order, one delivery or one invoice from beginning to end. I ask to see the real documents: the notebook at the gate, the spreadsheet on the accountant’s desktop, the WhatsApp group where drivers confirm deliveries.

A few habits make this step productive:

• Follow one case end to end. One real order, traced through every hand it passes, reveals more than ten interviews about the process in general.
• Count things. How many orders a day, how many corrections a week, how many minutes per task. Rough numbers beat confident adjectives.
• Ask what happens when it goes wrong. Every process looks clean when it works. The interesting part is the exception: the return, the missing document, the absent colleague.
• Listen for workarounds. When someone says “normally we do it like this, but”, the real process starts after the “but”.

The output of this step is a plain written description of how the business works today, in the words of the people who run it. It is not a judgement and it is not a plan. It is a picture of reality that everyone involved can recognise.

Step 2: Structure

Once I know what is happening, I look for the structure underneath it. This is where operational systems thinking becomes concrete.

I map four things:

1. Processes. Who does what, in which order, triggered by what event.
2. Data. Which information each step needs, which it produces, and where that information lives.
3. Dependencies. Which steps cannot start until another one finishes, and which people or tools everything relies on.
4. Failure points. Where the flow breaks, how often, and what it costs when it does.

The most valuable output is often the dependency list. It shows the hidden single points of failure: the one person who knows the supplier prices, the one spreadsheet that feeds three reports, the one machine whose breakdown stops everything downstream. The theory of constraints makes the same point in its own vocabulary: a system moves only as fast as its narrowest point, so improving anything else first is wasted effort.

At this stage, I also separate what is essential from what is habit. Some steps exist because the business needs them. Others exist because a tool from ten years ago required them and nobody removed them. Structure means seeing which is which.

Step 3: Build

Only now do I decide what needs to exist. Sometimes it is software. Often it is something simpler: a clear role, a single shared list, a rule about who confirms a delivery, a form that replaces three phone calls.

Two principles guide this step.

The first is to build the smallest thing that fixes the real problem. The writer John Gall observed that working complex systems almost always grow out of working simple ones, an idea now known as Gall’s law. Systems designed complex from the start rarely work, and they are very hard to repair. So I start with the core flow that the structure step identified, make it work, and only then extend it.

The second is to build it properly. Small does not mean improvised. If the fix is software, it needs a clean data model, clear permissions and a way to correct mistakes. If the fix is a process, it needs to be written down, owned by someone and simple enough to follow on a bad day.

This is also where operational systems thinking protects the budget. Because the first two steps defined the real problem, the build has a clear boundary. Requests that do not serve the identified flow can be postponed without guilt.

Step 4: Operate

A system that has not run in real conditions is a hypothesis. The fourth step turns it into evidence, which is why operational systems thinking treats the first weeks of use as part of the build rather than an afterthought.

Operating means putting the new process or tool into daily use, with the real people, the real data and the real constraints. It also means staying close during the first weeks. I watch where people hesitate, where they fall back on the old way, where they need a second explanation. Those moments are not failures. They are the most precise information the project will ever produce.

A few rules for this step:

• Run it on real work, not on a demo. Test data never contains the strange cases that real data does.
• Keep the old way available, briefly. A short overlap reduces risk, but it must have an end date or the old way never dies.
• Make it easy to report problems. If reporting a problem is harder than working around it, people will work around it, and you will never know.
• Write down what you observe. Memory is selective. Notes taken during operation become the input of the next step.

Step 5: Improve

The last step closes the loop. I change what the evidence points to, and nothing else.

This sounds obvious, but most improvement in businesses is driven by opinion: the loudest complaint, the newest idea, the feature a competitor just announced. Evidence-based improvement is quieter. It looks at the notes from operation, the error counts, the time spent per task, and asks which single change would remove the most friction.

The classic PDCA cycle (plan, do, check, act) describes the same discipline. What matters is the order: you check before you act, and you act on what you checked.

Improvement then feeds back into understanding. Each change alters the reality, so the next cycle starts by looking again at what is actually happening. That is why I describe operational systems thinking as a loop rather than a line.

How the five steps loop in practice

On paper, the steps run in sequence. In reality they overlap and repeat at different scales.

• On a large project, the full cycle might take months, with a long Understand phase before anything is built.
• On a small fix, the whole loop can fit into a week: watch the problem on Monday, map it on Tuesday, change it on Wednesday, observe it for two days, adjust it on Friday.
• Within a running business, the Operate and Improve steps never stop. Each improvement is a small new cycle.

In operational systems thinking, the discipline is not the calendar. It is the refusal to skip a step. Building without structure, or improving without evidence, is where the risk comes back in.

An illustration: the business that asked for a CRM

The following example is an illustration, simplified from the kind of situation I meet often. It does not describe a specific company.

A distribution business with a dozen salespeople asks for a CRM because “customers are not followed up”. The request is specific and the solution seems obvious.

Understand. Spending two days with the sales team shows that customers are followed up, but inconsistently. Each salesperson keeps their own notebook. When someone is absent, their customers wait. The real complaint came from the manager, who cannot see who called whom.

Structure. The map shows three flows: new enquiries, existing customer orders and unpaid invoices. The dependency list reveals that the unpaid invoice list is kept by the accountant in a spreadsheet the salespeople never see, so they keep visiting customers who have not paid. The failure point is not follow-up. It is that sales and finance work from different information.

Build. The smallest useful fix is a single shared customer list with three fields that matter to everyone: last contact, open orders and unpaid balance. It could be a simple CRM, or a shared table with clear rules. Either way, it must show the unpaid balance to the salesperson before a visit.

Operate. For four weeks, the team uses it on every real visit. The manager notices that two salespeople still update their notebooks first and the list later, so the list is always a day late.

Improve. The fix is not a new feature. It is entering the visit from the phone, in the car, before driving away. Updates become same-day, and the manager finally has the view they asked for.

The project that started as “we need a CRM” became “sales and finance need to see the same customer”. The software choice became a detail. That is what operational systems thinking is for.

What operational systems thinking de-risks

I describe this method as risk reduction because each step removes a specific kind of risk.

Risk	Step that reduces it	How
Solving the wrong problem	Understand	The problem is defined by observation, not by the request
Hidden single points of failure	Structure	Dependencies are listed before anything changes
Overbuilding	Build	Scope is limited to the flow that matters
Low adoption	Operate	Real users test it on real work, early
Endless rework driven by opinion	Improve	Changes require evidence

None of these risks disappears entirely. But each becomes visible early, when it is still cheap to deal with.

Common mistakes

These are the patterns I see most often when operational systems thinking is missing from a project.

• Starting at Build. Choosing the tool first and fitting the business to it later.
• Mapping the ideal instead of the real. A process map drawn in a meeting room describes what people think happens, not what happens.
• Treating structure as paperwork. The map is not the goal. Seeing the dependencies and failure points is.
• Skipping Operate. Delivering a system and assuming people will use it as designed.
• Improving by opinion. Changing what is loudest rather than what the evidence shows.
• Forgetting the people. Every flow is operated by someone. A system that ignores their reality will be ignored in return.

How I use operational systems thinking across my work

I apply the same five steps whatever I am building. At MeskikCode, the brand under which I offer custom software and business digitalisation, they shape how a project starts: understanding the operation comes before any line of code. In my other ventures, listed on the ventures page, the same questions apply to products, teams and decisions.

The method is not tied to technology. It came from watching physical operations and running online stores long before I wrote software for others. Technology is how I build. Operational systems thinking is how I decide what is worth building.

Questions about operational systems thinking

Next

This is the first of a series of notes on how I build. Read more about my background, see the ventures I am involved in, or write to me if you are building something and want to compare notes.