Solving the "Distribution vs. Product" Paradox

A founder emailed me last month after reading several of my articles. She'd spotted something I'd missed.

"In 'The Startup Playbook is Dead' you wrote that distribution beats product - build your audience before you build. But in 'Beyond Product-Market Fit' you wrote that PMF is layer one, the foundation everything else rests on. Which is it? What do I actually do first?"

I didn't have a quick answer.

I went back and reread both pieces. She was right. On the surface, I was contradicting myself. In one piece I'm telling founders that the best product doesn't win anymore, that you need to build distribution before you build features. In another I'm saying product-market fit is the foundation, that everything else rests on solving a real problem for real customers.

Both felt true when I wrote them. Both still feel true. So what's going on?

The Contradiction That Isn't

Here's what I've come to understand: both statements are correct. The problem is that each one, taken alone, gets executed badly.

"Distribution before product" often becomes "build a waitlist and hope." Founders collect email addresses, post on social media, maybe get some press coverage - then launch to an empty house. They had an audience. They didn't have customers.

"PMF first" tends to become "build in isolation and pray." Founders spend months perfecting features nobody asked for, then wonder why no one shows up. They had a product. They didn't have a real path to the people who needed it.

The real question isn't which comes first. It's why the best founders never separated them.

What I've Watched Go Wrong

Evaluating startups for our pet-tech CVC, I saw both failure modes play out.

One founder had the distribution story down cold. Massive Instagram following among cat owners. Influencer partnerships lined up. PR firm on retainer. When she launched her subscription box, thousands signed up for the waitlist. The first shipment went out to genuine excitement.

By month three, churn was catastrophic. The product was fine - nice treats, decent toys. But "fine" doesn't create retention. She could get people to try it. She couldn't get them to stay. Distribution worked. The product didn't stick.

Another founder took the opposite path. Veterinarian by training, spent two years perfecting a diagnostic device. Genuinely innovative technology. When he finally launched, he discovered something painful: the vets who would benefit most weren't the ones making purchasing decisions. The practice managers who controlled budgets had never heard of him and didn't trust new vendors. He had a product. He had no path to the people who needed it.

Neither founder was wrong about what they focused on. They were wrong to focus on one thing at a time.

How They Actually Fit Together

The best founders I've observed never separated product and distribution in the first place. They treated them as one design problem.

Slack is the clearest example. They didn't create a messaging product and then figure out how to spread it. They designed sharing into the product architecture from day one. Using Slack automatically created distribution - every time you invited a teammate, you were extending the product's reach. Dropbox did something similar with folder sharing and referral mechanics. The distribution mechanism wasn't glued on. It was baked in.

But even with distribution baked in, you still need to do the early work of finding your first users. And that work is almost always manual and unglamorous.

Paul Graham's essay "Do Things That Don't Scale" captures this. Airbnb's founders went door-to-door helping hosts create listings. Stripe's founders did "Collision installations" - literally setting up Stripe for early users on the spot. The pattern: design distribution into your product, then do unscalable work to validate both simultaneously.

What This Looks Like in Practice

I'm working with a founder building a monetization platform for independent creators. He was actually my inspiration for "Learning Velocity", the piece I wrote about optimizing for learning speed over building speed.

What strikes me about working with him is that his practices force product and distribution to stay integrated. Not through grand strategy - through specific habits.

He doesn't build features without knowing the person who asked for them. Not a persona - an actual person. Last month he was considering a new feature. Before writing any code, he spent a week on calls with creators who'd mentioned cash flow problems. Three of them said they'd switch platforms for faster payouts. Four said it wasn't a real pain point. He built it for the three - and asked each of them who else they knew with the same problem.

That's the integration. The distribution question ("who else has this problem, and will you introduce me?") is embedded in the product question ("should I build this?").

He treats every early customer as a potential channel. Before he builds something for them, he asks: if this works, will they tell someone? Will using this feature naturally expose new people to the platform? Not every feature has to spread - but if none of them do, he's building in isolation.

He sets learning goals, not shipping goals. His weekly question isn't "what did I ship?" It's "what did I learn about who needs this and how to reach them?" Sometimes the answer comes from building. Sometimes from conversations. Usually both.

Why This Is Hard

Founders often prefer a sequence. "First I'll do X, then Y." The reality is messier - and slower than anyone wants to hear.

Content and community building can take six to nine months before you see meaningful traction. Many founders quit after four to six weeks, assuming something's broken. Direct sales validation is faster but still requires commitment - a 60-90 day sprint, 20 direct outreaches per week to your ideal customer profile. Community-based distribution - becoming the trusted hub for a specific audience - can take one to three years of building relationships.

The psychological trap: building feels like progress. Writing code, shipping features, seeing something take shape - that feels like work. Testing distribution feels like stalling. Sending emails, having conversations that don't lead anywhere immediately - that feels like you're avoiding the real work.

But the founders who get this right understand something important: the commitment is to learning what works, not to following a predetermined sequence.

Back to That Email

I wrote back to the founder who'd spotted my contradiction. Here's roughly what I said:

"You're right that I contradicted myself. Both things are true - and the hard part is holding them together. The skill isn't choosing 'distribution-first' or 'product-first.' It's refusing to let them become separate questions.

Every product conversation should include 'how will people find this?' Every distribution experiment should feed back into 'what should we build?' When you catch yourself working on one without the other, that's the warning sign."

She wrote back a few weeks later. She'd started asking a different question in her weekly planning: "Who specifically will I learn from this week - and what will I build or change based on what they tell me?"

Simple reframe. But it forced the integration.

That's the thing about this paradox. The answer isn't a sequence. It's a refusal to separate the questions at all.

I help founders navigate strategy and funding decisions when the path isn't clear. If you're there, let's talk.