Train the Monkey First: Moonshot Lessons for AI Pilots
The cheapest AI project is the one you stop in week two because you tested the hard part first.
Astro Teller runs X, Alphabet's "moonshot factory", the lab behind Waymo's self-driving cars and Google Brain, which helped create the deep-learning methods and the Transformer architecture that modern chatbots are built on. In a conversation on Moonshots with Peter Diamandis, he explained how X decides what to pursue and, more often, what to drop.
His numbers are sobering. Teller has said publicly that only about 2% of the projects X starts ever graduate into a business. The rest are stopped. He does not see that as failure. He sees it as the system working.
A small business is not trying to build self-driving cars. But anyone starting an AI project faces the same risk X manages every day: spending months and money on something that was never going to work. Four of Teller's lessons translate directly.
1. Name the problem before the technology
Teller defines a moonshot in three parts: a big problem you can name, a solution that would clearly fix it if you could build it, and a technology that gives you at least a chance of building it. If you cannot name the problem, he says, you are doing an academic exercise.
The small-business version is the same discipline at a smaller scale. "We should use AI" is not a project. "We lose about ten hours a week chasing unpaid invoices" is. Start with the cost of the problem in hours or money, then ask whether AI is the right tool.
2. Train the monkey before you build the pedestal
Teller's best-known analogy goes like this. Suppose the goal is to get a monkey to stand on a ten-foot pedestal and recite Shakespeare. Which do you do first? Most teams build the pedestal. It is easy, it shows progress, and it gets the next round of funding. But the pedestal was never the hard part. If the monkey cannot be trained, the pedestal is wasted.
In an AI project, the pedestal is the dashboard, the login screen, the nice interface and the integration plumbing. The monkey is the question of whether the AI can actually do the job accurately on your real data. Test that first, with a small sample of real cases, before anyone builds anything around it.
3. Check the economics early
Teller says X kills many promising ideas on what he calls techno-economics: once you work out the real costs and what customers would really pay, the numbers do not add up. Clean water is his example. X has returned to it repeatedly, but the target cost per litre has not yet been reachable.
For an AI pilot, do the arithmetic before the build. What will the model cost to run each month at your real volume? How much human checking will it still need? What is the saving or extra revenue? If the answer only works in the best case, you have learned something valuable for very little money.
4. Make stopping cheap and normal
The hardest lesson is cultural. Teller argues that you learn nothing when you are right and only learn when you are wrong, so a team has to stop feeling bad about the moment it discovers a project will not work. Otherwise people avoid that moment and keep a "zombie" project alive for years.
He also points out an imbalance. Wrongly continuing a project that will not work is expensive. Wrongly rejecting one that might have worked costs almost nothing, because there are always more problems and more ideas to try.
For a small business, that argues for short, fixed-length pilots with a clear pass-or-stop test agreed in advance. If the test fails, stop, write down what you learned, and move to the next problem. Nobody should be blamed for a pilot that answered its question.
A simple pilot plan
- Week 0: Write the problem in one sentence with its monthly cost.
- Weeks 1–2: Test the AI on 20–50 real past cases. Measure how often it is right.
- Week 2: Do the cost sum: running cost plus human checking against the saving.
- Decision: Continue only if accuracy and economics both pass. Otherwise stop and pick the next problem.
- Only then: Build the interface, the integrations and the automation around it, with logging and human approval in place.
Frequently asked questions
How long should an AI pilot for a small business take? Two to four weeks is usually enough to learn whether the core task works on your real data. If it needs months to show anything, the scope is too big.
What if the pilot fails? Then it did its job. You found out cheaply. Record what went wrong, because the same data or process issue often blocks the next project too.
Do we need a big budget to work this way? No. Teller points out that X keeps its teams deliberately small. The method is about testing the hardest part first, not about spending more.
Where this runs at Obizworks Obizworks starts every engagement with a short, fixed-scope pilot on your real data, with a pass-or-stop test agreed before any build begins.
- Governed AI pilots and automation: obizworks.com
- AI management assistant: mgmt.obizworks.com