Category: Style

Master the balancing of the two and become a legendary leader for a valuable product.

Every founder I know can articulate their grand vision. They’ll paint you a picture of how they’re going to change the world, disrupt industries, and build the next unicorn. But ask them what they’re shipping next Tuesday, and you’ll watch their eyes glaze over with the thousand-yard stare of someone who’s lost in their own complexity.

The paradox? It’s harder to make something small out of something big than it is to make something big out of something small.

And this single insight explains why 99% of startups fail, why enterprise software sucks, and why the most successful builders seem to possess an almost supernatural ability to know exactly what to work on next.

“Know When to Fold Them” Problem

Do you find yourself six months into your product and still “architecting the platform.” What a user actually does with the product today is more valuable than any genius level architecture or UI you are preparing them to use in the future.

This is what I call the Know When to Fold Them Problem. In poker, you can fold a small bet when you realize you’re beat. But when you’ve already pushed all your chips to the center of the table betting on a massive, interconnected system, folding becomes existentially difficult. In poker terms, you are “pot committed” and your ability to think clearly drops precipitously. Decision branches grow exponentially. Baggage of technology your implementation becomes burdensome. Your small product and company move at the speed of a larger one, and thus you lose one of your greatest advantages – being a mean, lean, nimble machine.

The brutal truth? Most builders and founders are terrible at managing the spectrum between atomic and cosmic.

Product Decisions Live on a Spectrum

Picture a spectrum. On one end, you have the atomic—the smallest possible thing that creates value. On the other end, you have the cosmic—the grand vision that changes everything.

The magic happens in the middle. But here’s where it gets interesting: the middle isn’t a place. It’s a dance.

The best builders I know—the ones who’ve built products that millions of people actually use—they’re constantly dancing between atomic and cosmic. They’re thinking in decades while shipping in days. They’re building cathedrals one brick at a time, but they know exactly which brick to place next.

The Warped Interpretation of “MVP”

MVP has become the most abused acronym in tech. Everyone thinks they understand it, but most people use it as an excuse to ship mediocre products.

The real MVP isn’t about just building the minimum. It’s about building the meaningful minimum. There’s a profound difference. What effs it up is the inability for must humans to understand how small something can be to have some semblance of minimum. It isn’t about know what MVP means, but decerning and being critical about where the line of “need”, “whish”, “want” live and how not to get stuck on your imagination of what the initial product set “should” be.

A minimum product is the smallest thing you can build. A meaningful minimum is the smallest thing that creates a complete experience for your user. One is about you. The other is about them.

The best MVPs you’ve never seen were deployed to tiny groups—AirBnB’s first hosts, Uber’s initial San Francisco cohort. Countless improvements and ruthless decisions to cut features and create focus happened in the shadows before these products hit the masses. The magic wasn’t in what they launched publicly; it was in what they learned and refined privately.

Learn from the Enterprise Trap

This is why software built in enterprises (or governments) are consitantly terrible. Whether you’re building products inside a large corporation or developing software as a direct contract for an enterprise client, you face the same fundamental problem: you’re optimizing for committees, leaders, and people that can express themselves with inherent importance, instead of having an individual procure and transform technological capability, true need, iterations, and robustness as a focus.

If Notion was built by an enterprise and its vocal leaders and wedge their preferences into the feature set, it would probably have ended up just like Microsoft Word. And, ironically, when I talk to most people that work in enterprises they wish they could use Notion – even with its far smaller feature set.

When enterprises build internally, they lose the discipline of starting small because there’s no market forcing function. When you’re building as a contractor for enterprises, you’re trapped by feature matrices and checkbox requirements. In both cases, you end up with a Frankenstein’s monster of half-baked features that nobody actually wants to use.

The result? Software that costs millions and makes everyone’s life worse.

Fallacy with Leadership

Leadership involvement is both essential and toxic. You need visionary leadership to maintain the cosmic perspective. But too much leadership involvement in day-to-day product decisions creates the exact opposite of what you want.

I’ve seen this pattern dozens of times. CEO has a vision. Product team starts building. CEO sees early version and says, “But what about this other thing from the vision?” Product team pivots. CEO sees that and says, “Wait, but we also need this other thing.”

Pretty soon, you’re building everything and completing nothing. You’re trapped in the middle of the spectrum, oscillating between atomic and cosmic without ever creating anything meaningful.

A Quality Paradox

Users love quality. They also love completeness. But quality and completeness are often in tension with speed and evolution. This creates another paradox: you need to ship fast to learn fast, but you need to ship quality to create meaningful experiences.

The answer isn’t to choose sides. It’s to redraw the battlefield entirely.

Instead of asking “Should we prioritize quality or speed?”, ask “What’s the smallest thing we can build that feels impossibly good?” Instead of “Should we build more features or polish existing ones?”, ask “What’s the one thing that, if we made it 10x better, would create real value?”

The Hard Truth

Most builders fail at this because it requires two skills that seem contradictory: the ability to think big and the discipline to start small. It requires the vision to see the cathedral and the humility to lay one brick at a time.

It requires saying no to good ideas so you can say yes to great execution. It requires disappointing stakeholders who want everything so you can delight users who want one thing done impossibly well.

But here’s the thing: the builders who master this paradox don’t just build successful companies. They build legendary ones. They build products that change how people work and live and think.

They build the future, one meaningful minimum at a time.

The Question

So here’s the question that separates the legends from the graveyard: What’s your atomic experience? What’s the smallest thing you can build that creates a complete emotional transformation for one specific person?

And more importantly: Are you brave enough to start there?

Because if you are, you might just change the world. One brick at a time.

What’s your atomic experience? I’d love to hear about it. The best builders I know are constantly refining their ability to find the meaningful minimum. It’s the difference between building products people have to use and building products people can’t live without.