How to Document a Proprietary Methodology

The hardest part of scaling expert work isn't packaging it or marketing it. It's capturing it. Most methodologies live in the practitioner's judgment — accumulated through years of client work, refined through iteration, shaped by pattern recognition that has become intuitive.

Converting that judgment into explicit, transferable knowledge is where most documentation efforts stall. Not because the method isn't there — it is — but because making it legible to someone who doesn't share its creator's context is genuinely difficult work.

This article explains what documentation actually needs to capture, where most efforts go wrong, and how to approach the work in a way that produces something useful.

Why Documentation Is So Hard

Expert practitioners suffer from what cognitive scientists call the curse of knowledge: the more expertise you have, the harder it is to remember what it was like not to have it. What feels obvious to you is invisible to someone encountering the method for the first time.

This means that self-documentation — founders writing down their own methods — almost always produces documentation that is useful to people who already understand the method, and opaque to everyone else. The gaps aren't visible to the person who fills them automatically.

Good methodology documentation requires an outside perspective: someone asking the questions that reveal the assumptions the founder doesn't know they're making.

What Documentation Actually Needs to Capture

Methodology documentation is not a user manual. It is not a slide deck or a process flowchart. Those artifacts may be useful — but they are outputs of documentation, not documentation itself.

A complete methodology documentation captures four things:

1. 01Principles — the underlying logic that explains why the method works. What is it about human behavior, organizational dynamics, or the problem being solved that makes this approach effective? Principles are the reason the steps exist.
2. 02Process — the sequence of phases, steps, or components that define how the method is delivered. What happens first? What follows? What are the decision points?
3. 03Decision logic — the judgment calls practitioners need to make, and the criteria for making them. This is the hardest part to capture and the most important. What does a practitioner do when X happens? How do they know when to adapt and when to hold to the standard approach?
4. 04Boundaries — what the method is not. What problems does it not address? What client situations is it not designed for? What adaptations are permitted and which compromise the method's integrity?

The Four Layers of a Methodology

Think of a methodology as having four layers, each requiring different documentation work:

Layer 1: The Conceptual Framework

The mental model that explains why the method works. This is what a practitioner needs to understand before they can apply the steps correctly. Without the conceptual framework, practitioners follow the process mechanically — and miss the judgment calls that make the method effective.

Layer 2: The Delivery Process

The structured sequence of activities that constitutes delivering the method. This is what most documentation efforts focus on — and it's the least sufficient layer on its own. A process without principles produces practitioners who know what to do but not why, making them brittle when conditions don't match the template.

Layer 3: The Decision Architecture

The map of choice points practitioners encounter and the criteria for navigating them. This is where expert judgment lives — and where documentation almost always falls short. Capturing decision logic requires observing practitioners at work, surfacing the questions they ask themselves, and making the criteria explicit.

Layer 4: The Calibration Signals

The indicators that tell a practitioner whether the method is working, whether they're on track, and when something has gone wrong. These are often the least explicit part of a founder's knowledge — they know what success looks and feels like, but haven't articulated it in terms a new practitioner can use.

Common Documentation Mistakes

Most documentation projects fail for the same reasons:

• Documenting outputs instead of logic — describing what to produce rather than how to think about producing it
• Skipping the principles layer — producing a step-by-step process with no explanation of why the steps exist
• Writing for someone who already understands the method — failing to include the context a new practitioner actually needs
• Conflating documentation with curriculum — writing a training course instead of capturing the method itself
• Treating documentation as complete when it's been written — real documentation is validated by testing it against someone who doesn't already know the method

Where to Start

The most effective place to start is not at the beginning of the method. It's at the most common decision point — the moment in delivery where a practitioner's judgment matters most, where the gap between an expert and a novice is most visible.

Start there. Ask: what is the practitioner deciding at this moment? What information are they using? What would a wrong decision look like, and why would someone make it? What does the expert know that the novice doesn't?

Answering those questions honestly produces documentation that's actually useful — because it captures the judgment, not just the sequence.

When Documentation Is 'Done'

Documentation is never fully complete — the method evolves, new edge cases emerge, and calibration improves with each practitioner cohort. But documentation is done enough to support certification or delegation when:

• A practitioner who has never worked with you can read it and produce work you'd recognize as consistent with your method
• You can design an assessment that tests meaningful competence against the documented standard
• The decision logic is explicit enough that a practitioner can explain their choices — not just make them
• The boundaries are clear enough that a practitioner knows when they've gone out of scope

If documentation can't pass those tests, it isn't finished — regardless of how long it is or how thorough it feels to the person who wrote it.