Imagine hiring a builder to build you a house. You buy a plot of land, order a lorry-load of timber, bricks, and pipes, dump it all on site, and say: "Get started. I'll tell you what I want as you go."
There's no site plan, no structural drawings, no decision about where the kitchen goes or whether the living room faces the morning sun. Just materials, people, and enthusiasm.
No builder in the world would accept that job. And no homeowner would seriously propose it, because the absurdity is obvious the moment you picture it.
Now swap the house for a digital product, a customer channel, or a full business transformation. In a lot of companies, work moves from strategy straight to data models or UI-level design. The layer in between, the one that defines the big picture, gets skipped without anyone noticing.
It's not that teams are careless. The strategy gets set at a high level, the pressure to show progress is real, and detail work feels productive because concrete things start appearing on screens and in tickets. The missing layer doesn't announce itself. It just quietly isn't there, and nobody has the vocabulary to say "wait, we're jumping from strategy to details without the structure in between."
That missing layer has a name. It's called concept design. Most companies that skip it aren't dismissing the idea. They've simply never seen it done well, so they don't know what they're missing.
The layer that's supposed to sit between strategy and execution
Strategy tells you where you're going and why. Execution tells you what to build, line by line, field by field, screen by screen. Between those two there's a layer that answers a different set of questions:
- What are we actually trying to achieve, what change are we aiming for, and what stays the same?
- What is the big picture we're actually creating?
- How do the parts relate to each other?
- Which parts are load-bearing and which are decorative?
- What order do we build things in, and why that order?
- What does "done" look like at each level?
- Which internal stakeholders need to agree on what, before we commit?
Concept design is the layer that answers these. It's structural work. It's the architectural drawings for what you're about to build.
In most organisations, when people hear "concept design" or "architecture", they think technical architecture: software components, data models, integrations, infrastructure. That's one of the three perspectives concept design should cover, and it's the one teams jump into first. The other two almost always get skipped.
The second perspective is the business one. How does value get created, delivered, and captured? What processes and what operating model sit behind the thing you're building? Who does what, and where does the money come from? The third perspective is the customer and user one. What is the actual experience, what job does it do for the person using it, and how does it fit into the rest of their day?
A good concept design holds all three perspectives at once and makes them fit together. When teams skip straight to software architecture, the technical layer ends up clean and the business and customer layers get bolted on later. That's exactly when things stop fitting. The engineers and designers downstream are guessing at what the strategy meant, and the people who wrote the strategy are surprised by what eventually shows up in production.
This is not a PowerPoint exercise. Concept design is concrete. It produces artefacts the team can argue over and change before anything expensive happens.
Concept design works at five very different scales
Concept design is hard to recognise because it looks completely different depending on the scope of what you're designing. The role it plays is the same at every scale.
Scale one: a single product or a product area. This is the version most people have seen. You're designing a new feature, a new service, or a new product from scratch. Concept design here answers: what is the customer problem, what is the shape of the solution, how does it fit into the existing product, what does the core flow look like, what are the main screens or touchpoints, what is the data and business logic behind them. The artefact might be a service blueprint, an interactive prototype, or a concept deck. The scale is weeks, sometimes a few months.
Scale two: a new business opportunity. Here the question isn't "what feature do we add" but "is there a whole new business worth building." Concept design at this scale answers: who is the ideal customer, what is the problem and the value proposition, what does a Lean Canvas for this look like, what would the customer journey be end to end, what does the delivery model look like, which organisational capabilities need to exist for this to work, who owns what across functions, how do different parts of the organisation need to collaborate to actually get it to market, and, most importantly, how do we validate the whole business model cheaply enough that we know it's worth building before we commit to building it. The artefact is usually a combination: a Lean Canvas, an ICP definition, a journey sketch, a delivery and operating model outline, and a validation plan with the riskiest assumptions mapped. The scale is weeks to a few months, and the output is a go/adjust/stop decision on the opportunity itself.
Scale three: a product ecosystem with customer journeys and business processes. Now you're designing something larger: a full customer experience that spans multiple products, channels, and internal teams. Concept design at this level answers: what does the end-to-end customer journey look like, how do products connect, which business processes support each stage, who owns what, where do handoffs happen, what does the operating model around it look like. The artefact might be a journey map with supporting process maps, an ecosystem diagram, or a set of interlocking blueprints. The scale is months.
Scale four: a full business transformation. This is the version almost nobody has seen, because only a small number of organisations ever do transformations large enough to need it. Concept design at this scale answers: what is the core system renewal we're committing to, what is the new customer channel that goes with it, what are the hundred-plus business processes that need to change, what is the new operating model, what are the business goals and metrics that justify the whole thing, what changes and what stays the same, and in what order does it all happen. The artefact is not one document. It's a coordinated set of concept artefacts, one per layer, tied together by a shared target state. The concept design work itself takes somewhere between six months and a year. The transformation that follows can easily stretch over several years once it moves into execution.
Scale five: a cross-organisational or planetary system. All of the scales above sit inside a single company. Concept design doesn't stop there. It can also happen between organisations, across an ecosystem of companies that need to work together, or between nation states tackling a shared problem. Picture a shared payments infrastructure that has to function across multiple banks, regulators, and fintechs. Or a cross-border health data exchange. Or the coordination model that lets countries, cities, private companies, and civil society act together on climate change. At this scale concept design answers: who are all the actors, what is the shared goal, what does each party contribute and get back, what are the shared rules and standards, where do the interfaces sit, how do decisions get made when no single party is in charge, and how does the whole system evolve over time when the participants keep changing. The artefacts are shared target pictures, governance models, interoperability standards, and coordination frameworks. The scale is years to decades, and the work rarely has a single owner. That's exactly why explicit concept design matters even more here than at smaller scales.
The underlying logic is the same at all five scales. You start from the goals: why are we doing this at all, what outcome are we trying to create, and for whom. From there you define the big picture, then the structure, then the layers, and then you refine each layer downward until you reach the level of detail the work actually needs. The bottom layer looks different depending on what you're designing: code and data for a software product, process steps and role descriptions for a transformation, shared standards and interfaces for a cross-organisational system. The scales differ only in how many layers there are, what kind of detail sits at the bottom, and how much is at stake.
Back to the house. This is why the analogy matters.
When you build a single house, you need a site plan, a floor plan, structural drawings, HVAC and electrical layouts, and an interior plan. Those are the layers. Each one sits on top of the previous one. You can't do the electrical layout before you know where the walls are, and you can't put up the walls before you know which way the house faces on the plot.
When you build an apartment building, you need all of those layers, plus things that don't exist at single-house scale: shared infrastructure, fire safety systems, common spaces, accessibility routes, waste management, and the legal structure of shared ownership. The layers don't disappear. There are just more of them, and they depend on each other in more complicated ways.
When you build an entire neighbourhood, you need everything from the apartment building scale, plus road networks, public transport connections, schools, parks, water and power grids, zoning regulations, and a plan for how the whole thing grows over time. You're no longer designing a single object. You're designing a system of objects that have to work together.
At every scale, no builder starts work before the plans exist at the right level of detail for what's being built. And at every scale, the plans are made in a specific order: site first, then structure, then systems inside the structure, then finishes. Trying to do them in a different order makes the later plans impossible.
Now map this onto digital development.
- Building one house ≈ designing one product or product area
- Building a small cluster of new houses on an empty plot ≈ shaping a new business opportunity, where the infrastructure and the business model have to be designed together
- Building an apartment building ≈ designing a product ecosystem with journeys and processes
- Building a whole neighbourhood ≈ designing a full business transformation
- Planning an entire city, or coordinating several cities and countries around shared infrastructure ≈ designing across organisations, ecosystems, or nation states on problems no single actor owns
The digital equivalents of site plan, floor plan, structural drawings, and HVAC exist too. They just don't have agreed names in most organisations, which is half the reason they get skipped. When nobody has a shared word for the thing, nobody notices it's missing.
What actually gets skipped when there's no concept design
In practice, what I see most often is that teams jump from a strategy document directly into some detail-level layer, depending on which discipline grabs the work first. The specific layer varies. It might be data modelling, UI wireframes, a backend service design, a process map, an integration spec, or something else entirely. The pattern is the same: a team picks one detail layer and starts building from there, without the structural layer above it.
A couple of common examples:
One is jumping straight into data modelling. Someone starts sketching tables, entities, and fields, based on an assumption about what the product needs to store. The data model then drives everything downstream, and by the time anyone asks "is this actually the right structure for the customer experience we want," it's too late to change without rebuilding.
Another is jumping straight into UI wireframes. Someone starts designing screens and fields, based on an assumption about what the user needs to see. The screens then drive everything, and by the time anyone asks "does this actually connect to our business model and our processes," the design has already shaped how developers think about the system.
These are just two examples. The underlying issue is the same whichever detail layer the team starts from: skipping concept design means skipping the layer where you would have noticed that the different parts of the system were making incompatible assumptions about the business. Without it, the incompatibility shows up later, in production, and costs a lot more to fix.
The benefit nobody counts
Everyone talks about the cost of doing concept design. Very few people count the cost of not doing it.
The visible cost is time spent upfront on work that doesn't produce code. Two weeks, four weeks, sometimes more depending on the scale. This is the cost leadership sees, and it's the cost they instinctively want to cut.
The invisible cost, the one that dwarfs the visible one, is the back-and-forth in execution. When there's no shared concept, every decision during the build becomes a debate. The developers and the business stakeholders disagree about what something means, because nobody ever agreed on the definition. Features get built and then rebuilt because someone further up the chain "didn't realise it would work that way." Rework piles up, releases slip, and the team eventually gets tired and cynical.
In the worst cases, the ones I've personally watched inside large organisations, this back-and-forth can eat a year of calendar time and millions of euros. The teams were skilled. The problem was that they were all trying to build on a foundation nobody had agreed on, so every decision turned into another round of negotiation.
A good concept design doesn't eliminate debate. It moves the debate to the right moment: early, while the cost of changing your mind is low. That's the whole point.
Why I keep writing about this
I've done concept design at all five scales. Single product concepts for startups and product teams. Ecosystem-level concepts for large financial services projects. A full business transformation concept covering a core system renewal, a new customer channel, more than a hundred business processes, and a new operating model, with goals, metrics, and a clear definition of what was changing and what was staying the same.
I've watched what happens when the concept layer is there, and I've watched what happens when it's missing. The difference is not subtle. It's the difference between a project that lands roughly on time and budget, and one that spends eighteen months in execution purgatory trying to agree on what it was supposed to be.
That's why I keep coming back to this topic. Concept design is the least-sexy, least-understood, highest-leverage part of the whole development process. And it's the part most organisations don't even know they're skipping.
I'm Jenni. Most strategies stay vague. I help organizations define what their strategy actually means in practice, then build the operating models, processes, and concepts to execute it. Founder of Digital Rebel.