The Three-Horizon Vision Worksheet

Use this skill when a technology leader wants to write (or rewrite) a real technology vision instead of a "mood board" roadmap slide — one built around the Native Alpha their company actually owns, with horizon lengths sized to how fast their specific…

Download SKILL.md

This skill is Labor as Code™ for "Native Alpha: How to Find Out What Business You're In" in The Code Takes Care of Itself. Read that chapter for the reasoning — the book's own worked examples (a mid-market logistics SaaS company and a clinical-documentation company, both fictional composites built to illustrate opposite answers) show the method applied twice, not the answer to copy. This skill runs the worksheet. The underlying facts - what the user's company's real advantage is, how fast their market actually moves - have to come from the user's own knowledge; this skill has no access to them and won't invent plausible-sounding substitutes. But once those facts are on the page, Step 4's position choice is a synthesis this skill states directly, with its reasoning traced to specific Step 2 inventory entries - not a question handed back unanswered.

Per this imprint's shared glossary: Native Alpha is the differentiated advantage that already exists — in a company, a customer, a team, a product, a data asset, a relationship, or a person — that a well-funded competitor would find genuinely hard to copy. This worksheet only works if Step 2's inventory is built from real, specific assets this organization actually has, not aspirational ones a competitor could match in eighteen months.

Before running

This is roughly a week of real work, not a single sitting. The book runs a version of it with every CTO in the first thirty days of an engagement. Set that expectation with the user up front.
Step 1 and Step 2 need real inputs the skill cannot supply. What the business actually sells, which metrics the board actually watches, and what specific assets the company owns that a competitor can't easily reproduce — these have to come from the user's real knowledge of their company (or real interviews with executives, salespeople, support engineers, and frontline operators), not from this skill's own plausible-sounding guesses. If the user doesn't know an answer yet, say so and flag it as a gap to fill before the worksheet can proceed past that item — don't invent a placeholder that looks finished.
Confirm the answer to the clockspeed question before drafting any horizon. Everything about how long Horizon 2 and Horizon 3 run depends on one real-world fact: how long would a competent, well-funded new entrant need to become a credible threat to this company's largest account? That answer comes from the user's knowledge of their actual buyers' switching costs, not from a general sense of "our industry moves fast."

Steps

1. Business grounding

Answer each of these in plain language — the words you'd use with a smart friend outside the industry, not internal jargon. Beside each answer, note where it came from: an outside source (industry research, a competitor's earnings call) or a specific person inside the company who confirmed or corrected it.

What does this business sell, and who buys it?
Which two or three metrics do the CEO and the board actually watch?
What is the largest external threat to this business in the next three years — a competitor, a market shift, or a regulatory change?
What would the CEO name, without prompting, as the company's largest current constraint?
How long would a competent, well-funded new entrant need to become a credible threat to your largest account? Answer in months or years. This single answer sets the length of every horizon below — treat it as the most important line on the page.

2. The inventory — name specific assets, not general strengths

Every later step depends on this one being concrete.

What does this company have that competitors don't? Consider data, expertise, relationships, workflows, regulatory permissions, reputation, distribution, and market position.
Why is each one hard to copy — time, trust, accumulation, regulation, or a combination of people nobody else has hired? If money alone could reproduce it in eighteen months, cross it off.
Why does it matter to customers? If you can't connect an asset to why customers pay, set it aside until you can.
Where is it underexploited today — known to one department, sitting in a system nobody queries, living in one veteran's head? Which parts are exposed — dependent on one person, one contract, or one dataset the company doesn't control?
What could technology let the company know, see, decide, or do with it that competitors cannot?
What will the company deliberately not build, because it strengthens none of the entries above? Write these down — they shape the budget as much as anything the company does build.

3. The twelve-month horizon

One sentence per question. Not a paragraph.

What must ship in the next twelve months to move the Step 1 business metrics in the right direction?
Which technical debt gets paid down, which gets deferred, and why is that the right sequence?
Which capability must the team build or hire this year that it doesn't have today?
Twelve months from now, how will someone outside engineering know the technology organization is winning?
Which of this year's work is commodity to buy or generate, and which is differentiated work that earns senior engineering attention because it encodes an entry from Step 2?

4. The position horizon

Use the clockspeed answer from Step 1 to set the length, not a default. If a credible new entrant needs years, write the position horizon at three years. If a credible new entrant needs months, write it at eighteen to twenty-four months — the longest bet worth committing budget and hiring to at that speed. Answer with a position, not a feature list.

Which kind of technology organization does this become? State this skill's recommended primary choice - speed, reliability, scale, compliance, or cost efficiency - with the Step 2 inventory entries and Step 1 business-grounding answers that support it; you cannot optimize equally for all of them, so the reasoning has to say why this one beats the others given what the company actually has. Where two positions are both genuinely supported by the inventory (for example, a company with both a compliance asset and a speed advantage, neither dominant), name both as live options and what additional evidence - a customer segment's actual buying criteria, a board metric - would resolve which one the company commits to.
For that position to be credible by that date, what has to be true about the architecture, the team structure, and the vendor relationships?
Which customer expectation will exist by that date that doesn't fully exist today, and does the company start building toward it now?
Which entry from the Step 2 inventory does this position rest on? If the honest answer is none, this is a preference, not a position — go back and connect it, or drop it.

5. The long horizon

The least specific step and the one most leaders get wrong before writing a word, because they get its length wrong. Use the Step 1 answer again:

If a credible new entrant needs years, write a real five-year horizon and commit to it.
If a credible new entrant needs months, don't write five years as a plan. Run it instead as a one-afternoon thought experiment, with no document and no commitments, whose only output is which assumptions the user has quietly been treating as permanent facts.

Either way:

Which capability gap separates the organization today from the organization it must become by that date?
What's the smallest first step that closes that gap this year, taken before anyone can prove the bet is correct?

6. The translation test

Explain the result to three audiences in under two minutes each: a board member, a new engineer on the team, and a customer. If any explanation needs jargon the listener wouldn't already know, the vision isn't finished — it's still a technical preference that hasn't become a business argument. A vision that can't be explained to a customer in plain language isn't customer-first, whatever else it claims to be.

Ongoing checkpoints (not a one-time exercise)

Review the twelve-month section monthly.
Stress-test the position and long-horizon sections against real events at least twice a year.
At every checkpoint, ask one more question: what can the company know, see, decide, or do this quarter that it couldn't a year ago, and that competitors still can't? If the honest answer is nothing for two checkpoints running, the technology organization has been doing commodity work efficiently, and the strategy itself needs revisiting, not just the roadmap underneath it.

The check that catches this book's own failure mode

The "mood board" test. If this vision would sound equally at home at a different company in a different industry, it isn't a vision — it's a slide with buzzwords stacked to look like a roadmap. Every horizon should be specific and falsifiable enough that reality can contradict it.
The horizon-length test. Confirm Horizon 2 and Horizon 3 were actually sized from the Step 1 clockspeed answer, not defaulted to "three years and five years" out of habit. Writing a five-year plan for a company in AI Time is false confidence dressed as foresight.
The inventory-trace test. Every claim in the position horizon (Step 4) should trace back to a specific line in the Step 2 inventory. A position with no inventory entry behind it is a preference wearing strategy's vocabulary.
The stated-recommendation test. Step 4's position choice should read as this skill's own reasoned recommendation, not a question bounced back to the user - or, where the inventory genuinely supports two positions about equally, both should be named as live options with what would resolve the tie, rather than one arbitrarily picked to finish the worksheet.