Moonshot

Companies mostly decide what to fund with one yardstick: how much goes in, how much comes back, and how sure the answer is. That yardstick works for most decisions. The problem is that a project with a 5 percent chance of success loses every time it is measured against it. Put a project with a 90 percent chance of returning $800,000 next to one with a 5 percent chance of returning $40 million, and even though the expected values are close, the first one wins the room. Backing the second means explaining your judgment when it fails; backing the first means calling it bad luck.

So the same scene plays out everywhere. Someone proposes an idea that would obviously shift the board, and a few months later the idea is gone without anyone having argued against it. Nobody killed it. It simply lost to the safer option at each quarterly budget meeting. That trap has a name — the innovator's dilemma. Every individual decision to protect a healthy business is defensible, and the accumulation of them misses a whole wave.

The word moonshot exists to give this class of project a different name so it can be weighed on a different scale. When Kennedy committed in 1961 to putting a person on the moon within the decade, it was not a plan that had cleared a return-on-investment review. The target was fixed first and the method was worked out afterward. That is where the name comes from.

A moonshot is judged by magnitude, not probability, and that swap is the whole mechanism. Rather than grinding a 5 percent chance up to 20 percent, you ask whether success would be worth as much as the entire existing business. Ten projects that each improve something by 10 percent and one project that changes something tenfold can look similar on a spreadsheet, but the approaches have nothing in common. The first does the current job better. The second removes the premise the current job rests on.

Running one takes three things together.

1. Fix the destination first. Start from what current resources allow and you never arrive at a moonshot. Name the endpoint, then work backward to today.
2. Separate the evaluation. Don't measure it in revenue or margin; measure it by what the team learned this quarter. A framework like three horizons, which splits the business into current, expanding, and exploratory, exists to enforce exactly that separation. Attach a revenue target to something in the exploratory box and it is being graded by the rules of the current box again.
3. Write the kill condition in advance. Failure being the default does not mean the project can be dropped whenever. Something like "stop if response time is not under one second within six months" turns shutting it down into keeping a promise rather than admitting a misjudgment.

Skip the third and a moonshot breaks in one of two directions: it drags on for three years with nothing to show because nobody wants to be the one to end it, or it quietly vanishes at the first quarterly review. Both end the same way, with no record of what was learned.

How the word gets used depends on company size.

Large companies carve out a box separate from the core business and call what goes in it a moonshot. Ratios like 70-20-10, often quoted in discussions of resource allocation, are a device for writing down a non-zero share for exploration before the arguing starts. Setting money aside is not enough on its own, though. Budget that drifts elsewhere shows up in the books, while people get moved quietly whenever something urgent lands — so the common failure is a project that still has names attached while those people spend their week on incident response.

Startups rarely have the slack to split boxes, so the whole company is often the moonshot. Here the word is aimed mostly at investors: the odds are long and the market looks small, but the board changes if it lands. That is why the question arrives paired with runway. With twelve months of cash, there is no moonshot to discuss.

A company like Pagedeck, just past its Series A, sits between the two. Pulling two or three people out of forty-five and giving them a quarter is the realistic size, and the usual mechanism is to exempt that team from the normal approval chain, much like intrapreneurship.

"This is a moonshot, so keep it out of the quarterly revenue target."

A request to be measured on a different scale.

"We call it a moonshot, but it's two people and half their week goes to incidents."

Pointing out that the label arrived and the resources didn't.

"We can't run two moonshots. Pick one."

Spread low-probability bets thin enough and none of them reaches the point where you learn anything.

At Pagedeck, Grace used the word about a project to make the content of a document findable without opening the document at all. That is a different species from making editing 10 percent faster. If it works, the definition of the product changes; the odds of it working are much worse.

Theo and one other engineer took it on, and it came out of the quarterly targets. In exchange, a line went in alongside it: stop in three months if search accuracy cannot clear 70 percent. Mia insisted on that condition because a project without a scheduled ending does not get one.

The number also settled what the team would report. Instead of showing progress toward revenue, the three-month review shows an accuracy figure and what the team now knows about why documents are hard to search. That is a report the exploratory box can act on and the current box has no way to read.

The most common mistake is using moonshot as a flattering word for any large goal. Anything ambitious starts collecting the label, and a plan to double revenue is usually not a moonshot at all — it is doing more of the current work. The test is not size but premise: would success break the assumptions the existing business runs on? Hand the name out freely and the genuine exploratory work ends up filed among ordinary targets, graded by ordinary rules.

The other misreading is that a moonshot is a project where failure is fine. Failure is the default outcome, but that describes the result, not the process, and the process is tighter than usual rather than looser. What would justify continuing and what would justify stopping have to be written down beforehand. Without that line, projects with no results survive for years, and the next time someone proposes a moonshot, nobody believes them.