译文修订

- As input, most reviews want to know what changed this quarter, why, and what should be done about it. Resist the urge to just update whatever numbers are in the template - give the model too as much data as you can get your hands on so it can understand your business: "Tell me what changed this quarter, why, and what we should do about it." - Meetings (the good kind, anyway) ideally end with some decisions. Ask Claude: "Work out which three decisions are most urgent in the face of everything you've learned, and start working on potential directions with for/against arguments." - QBRs are from a time when good reviews required humans to carefully sift through data, figure out what the data means, and if the business should adjust. Ask Claude: "The review exists so leadership catches problems early and moves money and people to the right places. Design a better way to do that than a quarterly deck, show from our own history that it would have caught things sooner, and run it beside the current one for a quarter."

The altitude approach works best if you really are after some ultimate outcome; it works less well for creative endeavors. A good tell-tale sign that ambition in altitude is a good idea is if you're going to have meetings to discuss whatever you're working on. There are currently limits ("Claude, go make money" doesn't seem to work for most businesses by itself in 2026), but I generally see that models seem to be able to operate at higher levels of abstraction the more capable they become.

Altitude is also where people find durable workflows that take the human out of the loop, making it less necessary for you to constantly update the model with task after task. Doing this well often involves changing your workflow - in order to let Claude make sure our app is crash-free, I first had to make sure it can easily fetch crash reports, understand which app version maps to what git commit, and give it access to Windows, macOS, and Linux computers so it can actually independently reproduce and verify fixes.

- **Insist on the same instruments used by the best in the industry:** When prompted to act like a professional, models often switch vocabulary without actually switching methods. To work on our problem with depth, we need to use the same tools as the best data scientists and statisticians. When Claude reaches for markdown tables, insist on the use of databases and statistical models. You don't necessarily have to know what the experts use, Claude usually does. - **Pick unreasonable goals and tell the model that they're very reasonable:** You need your website to load in 5s instead of 10s? Ask for 200ms. Does something seem impossible to the model? Reiterate that it's very much solvable, it just needs to keep going. - **Challenge what you know:** Especially in business, a lot of things we believe to be true are rough approximations of reality. Give the model access to the raw information and data and ask it to adversarially check assumptions. "We believe churn is an onboarding problem. Try to reproduce that from the raw data." - **Produce new knowledge:** Easily tacked onto challenging what you know - once Claude is already deep inside the data, ask it to find blind spots. "Build a simulation of our customers that reproduces the last year from our logs. Then find the earliest signal of churn we don't know about yet, and show it predicts on data it has not seen." - **Use an outside judge:** Do *not* ask the model to judge itself.I assume that this will eventually be solved with increasing model intelligence, but in October 2026, I implore you to insist on outside validation. Ideally that's a tool the model can run to get feedback immediately.

- **Try to replace the nouns with verbs:** An old trick from *The Art of Innovation* by Tom Kelley and Jonathan Littman. A quarterly review isn't "a deck". It's "getting busy people to believe a story about cause and effect, and to decide under uncertainty, in 30 minutes". Having the verbs makes it easier for both me and Claude to understand which fields might bring in a unique and useful perspective. - **Assemble the crew:** The deck needs to be amazing, otherwise aliens will blow up Earth. What kind of team will humanity get together? For production quality, I'd bring in an analyst, a journalist, and an editor. If it has to be presented, probably a motion and audio designer, too. It might be useful to employ an adversarial "red team", too, so let's bring in a short seller and a forensic accountant.

## We have been here before

- **Accomplish hard things by believing them to be possible:** In 1939, George Dantzig showed up late to a statistics class at Berkeley, copied two problems off the blackboard, and handed in his solutions thinking they were homework. They were two unsolved problems in statistics. - **Accomplish hard things after watching somebody else do them:** For decades, humans chased the four-minute mile. Roger Bannister broke it in May 1954 but remained the only human to do so for a mere 46 days. If you're into running, we're watching something similar happen to the two-hour marathon: Sabastian Sawe ran the first official sub-two-hour marathon in London this April. In the same race, the runner-up also broke the two-hour mark. - **Accomplish hard things by giving yourself permission to fail:** Apparently everyone's favorite business book is *The Inner Game of Tennis*, which I discovered just last week. The book's core thesis is that you're not playing your best game of tennis if you're trying really, really hard. We engineers might remember Linux, announced as "just a hobby, won't be big and professional like gnu".