At what point did you realize building wasn't the bottleneck anymore?
For me, it was when I finally shipped something I was proud of.
I thought:
"Now people will come."
They didn't.
That's when I realized there are actually two completely different skills:
Building a product.
Getting people to care about a product.
AI has made the first one much easier.
I'm not sure the second one has gotten any easier at all.
When did that realization hit you?
For me, the real split is this:
Building proves the product can exist.
Distribution proves someone already cares enough to change behavior for it.
A lot of founders mistake polite interest for demand. Comments, upvotes, “this is cool,” and even waitlist signups can feel like momentum, but they do not always prove a buyer has an urgent enough problem.
The shift happens when you stop asking “where can I post this?” and start asking:
who already feels this pain today
where are they complaining about it
what are they using instead
what trigger would make them try something new this week
That is usually when building stops being the bottleneck.
The painful part is that customer-finding feels slower and messier than shipping features, but it gives much cleaner truth.
I like the distinction between proving a product can exist and proving someone will change their behavior because of it.
As a founder, it's surprisingly easy to collect signals that feel encouraging but don't necessarily translate into usage or demand.
The part that resonates most is the behavior change. Someone trying your product, switching from their current workflow, or coming back a second time probably tells you more than dozens of likes or comments.
Exactly. Behavior change is the real signal.
Everything else is useful only if it helps you find the people already close to switching from their current workflow.
It hit me when feature requests started feeling easier than finding one more painful conversation. The best forcing function I have found is to make distribution work produce a concrete artifact: 5 exact words customers use, 3 places they already gather, and 1 objection that would stop them from trying it. If I cannot fill those in, I am probably still building to avoid market risk.
That's a great way to think about it.
I can definitely relate to the "building to avoid market risk" part. It's often much easier to spend a weekend improving a feature than having a conversation that might challenge your assumptions.
I like the idea of forcing concrete outputs from distribution efforts. Features create artifacts in the product. Customer conversations should create artifacts in our understanding of the market too.
Exactly. The artifact is what keeps the conversation from becoming vague reassurance.
A feature leaves you with code. A good customer conversation should leave you with sharper words, a clearer segment, or a better objection map. If it doesn't change one of those, I try to treat it as interesting but not yet operational.
That also makes the next action less mystical: update the page, test one outreach angle, or go find the next person with the same complaint.
It hit me when I realized shipping creates inventory, not demand. The useful split for me is: building answers “does this work?”, distribution answers “who already has the pain today, and where do they complain about it?”
For tiny products, I try to write down the exact complaint phrase before writing more code. If I cannot find people already saying that phrase in support threads, search results, or founder communities, I treat the next feature as procrastination until I can.
"Shipping creates inventory, not demand" is such a powerful way to put it.
I think a lot of founders, myself included, naturally gravitate toward building because progress feels visible. Customer discovery is much less tangible.
The complaint phrase idea is interesting too. It's easy to build around a problem you think exists. It's much harder to ignore people repeatedly describing the same pain in their own words.