Fill In the Three-Horizon Vision Worksheet in One Week

The Three-Horizon Vision Worksheet

Companion to The Code Takes Care of Itself · Updated 2026-09-30

This is the full playbook from “Build the Vision on Your Company’s Native Alpha.” The book prints a shorter version at the end of that chapter, and this page keeps every step and every example.

The Three-Horizon Vision Worksheet takes a week. I run a version of it with every CTO and fractional CTO I coach in the first thirty days of an engagement.

  1. Business grounding. Answer these in plain language before you write a single technical goal. Use the words you’d use with a smart friend outside your industry. Beside each answer, note where it came from: the outside source that taught you the industry’s version, and the 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 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 our largest account? Answer in months or in years. That number sets the length of every horizon below.
  2. The inventory. Name specific assets, not general strengths. Every later step depends on this one.
    • What do we have that competitors do not? Consider data, expertise, relationships, workflows, regulatory permissions, reputation, distribution, and market position.
    • Why is each one difficult 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 cannot 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, or walking around in one veteran’s head? Which parts are exposed: dependent on one person, one contract, or one dataset you do not control?
    • What could technology let us know, see, decide, or do with it that competitors cannot?
    • What will we deliberately not build, because it strengthens none of the entries above? Write these decisions down. They will shape the budget as much as anything you do build.
  3. The twelve-month horizon. One sentence per question. Not a paragraph.
    • What must ship in the next twelve months to move those business metrics in the right direction?
    • Which technical debt do we pay down, which do we defer, and why is that the right sequence?
    • Which capability must the team build or hire this year that it does not 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. Three years if Step 1 told you a new entrant needs years. Eighteen to twenty-four months if it told you months. Answer with a position, not a feature list.
    • Which kind of technology organization do we become? Pick one primary choice from speed, reliability, scale, compliance, or cost efficiency. You cannot optimize equally for all of them.
    • For that position to be credible by that date, what has to be true about our architecture, our team structure, and our vendor relationships?
    • Which customer expectation will exist by that date that does not fully exist today, and do we start building toward it now?
    • Which entry from the Step 2 inventory does this position rest on? If the answer is none, you have written a preference, not a position.
  5. The long horizon. The least specific step, the most important one, and the one most leaders get wrong before they write a word, because they get its length wrong. Use your answer from Step 1. If a credible new entrant needs years, write five and commit to it. If a credible new entrant needs months, don’t write five. Run it as a thought experiment and commit to nothing.
    • Which capability gap separates the organization we are today from the organization we must become by that date?
    • What is the smallest first step we can take this year to close that gap? Take it before anyone can prove the bet is correct.
    • If you are in AI Time: which assumptions did that afternoon reveal you have been treating as permanent facts? Those, not the plan, are the output.
  6. The translation test. Explain the result to three audiences in under two minutes each: a board member, a new engineer on your team, and a customer. If any explanation needs jargon the listener doesn’t know, you haven’t finished the vision. You still have a technical preference that hasn’t become a business argument. And a vision you can’t explain to a customer in plain language isn’t customer-first.

Try this with AI.

“You’re a board member who has never written code. I’ll explain our longest technology horizon in ninety seconds. Stop me the first time I use a word you wouldn’t use yourself, then tell me what you think we just committed to and what we gave up.”

Do the worksheet honestly, then run the checkpoints: the twelve-month section monthly, the position and long-horizon sections stress-tested against real events at least twice a year. Then add one more question to every checkpoint, because it is the only direct evidence that the strategy is increasing the company’s advantage rather than just producing output: what can we know, see, decide, or do this quarter that we could not a year ago, and that competitors still cannot? If the honest answer is nothing for two checkpoints in a row, the technology organization has been doing commodity work efficiently, and the strategy needs to be revisited. The document will be wrong in places. Every vision document is, because the future doesn’t hold still for your planning cycle. That’s why this has to be a habit rather than an artifact. The teams I watch struggle aren’t the ones whose long horizon turned out to be partly wrong. They’re the ones that never wrote anything down, and so never noticed the business drifting away from the technology strategy.

Get this right and your days change. You stop being the person your team needs in the room for every decision, because you’ve given them a direction specific enough to make most of those decisions themselves and a standard clear enough to know when they’ve met it. The code starts taking care of itself: the execution, the shipping, the mechanics AI is only going to accelerate further. What’s left for you is the harder and more valuable work: understanding what game this company is playing and what it owns that nobody else does, directing everything AI makes cheap toward strengthening that advantage, and being right about it often enough that your team trusts you to keep deciding.

All of the playbooks are listed on the playbooks page.