Building Capability
Chapter 4: Thinking Big Before You Build Small
Before you read — by the end of this chapter you will understand:
- Why the full picture must come before any build decision
- How to hold ambition and pragmatism at the same time — without losing either
- The danger of “just starting” without a destination in mind
- The danger of endless planning - and why untested assumptions are the most expensive kind
- How early architectural decisions either open or close future strategic options
There’s a tension I see in almost every organisation that’s serious about building capability.
On one side, the voice of ambition. Let’s think about what this could really become. Let’s map the full opportunity. Let’s not constrain ourselves before we’ve even started.
On the other side, the voice of pragmatism. We’ve got a business to run. We can’t spend six months planning. We need to show something. Let’s just start.
Both voices are right. That’s what makes it genuinely hard.
The organisations that build remarkable capability — the ones who look back five years later and can’t quite believe where they’ve arrived — those are the ones that learned how to hold both voices at once. They didn’t let ambition become paralysis. But they also didn’t let impatience destroy the foundation.
This chapter is about how to do that.
The City Planning Problem
I use this analogy constantly, so you’ll hear it more than once in this book. It comes from the difference between building a bridge and building a city.
A bridge has a defined purpose, a defined endpoint, and a finite scope. You can plan it completely, build it, and call it done. It either holds the load or it doesn’t. There’s a clear success condition.
A city is nothing like that. A city is never finished. It grows, it changes, it develops in directions nobody planned for. The decisions made in the early stages — where to put the roads, where to run the water and sewage, how to zone the land — those decisions constrain or enable everything that comes after. You can’t run a freeway through a densely built suburb after the fact. You can’t retrofit modern data infrastructure into a city centre built before electricity. The early decisions compound.
Building a technology capability for an organisation is like planning a city, not like building a bridge.
The technology you choose today, the data structures you establish, the architecture you build on — these are the roads and water pipes of your digital city. Get them right and everything that comes after is cheaper, faster, and easier to build. Get them wrong and you spend years working around them, regretting them, or eventually tearing them out at enormous cost.
This is why thinking big first is not a luxury. It’s an investment in every decision that follows.
What “Thinking Big” Actually Means
I want to be specific here, because “thinking big” is one of those phrases that sounds inspiring and means nothing if you don’t define it.
Thinking big, in this context, means three things.
First: Understanding the full potential of your IP.
Before you decide what to build, you need an honest view of what the intellectual property at the core of your organisation could actually become — across all three horizons from the previous chapter. Not what you think is realistic given your current constraints. What could be true if you had the right tools, the right team, and the right architecture?
This doesn’t mean committing to all of it. It means seeing it.
Second: Understanding the full scope of who you could serve.
Most organisations that come to me are serving a particular slice of the market they could serve. Not because they’ve made a strategic decision to focus there, but because their current model — the way it’s delivered, the cost it requires, the geography it demands — only makes it viable for that slice.
When you’re designing capability, you’re also designing reach. The architecture you build can either lock you into your current addressable market or open up segments you currently can’t reach. That’s a choice worth making deliberately.
Third: Understanding how Horizon One connects to Horizons Two and Three.
The first phase of any capability build should be designed with the second and third phases in view. Not fully planned — like a city things change too much for that. But the foundational decisions should be made with an awareness of where you’re eventually trying to go.
Thinking big doesn’t mean doing everything at once. It means not making decisions today that you’ll regret tomorrow.
The Danger of “Just Starting”
I have a lot of sympathy for the impulse to just start.
Planning is uncomfortable. It produces outputs that are abstract and hard to evaluate. It’s difficult to explain to a board. It doesn’t feel like progress. And there’s a very real risk — especially in organisations that have been “about to do something about technology” for years — that planning becomes a substitute for action.
So I understand why people want to skip it.
But I’ve seen too many organisations pay the price of skipping it.
The most common version of this story goes like this. The organisation identifies a clear and urgent problem — let’s say it’s the manual process of generating reports for clients. They want it automated. They find a developer or a small agency, explain the problem, and commission a solution. The solution gets built. It works. Reports are generated automatically. Tick.
Six months later, they want to add something. They want the system to also capture client feedback and link it to the report data. The developer comes back and explains that the way the report system was built, adding the feedback module isn’t straightforward — it’s going to cost almost as much as the original build.
They pay it. They get the feedback module.
A year after that, they want to give clients a portal — a place where clients can log in and see their own reports and feedback history. The developer explains that neither the report system nor the feedback module was built with that in mind. The data structures don’t support it cleanly. To do it properly, they’d need to rebuild significant parts of what’s already there.
This organisation has now paid three times for a system that, had it been designed once with the full picture in mind, would have cost about the same in total and been a far better result.
I’ve seen this pattern more times than I can count.
The Danger of Endless Planning
The opposite failure mode is just as destructive, and considerably more comfortable.
Endless planning keeps your imagination fed. The vision gets richer, the diagrams get more elaborate, and the possibilities multiply in ways that are genuinely exciting. Nobody has to make a hard decision because everything is still possible. The developers are in heaven - they’re building the most sophisticated, ambitious, architecturally beautiful thing they’ve ever touched, with no end date in sight and no crunch point where reality hits the road.
The problem is that you’ve built a house of cards.
Every plan that has never been tested is a stack of assumptions. Some of those assumptions are correct. Many are not. The dangerous ones aren’t the obviously wrong assumptions - those get spotted early. The dangerous ones are the plausible ones. The ones that seemed so reasonable when the plan was drawn up that nobody thought to question them. Left unchallenged in a planning document, they harden into architecture. They get built into data structures, workflow logic, and integration design. And then, when reality finally shows up - when actual users touch the system, when real data flows through it, when a client does something you didn’t model - one unproven assumption can undermine months of work built on top of it.
The discipline isn’t planning vs. building. It’s knowing what you need to think through before you build, and what you can only discover by building. The first proof of value isn’t just a business win - it’s a reality test. It’s how you find out which assumptions were right.
Plan enough to build the right thing. Build fast enough to find out if you were right.
Holding Ambition and Pragmatism Together
So how do you actually hold both? How do you think big without getting stuck planning indefinitely?
The answer, in practice, is a clear separation between the design layer and the build layer.
Design big. At the design stage, think about the full picture. Map all three horizons. Understand what the ideal end state looks like. Understand the data you’ll need, the integrations that matter, the architecture that will serve you for years. Don’t constrain this by what’s affordable in phase one — that’s a separate conversation.
Build small. Once you’ve got the “full picture”, identify the smallest possible first step that is consistent with the bigger design. Not the simplest thing you can build — the best possible first step toward where you’re actually trying to go.
That distinction matters. The simplest thing you can build might be a standalone system that solves today’s problem and creates tomorrow’s constraint. The best first step toward your actual destination might be slightly more complex, but it points in the right direction and doesn’t close any doors. It also starts to validate your bigger picture.
The organisations that do this well have a roadmap — a living document that shows the full intended capability across all phases, with phase one defined in enough detail to build, and subsequent phases defined in enough detail to make coherent architectural decisions today.
The roadmap isn’t a commitment. Things will change. New priorities will emerge. Phase three might turn into something completely different from what you imagined. But having it — having that view of the whole — means every decision you make today is made in context.
The People Who Get This Right
In my experience, the organisations that navigate this well have one thing in common: leadership that is willing to invest time in understanding before they invest money in building.
Not endless time. Not a year of workshops and strategy decks. But enough time — genuinely enough time — to see the full picture, make the key architectural decisions thoughtfully, and brief the build team with the right context.
That investment in understanding pays back many times over. Not just in the quality of what gets built, but in the speed of subsequent phases, the reduction in rework, and the strategic options that stay open because the foundation was right.
It’s the difference between a road that goes somewhere and a cow path that just goes.
Think big first. Build small second. In that order. Every time.
Tool: The Big Picture Planner (Quick Version)
This tool is designed to be completed before any build decisions are made. It asks you to define the destination first, then work backward to a coherent first step — so that every early decision points in the right direction.
Allow 60–90 minutes. Do this with whoever will own the capability investment, plus someone who knows day-to-day operations well.
1. The end state
Describe your organisation in three years if capability building goes well. What can it do that it can’t do today? Who does it serve? What has it stopped depending on people for?
Write the description — don’t edit yourself at this stage.
2. The full capability picture
Without filtering for cost or feasibility, list everything you can imagine being built. Include all three horizons.
Horizon One (better / faster / less manual):
Horizon Two (new segments / models / reach):
Horizon Three (something genuinely new):
3. The architecture test
What data do you wish you had but don’t currently capture? What existing systems would a new capability eventually need to connect with? Are there any decisions being made today — in your current systems — that would limit what you can build later?
Note anything here that needs to inform the first build.
4. The first step
Given the full picture, what is the smallest meaningful first build that points in the right direction — not the easiest thing, but the best first step toward your actual destination?
First phase description / Value it delivers on its own / How it connects to the larger ambition
5. The ambition check
Am I thinking big enough? And is the first phase genuinely achievable — or have I already let the ambition expand into the build?
Honest answer:
Want to go deeper?
The full version of this tool — the Big Picture Planner — includes a detailed architectural planning template, a franchise prototype workshop format, and a guide for aligning ambition and pragmatism across departments.
Available in the members area at [website]