Building Capability

Chapter 2: What You Actually Have (And What You Don't Know You Have)

Before you read — by the end of this chapter you will understand:

Why most organisations massively underestimate the intellectual property they already hold

The franchise prototype concept and why it’s the most useful mental model for surfacing hidden value

How to recognise capability that’s trapped in spreadsheets, people’s heads, and informal workarounds

Why formalising what you know is the essential first act of any capability-building programme

Here’s something I’ve noticed over and over again, across dozens of organisations, across almost every industry I’ve worked in: the people running the business are almost always the last ones to see how valuable what they do actually is.

Not because they’re not smart. They’re usually very smart. They’ve built something real, with real customers and real results.
But they’re so close to it, so inside the day-to-day of it, that what they do has become invisible to them. It’s just how things work here. It’s background noise. It’s the thing they stopped noticing years ago because they stopped having to think about it.

And sitting right there, inside all of that background noise, is usually an extraordinary amount of intellectual property. Proven knowledge. Hard-won process. Expertise that took years, sometimes decades, to build. Worth far more than most people in that room have ever considered.

The first job of capability building is making the invisible visible.

The Catalog Consultant Who Didn’t Know What He Had

I worked with a specialist catalog planning consultant, someone who had spent years developing deep expertise in how major retailers should allocate space, sequence products, and time seasonal ranges to maximise the return on every page of a printed catalog.

His clients were serious businesses: major retailers who understood that every square centimetre of catalog space represented a financial decision. He had built tools, spreadsheets mostly, that could analyse gross margins, net profits, stock levels, and customer response patterns across multiple publication cycles to tell a client exactly where to place what product, and when.

What took a junior analyst weeks of SQL queries and data manipulation took him a fraction of the time, with meaningfully better output.

He’d been doing this for years. It was just how he worked.

When I first sat with him and looked at what he’d built, it became clear that what he had wasn’t a set of working tools. It was a productised methodology. Years of accumulated pattern recognition, encoded into something that could be used to serve multiple clients simultaneously, without him being personally in the room for every analysis.

He hadn’t seen it that way. It was just his process. His shortcut. His way of doing things faster than the next person.

That’s the thing about intellectual property that lives inside organisations. It doesn’t announce itself. It hides in spreadsheets, in people’s heads, in tribal knowledge that the longest-serving person carries and nobody else can fully replicate. You don’t find it by asking “what do you want to automate?” You find it by asking “what do you do that nobody outside this organisation can do as well as you?”

The catalog consultant’s answer to that question was everything. The platform we built together allowed him to serve far more clients than his personal time permitted, and allowed those clients to access his expertise without requiring his direct involvement in every routine analysis. The knowledge that had been locked inside one consultant’s head became a scalable business.

The Franchise Prototype

There’s a concept I come back to again and again when I’m helping organisations understand what they actually have. It comes from Michael Gerber’s E-Myth: the idea of the franchise prototype.

The argument is this: even if you never intend to franchise your business, the most valuable thing you can do is design it as if you were going to.

Think about what franchising actually requires. To hand a business model to a stranger in another city and have them succeed with it, you have to have automated or documented everything. Every process, every standard, every decision rule. You have to have removed the business from dependence on any single person, including, and especially, yourself. The whole system has to be legible, transferable, and repeatable.

Most businesses are the opposite of that. They’re deeply dependent on the knowledge, relationships, and instincts of the people who’ve been there longest. The longer someone has been there, the less they know how to explain what they do, because they’ve long stopped thinking about it explicitly. It just happens. Automatically. In their head.

The franchise prototype exercise is a forcing function. It asks: if you had to hand this business to someone else tomorrow and have them succeed with it, what would break?

The answer to that question is almost always the same: everything that hasn’t been written down, documented, or systematised. Every piece of knowledge that lives only in someone’s head. Every process that depends on one person knowing the right workaround.

And when you start listing those things out, all the things that would break, you start to see something remarkable. You start to see the actual shape of the business. Not the org chart, not the website, not the pitch deck. The real thing. The knowledge that powers it. The expertise that makes it work.

That’s what you have. That’s what you’re building with.

What’s Actually Trapped in Your Organisation

Let me be more specific, because I find that organisations tend to carry certain types of hidden IP in predictable places.

In the heads of long-tenure staff. The person who’s been there twelve years knows things that aren’t in any document. They know why certain clients need to be handled a particular way, which supplier has a quirk that causes problems if you don’t follow the right sequence, how to read the numbers to spot a problem three months before it shows up. When that person leaves, a significant portion of organisational capability goes with them. Building it into systems is not about replacing them. It’s about protecting what they’ve built.

In spreadsheets. Almost every organisation I’ve worked with has at least one spreadsheet that is absolutely critical to operations and absolutely terrifying to anyone who has to maintain it.

These spreadsheets are often extraordinary pieces of work: years of logic, refinement, and domain knowledge encoded into formulas and tabs. They are also completely brittle, usually undocumented, and deeply vulnerable to version drift.

In informal processes. The way work actually gets done in most organisations has very little to do with the official process documentation, assuming any exists. The real workflow is a series of adaptations, shortcuts, and informal agreements that evolved because the official process didn’t quite work.

These informal processes often represent the best thinking in the organisation, the result of real problem-solving under real conditions. But they’re invisible and unmeasured.

In the quality of decisions. Senior people in an organisation make hundreds of small judgement calls every day. Most of those calls are never documented or explained. They just happen.

Over time, those decisions compound into a kind of organisational wisdom. The problem is, it only lives in those people. If you can capture even part of the logic, the criteria, the rules of thumb, the heuristics, you can start to distribute that wisdom more widely.

Formalising What You Know

Here’s the thing about all of this hidden IP: it only becomes an asset when it’s formalised.

Knowledge in someone’s head is a person-dependent liability. Knowledge that’s been articulated, documented, and built into a system is an organisational asset. The difference between the two is profound, both in terms of operational resilience and in terms of the value the business represents to anyone thinking about acquiring it, investing in it, or scaling it.

I’m not talking about writing procedure manuals that nobody reads. I’m talking about understanding what you know well enough to build it into the way the organisation operates, into its tools, its training, its onboarding, its quality control.

That process of formalisation is the first real act of capability building. Not because the documentation itself is the goal, but because you can’t build on something you haven’t defined yet.
You can’t systematise knowledge you haven’t articulated. You can’t train a new hire into expertise you can only pass on by having them sit next to someone for six months.

The question I ask clients at the start of every engagement is a simple one, and it always produces a long, productive conversation:

What do you know how to do that your competitors don’t? What do you know that your staff don’t?

Not what do you do differently. Not what’s on your website. Not what you say in a pitch. What do you actually know? What have you worked out, through years of doing this, that gives your clients better results?

The answer to that two-part question is the foundation of everything.

From Asset to Competitive Position

Formalising what you know is not just an operational exercise. It is the first step toward becoming genuinely hard to compete with.

Consider two organisations. Both serve similar clients. Both have smart people. Both have been doing what they do for a long time. One of them has captured its expertise, turned it into systems, tools, and documented processes that can be applied consistently and extended over time. The other carries that expertise entirely in the heads of its senior staff.

The first organisation can onboard a new client faster. It can bring a new team member up to speed in weeks rather than years. It can apply its best thinking to ten clients simultaneously, not just the ones the senior partner happens to be working with this month. And critically, it can build on what it knows, taking that foundation and using technology to deliver its expertise in ways that were previously impossible.

The second organisation is permanently constrained by how many hours its best people have available.

That is the difference formalisation makes. Not better filing. Not more thorough documentation. A fundamentally different competitive position.

The News Ltd case study illustrates this at the larger end of the scale. The knowledge about how a newspaper operates, the relationship between advertising sales, editorial space, press configuration, and financial profitability, existed in that organisation for decades. Editors knew it. Finance knew it. Production knew it. But each department knew only their piece of it, and they knew it in ways that weren’t connected.

When that knowledge was formalised into a single platform, a live model of the newspaper that every department worked from simultaneously, it didn’t just make things more efficient. It changed what was possible.

Finance could see forward weeks ahead rather than looking back two months after the fact.
Sales could search available space across every title and every edition for the next six months.
A single ad booking by a salesperson would ripple through layout, press configuration, editorial space, and financial projections in under a second.

That is not automation of an existing process. That is a capability that did not previously exist.

At the other end of the scale, Lilydale Books, a family business supplying textbooks to Victorian schools, had deep knowledge of how schools ordered, what parents needed, and how the annual back-to-school period actually worked.

That knowledge lived with Ayesha and her team. When it was formalised into a system, it became something else entirely: a platform that allowed families to complete the entire school onboarding process online, that freed teachers from booklist administration, and that positioned a small family business to compete on client experience with much larger players who had generic catalogues and no real understanding of the schools they served.

Both of those outcomes started with the same question: what do you know that your competitors don’t?

The answer was the foundation. Everything else was built on top of it.

What This Means for the Work Ahead

The reason I spend time on this at the beginning, before we talk about technology, before we talk about processes, before we talk about any of the frameworks that will come later in this book, is because building capability without understanding what you already have is like building a house without looking at the land.

You might build something technically impressive. But it won’t be grounded in the thing that makes your organisation distinctively valuable. It won’t leverage the knowledge that took you years to accumulate. It will be generic, replicable, and ultimately not very defensible.

The organisations that build real capability, the kind that compounds over time, the kind that opens up strategic options they didn’t have before, start by taking stock of what they already have.

Then they build from there.

Tool: The Business Landscape Map

Before you start thinking about what to build, you need a shared picture of how your business actually operates, not how it’s supposed to work on paper, but how it really works day to day. This tool creates that picture in two layers.

The Base Layer

Draw a diagram of your operation using this orientation:

Top — your customers (by type or segment, not individual names)
Centre — your operation, mapped by role rather than individual people. One person can hold more than one role; show that. Focus on the roles that touch the work.
Sides — your systems and virtual elements: software platforms, spreadsheets, databases, tools, and any automated processes
Bottom — suppliers, partners, subcontractors, regulators, government agencies, and any third parties whose actions affect how you operate

Use a whiteboard, sticky notes, or a shared digital canvas. The goal is a picture that anyone in the business can read and immediately see where they fit.

Allow 60–90 minutes. Include at least one person from each part of the operation.

The Process Overlays

Once your Base Layer is complete, place a transparent layer over it for each significant business process. On each overlay, trace a single process from trigger to outcome.

Every process starts with one of two things:

A customer action (an enquiry, a booking, a purchase, a complaint)
A timing event (end of month, a scheduled review, a recurring obligation)

For each process, trace:

Which role takes action at each step
Which system is involved, where does information go, what gets updated
What the customer experiences at each stage
Where third parties are involved
Where decisions require someone’s judgement (not just a step to follow)
Where responsibility passes from one person or system to another

Start with these four processes:

New client onboarding
Core service delivery
Invoicing and financial close
Client handover or offboarding

What You’re Looking For

Once you have the Base Layer and two or more overlays, look at the whole picture together. You are looking for:

Concentration risk — too many critical steps sitting with one person
System gaps — steps done manually that a system could support
Handoff friction — where things slow down, get lost, or require chasing
Decision bottlenecks — where work waits for a senior person to make a call
Hidden knowledge — where a step relies on someone knowing something that isn’t written down anywhere. That’s your intellectual property, and it’s at risk.

This map becomes the input for everything that follows. It’s what you’re building from.

Want to go deeper?
The full Business Landscape Mapping Kit includes a facilitated workshop guide for building the Base Layer and Process Overlays with your team, a library of trigger types and process templates for common business functions, a structured analysis framework for identifying the highest-priority improvement areas, and a guide for translating your map findings into a capability-building brief.
Available in the members area at [website]

Tool: The Hidden IP Audit

Before you start thinking about what to build, you need to know what you have. This short audit helps you surface the intellectual property that’s already in your organisation, the knowledge, processes, and expertise that most businesses have never properly named.

Allow 45–60 minutes. Do this with two or three people who between them know the business well.

1. The franchise prototype test
If you had to hand this business to a competent new owner tomorrow, what would break in the first week? List the knowledge, processes, and decisions that currently exist only in people’s heads.

What would break / Who holds it

2. Where is expertise locked in individuals?
Think about your longest-serving team members. What do they know that nobody else does? What would disappear if they left?

Person or role / What they know that isn’t written down anywhere

3. Where is knowledge trapped in spreadsheets?
List any spreadsheets that are critical to operations, especially the ones that would be a problem if the person who built them weren’t available.

Spreadsheet / What it does / Who understands it

4. What do you know that your competitors don’t?
This is the core question. Not what you do differently on paper, but what have you genuinely worked out, through years of doing this, that gives your clients better results?

Write it down. Even if it feels obvious. Especially if it feels obvious.

5. What do you know that most of your own staff don’t?
The expertise that lives only at senior level, the judgement calls, the rules of thumb, the things that take years to develop.

What it is / Why it’s not more widely held

What this tells you:
The things you’ve written down are the foundation. They’re what any capability build should be designed around. If a system doesn’t encode or leverage any of this, it’s not building capability. It’s just adding tools.

Want to go deeper?
The full version of this tool, the Hidden IP Audit, includes a facilitated workshop format for extracting and mapping your organisation’s IP across all four hidden categories, a guide for prioritising which knowledge to formalise first, and a template for turning what you find into a capability-building brief.
Available in the members area at [website]