I'd seperate PMF hunting and go to market just in case that's not what you're doing. I've done tons of small/startup GTM projects, most notabily I was on the deviantart zero to 1 and the digitalocean zero to 1. I wasn't clear enough. I'm not advocating that you should skip validation or assume a PMF, rather, you shouldn't even be thinking about a full, formal GTM until you've proven repeatable product market fit.
You're right that active, direct customer outreach in early stages, talking to real people at events, user interviews, forcing them to talk to you etc is the only way to validate and refine PMF. But to me, this isn't really "outbound" in the spammy, growth hacky sense that I critiqued above. It's thoughtful customer development: qualitative, deliberate, personal, strategic, and hopefully founder lead.
The real outbound I'm against is that lazy "spray-and-pray" approach, or the obsession with hyper personalized yet fundamentally shallow cold outreach that's mistaken for scalable growth. Real GTM, once you truly have PMF, is actually pretty mechanical and clinical. That said, personally, I've always treated early GTM as inseparable from product refinement. Every interaction early on is about learning and adjusting, (sorry Arch, you just had to go!) not aggressively scaling. "Rapid growth" is alluring, sure, but if it isn't anchored in real market validation, as you're pointing to: it ends up as expensive noise.
Am I correct in that much of the 0 to 1 is just like, getting some interactible artifact in front of potential customers, getting them to kick the shit out of it, identifying which of those people liked the artifact best, refining the artifact for THOSE types of people, then repeating the cycle? Like, there's no "market" yet, only your buddy Joe and some guys he knows.
Not really, well kinda, although lots of people skip the first step (well, most people try to skip a lot of steps sadly). You're describing something closer to early stage customer validation (ux/ui or otherwise) imo, (although experienced folks will tell you the playbooks and motions matter a lot, I agree, but that would be too much to get into), and while that iterative process is crucial, there's a key difference: real zero to 1 requires that you've also done a broader market analysis to understand where you're headed in a strategic sense, your "vision". That is not just about refining an artifact based on Joe and a few friends, it’s about deeply understanding the context your artifact fits into, including the broader market dynamics, existing customer pain points, competitive landscape, and whether this thing has legs to actually scale beyond those first friendly testers. (In business the answer is the answer, not what you want the answer to be: 5 customers, 500 customers, 5 million customers, there is an answer.)
Early feedback loops from Joe & friends can be misleading without also stepping back to ask strategic questions like: “How big is this pain?”, “Is this pain widespread or niche?”, and “What are the economic dynamics around solving it?” You’re not truly going from zero to 1 until you’ve mapped those answers and built a clear hypothesis around repeatable product market fit, which involves deliberate strategic judgment calls beyond just refining based on individual user reactions. When we launched DigitalOcean, several major tailwinds aligned perfectly, fueling rapid adoption. Chief among these was the dramatic, yet largely unnoticed, decline in SSD pricing, which Ben and Moisey Uretsky recognized early. Once they explain that change was happening in the world, I was able to understand and explain the whole business: SSD prices dropping allowing us to offer faster infrastructure at price parity (and eventually even lower than traditional providers). The Comp Sci degree was outpacing the MBA handily as an area of study, coupled with the explosive growth in developer focused startups (and startups generally), dissatisfaction with AWS complexity, and a rising wave of DevOps and containerization practices, we positioned ourselves perfectly for the incoming generation of developers. We came to a market with a genuine commitment to simplicity, love, community driven marketing, and API-first infrastructure resonated deeply, creating genuine trust and loyalty that became the foundation for rapid, sustainable growth. I was literally online 24/7365 making sure everyone was happy with everything (except that one time: sorry about that!!!!), just ask anyone here, I was on it.
tl;dr yes, iterate closely with early users, but pair that tight iteration with rigorous market understanding and strategy, if you're unaware of the broder market dynamics, you're at risk of solving only for a handful of early adopters and missing the real market entirely. (I don't like to mention my blog on HN, but I have a most you might enjoy: https://b.h4x.zip/founders/)
By definition, the Digital Ocean Zero to 1 can't have been a thing.
Providing services like virtual machines, managed databases, and Kubernetes clusters wasn't a groundbreaking innovation by the time DO came out in 2011. Even Heroku had been around for four years by then.
You're right that active, direct customer outreach in early stages, talking to real people at events, user interviews, forcing them to talk to you etc is the only way to validate and refine PMF. But to me, this isn't really "outbound" in the spammy, growth hacky sense that I critiqued above. It's thoughtful customer development: qualitative, deliberate, personal, strategic, and hopefully founder lead.
The real outbound I'm against is that lazy "spray-and-pray" approach, or the obsession with hyper personalized yet fundamentally shallow cold outreach that's mistaken for scalable growth. Real GTM, once you truly have PMF, is actually pretty mechanical and clinical. That said, personally, I've always treated early GTM as inseparable from product refinement. Every interaction early on is about learning and adjusting, (sorry Arch, you just had to go!) not aggressively scaling. "Rapid growth" is alluring, sure, but if it isn't anchored in real market validation, as you're pointing to: it ends up as expensive noise.