Uxtopian
All articles

Toy and Tool: Two Modes of Building Product

Most products and features that people actually love started as something no one asked for. A prototype that didn’t fit a roadmap. An experiment that ignored the market for a minute. The Symposium started that way. I wasn’t solving a business problem. I was pulling two books off a shelf and wondering what would happen if the authors could argue with each other. No user stories. No competitive analysis. Just: what if?

That’s the Toy. Think about a basketball. It’s hard to use. The rules are complex. But you pick it up and mess around anyway because it’s fun. You’re not asking “will this sell” or “does this integrate.” You’re asking what’s possible that wasn’t before. The Toy gives you permission to be weird. To over-build in one direction and completely ignore another. To chase a feeling before you can name the function. The barge button, the comfort toggle, the instigator. None of those came from requirements. They came from play.

Then there’s the Tool. A lawnmower. Nobody plays with a lawnmower. You use it because it’s efficient and it gets the job done. The Tool asks the hard, boring, necessary questions. Who’s this for? How does it integrate with what people already use? What do you cut? You throw away most of what made the Toy interesting. That’s the job. The Tool is discipline. It’s the part that makes something shippable instead of just demoable.

Most teams start in Tool mode. They spec the product, map the market, define the requirements, and then try to inject magic at the end. It doesn’t work. You can’t schedule novelty. You can’t put “delight” in a Jira ticket and expect it to show up. The magic comes from the Toy phase, from building without the constraints that make products viable. The Tool phase makes it real. But it can’t make it interesting.

The toy is where you discover what’s magic. The tool is where you discover what’s necessary. You need both, in that order.

This matters more right now because the interaction patterns for AI products haven’t been established yet. We’re still in the search-box-that-texts-you-back era. Intent-based interaction, where users express goals instead of steps. Progressive disclosure that reveals AI power gradually. Explainability that earns trust by showing reasoning. Human-AI co-creation where the interface becomes a collaboration space. None of that comes from market analysis. It comes from someone building something that doesn’t need to work yet, just to see what happens.

I’m starting to push the Symposium toward its Tool phase. Same core insight: sustained disagreement is more useful than convergence. But the questions are shifting. Not “what’s possible” but “who needs this and why.” Not “what else can I add” but “what can I remove without losing the magic.” The comfort toggles, the thinking hats, the head-to-head mode. Some of that survives. Some doesn’t. I wouldn’t know which was which without having built the Toy first.

Meanwhile the Toy keeps teaching me things. I just added a Design Critics table with nine design thinkers from Rams to Hadid, and the interaction problems that came up were completely different from the tech-philosopher table. Fixed a bunch of mobile issues. Rebuilt the token management so debates don’t choke at nine voices. Every fix feeds the Tool version. That’s the thing about running both tracks: the Toy stays loose and the Tool stays grounded, and they make each other better. I’ll probably ship them side by side so you can play with both and see for yourself where the magic lives.

I find myself asking this on every product decision now. Is this a Toy problem or a Tool problem? Am I trying to discover what’s magical, or make something magical into something usable? Those are different mindsets. Mixing them is how you get products that are neither interesting nor useful.

The products people remember almost always started as someone’s Toy. The Tool is what made them last. But the Toy is what made them matter. (And if anyone at Anthropic wants to sponsor my API credits so the Toy can keep running, I’m very open to that conversation.)

IA

Ian Alexander

VP of Design — writing on leadership, AI product strategy, and building teams that ship.