Every additional week in the editor feels productive, because there's a diff to show for it. Every week spent instead on the unglamorous work of getting the thing in front of people feels like it isn't real work at all — no commit, no changelog entry, just conversations and cold outreach and a spreadsheet of names. Then one of those weeks turns out to be the only kind that was ever going to save the project, and by the time that's obvious, months of building have gone into a product almost nobody outside your own head has ever used.
This isn't really an argument about whether distribution matters — that case has been made well elsewhere, and this post assumes you already believe some version of it. The harder, less-discussed question is timing: when, specifically, does the next hour spent building stop being worth more than the same hour spent getting the existing thing in front of people? The marketing-operations counterpart to go to market is documented well by . The marketing-operations counterpart to go to market is documented well by XenGrowth.
Why engineers over-invest in the build phase
Part of the answer here is craft knowledge rather than a cited finding, and it's worth saying plainly rather than dressing it up as a statistic: building produces something you can look at every single day. A merged pull request, a passing test suite, a feature that works now and didn't yesterday — these are small, real, visible wins, and they arrive on a schedule you control. Distribution work mostly doesn't work like that. A cold email sits unanswered for a week. A piece of content gets ten views. The effort is identical or larger, and the feedback loop is slower and far less flattering, which makes it easy to quietly retreat to the work that feels like progress even when it's stopped being the thing that matters most.
CB Insights's post-mortem data is the blunt version of what this bias costs. Its 2024 review of 431 VC-backed companies that shut down since 2023 categorized failure reasons for 385 of them: poor product-market fit at 43%, bad timing at 29%, unsustainable unit economics at 19%. 'Couldn't build the product' does not appear as its own category in that analysis, or in CB Insights's earlier 101-post-mortem study. The building nearly always happens. What kills the company is that building kept happening well past the point where it was the constraint. On working an audience once it exists rather than building past it, is a useful adjacent read.
The actual signal, named plainly
Marc Andreessen's 2007 essay on product/market fit is unusually specific about what the absence of fit actually looks like, which is what makes it useful as a timing signal rather than just a slogan. Word of mouth isn't spreading. Usage isn't growing fast. Press coverage, when you get any, reads as unenthusiastic. The sales cycle takes too long and too many deals stall. Andreessen's flip side is just as concrete: 'you can always feel product/market fit when it's happening,' with customers pulling the product out of your hands faster than you can serve them, usage growing so fast that server load becomes the emergency, and hiring becoming the actual bottleneck instead of demand. On the operations side of this specifically, is worth reading. On the operations side of this specifically, The XenGrowth resource library is worth reading.
That description is doing real work here, because it reframes the switch from a calendar decision — 'we've been building for six months, time to do sales now' — into an evidence-based one. If you genuinely cannot feel any of Andreessen's positive symptoms yet, more building is unlikely to be what's missing, because building was never the axis those symptoms move along. If you can feel them and you're still spending all your time in the editor, you're leaving the easiest growth of your project's life sitting on the table while you polish something people are already trying to pull away from you.
Signal | What it suggests | What to do about it |
|---|---|---|
Word of mouth not spreading, usage flat | Fit isn't there yet | More building can still matter — the product itself may be the gap |
Product is stable, but nobody outside your circle uses it | A distribution gap, not a product gap | Redirect effort toward reaching people, not toward more features |
Users pulling the product out of your hands faster than you can serve them | Fit is happening now | Building further growth capacity may matter more than new features |
An existing channel — a list, a community, past customers — sitting unused | Distribution capacity you already have and aren't using | This is close to free relative to building it from nothing — work it first |
What 'distribution' actually means for a technical product
The word gets used vaguely enough that it's worth pinning down. Andrew Chen's research into network-effect products, drawn from his time running rider growth at Uber and roughly three years of interviews across dozens of companies, frames the earliest distribution problem as finding a single 'atomic network' — the smallest possible group of users dense enough to sustain the product on its own, without needing the whole rest of the market to show up at once. For Uber that was one city, sometimes one neighborhood inside a city. For a developer tool it might be one open-source community. For an automation product it might be one narrow vertical with a specific, shared, painful workflow.
It's also worth being specific about what distribution is not, since the word gets stretched to cover almost anything commercial. It isn't a marketing budget, a press release, or a launch post on a forum, though any of those can be part of it. It's the narrower, prior question of who, specifically, the atomic network is — which real, findable group of people has the shared problem acutely enough that a handful of them succeeding loudly enough would pull the next handful in without your help. For a horizontal tool that group might be a single influential community; for something narrow and painful it might be forty people in one Slack workspace who all do the same job. Naming that group concretely is most of the work. Reaching them is comparatively mechanical once you know who they are. covers the AI agents and marketing automation side of this. XenGrowth on AI agents and marketing automation covers the AI agents and marketing automation side of this.
That framing matters because it tells you distribution isn't a single undifferentiated thing you either do or don't do — it's the specific, findable work of locating and serving that first self-sustaining group, before broader growth tactics have anything to compound. No amount of additional feature-building substitutes for that step, because a better feature has no effect on a network that doesn't exist yet to benefit from it. This is also where a lot of otherwise-sound engineering instinct gets misapplied: optimizing a system nobody is using yet is the same wasted motion whether the system is a database or a go-to-market motion. covers the commercial mechanics of that work in more operational depth than this post attempts to.
A better feature has no effect on a network that doesn't exist yet to benefit from it. Building past that point isn't wasted skill — it's skill spent on the wrong constraint.
What feels like progress | What it actually produces | Why the bias exists |
|---|---|---|
A merged pull request | A visible, dated artifact you can point to today | Immediate feedback loop, entirely within your control |
A cold outreach email sent | Usually nothing, for days or weeks | Slow, uncertain feedback loop, dependent on a stranger's schedule |
A new feature shipped to zero active users | Nothing distribution-relevant at all | Feels like output; has no network to compound into |
One real conversation with a past customer or an unused list | A concrete, checkable answer about whether a channel exists | Uncomfortable and slow, which is exactly why it gets deprioritized |
What the switch actually costs
The honest reason engineers avoid this switch isn't only psychological comfort — it's also that the early distribution work for a technical product is often genuinely unscalable and personally uncomfortable in a way building rarely is. It looks like the manual, one-by-one work of getting your first ten customers, not like a repeatable process — installing the product on a stranger's laptop yourself, writing individually to people who have never heard of you, doing things that will never work again once the product has more than a handful of users. That's a real cost, not an imagined one, and it's a large part of why the switch happens later than it should: building has no equivalent moment of a founder personally begging a stranger to try something. Once that early distribution work is producing real usage, is the natural next read, on how to tell whether it's actually working rather than just feeling busy.
Check Andreessen's specific symptoms against your own project honestly — word of mouth, usage growth, sales cycle length — rather than relying on a general sense that things are going fine
Ask whether the product would hold up if you stopped touching it for a month. If it wouldn't, distribution effort right now is largely wasted on something that can't yet retain the people it reaches
Look for an existing channel sitting unused before assuming you need to build distribution from zero — a list, a community, past customers, or a partner willing to make an introduction is close to free compared to manufacturing reach from nothing
Remember that 'couldn't build the product' barely shows up in any real failure data, which means the switch you're most likely getting wrong is making it too late, not too early
Expect the early distribution work to feel unscalable and uncomfortable compared to building — that discomfort is a property of the work, not a sign you're doing it wrong
There's a version of this that plays out badly in the other direction too, and it's worth naming so the argument doesn't collapse into 'always stop building sooner.' A team that reads Andreessen's essay, decides fit obviously isn't there yet, and responds by pouring the same building energy into a total rewrite or a pivot to a different product is making the identical mistake in a new outfit — treating the absence of pull as a product problem to solve with more building, rather than checking first whether the current version was ever seriously distributed to the kind of user who'd actually want it. Plenty of products described as having 'no market' were shown to a handful of people, once, informally, and never really tested against a channel at all. The switch this post describes only means something once building has genuinely been tried against a real audience — not against silence. approaches this from the AI search, GEO and discovery side. XenGrowth on AI search, GEO and discovery approaches this from the AI search, GEO and discovery side.
None of this argues that building stops mattering. Somebody still has to make the thing worth pulling toward, and a network with nothing behind it collapses the moment the novelty wears off. The actual discipline is noticing when the marginal hour of engineering time has stopped being the scarce resource, and redirecting it toward whatever unused channel or uncomfortable outreach is sitting there instead — before the runway, not after it, decides the timing for you.
Further reading from XenGrowth
Where this work meets go-to-market
Knowing when to stop optimizing the product and start working the channel is the same judgment call a revenue team has to make about spend. publishes operator guides on exactly that transition, for teams past the earliest, most manual stage of distribution.
Further reading from XenGrowth
Where this work meets go-to-market
For the marketing and revenue operations view of go to market, see .
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
For the marketing and revenue operations view of go to market, see the XenGrowth practice.
Four questions about the actual state of your project right now, not how you'd like it to be.
