Seven Weeks at the Speed of Play

Lenny Rachitsky’s recent interview with Roman Ugarte, who helped build Grok Bot at SpaceXAI after leading Growth at Cursor, is worth an hour of any leader’s time. The product matters less than the way it was built.

Grok Bot may not work. It is weeks old, it competes in the most crowded market in software, and it could be a footnote by spring. And I haven't had a chance to experiment with it yet, though it is on deck for the coming weekends. What deserves study is the method.

A handful of people were moved to a separate part of the office, given private channels, and handed one instruction: build a knowledge-work product for everyone outside engineering. No roadmap, no requirements document, no six-month vision deck. A working internal prototype took about a month. Public launch followed three weeks later. Seven weeks from a blank page to a product in the hands of strangers.

Clayton Christensen made the structural version of this argument in The Innovator’s Dilemma nearly thirty years ago. Established companies fail at new things not for lack of talent or money, but because their resource allocation is built to serve existing customers. His remedy was to place the new effort in an independent organization, small enough that early wins still matter to it, often a separate company altogether. Grok Bot is the same idea compressed: not a spin-off with its own balance sheet, but a sealed room, a small team, and a calendar measured in weeks. Separation is no longer mainly about protecting a new business from the old one’s income statement. It is about protecting the new effort’s decision speed.

That speed is the scarce resource. A group of four makes a hundred judgment calls a week. A group of fourteen makes twelve, and most of them are compromises that split the difference between two good ideas and land on a mediocre one.

Mark Pincus, the founder of Zynga, gives this a name in Life at the Speed of Play: testing ideas in hours or days rather than months or years, with the marginal cost of each test driven close to zero. He argues the minimum viable product is now too slow and proposes a smaller unit he calls the minimum idea state, anything from a text link to a slide to demoware that breaks after ten clicks. His rule on volume is blunt: when forced to choose between the most shots on goal and the best, most wins.

The Grok Bot team worked the same way. They walked 200 to 300 early users through setup by hand, watched the early sessions go badly, and shipped fixes before the next call. That is Pincus’s instruction in practice: “Use data to generate your idea instead of using your idea to generate data.” It is also his point about staying close to the metal. The builders were in the room when the product failed.

They also removed more than they added, banning “the product now has” in favor of “the product can now.” Pincus would call that killing losing ideas without attachment to the variant you happen to be building.

Then there is the 90 percent problem. Ugarte argues that an AI doing 100 percent of a job feels categorically different from one that gets you 90 percent there, because you are still carrying anything you have to monitor. Pincus supplies the diagnosis: “B+ is the enemy of A.” A 90 percent tool is good enough to get funded, piloted, and renewed, and never good enough to change how work gets done.

Innovation is not a nine-year construction project you unveil and hope lands. It is moving, learning, and correcting in public, fast enough that you find out you were wrong while being wrong is still cheap. Where Grok Bot ends up is unknown. Directionally, this is where organizations need to go.

This is not limited to product buildouts. It is a philosophy, and it should govern how organizations handle their partners. Most of what any company delivers runs through vendors, and a seven-week idea dies inside a twelve-month contract cycle. If testing an idea with a partner requires a statement of work, a legal review, and a ninety-day onboarding, the marginal cost of that test is nowhere near zero. If a partner cannot keep up, if a partner cannot provide the flexibility to move at this speed, that partner may not be the right one.

Be wrong quickly and often rather than careful and irrelevant. Put the thing that might not work in front of real people, and find out fast.