GTM 101 for EPD: Why Distribution Is the New Bottleneck

There's an uncomfortable pattern I keep seeing in EPD organizations: teams that can build anything, but can't get it to users.

The irony is that AI has made this worse, not better. When you can ship a feature in days instead of weeks, the temptation is to build more. But building faster without distributing better just means you accumulate features that nobody uses at a higher rate.

The bottleneck has moved. And most EPD orgs haven't adjusted.

This post is the GTM literacy I wish I'd had earlier in my career. Not the sales playbook version. The version that changes how you build.

In this post:

1. The shift EPD leaders are missing: why building fast isn't enough
2. The concepts that actually matter: ICP, distribution fit, GTM motions
3. How GTM stage changes what you build: 0→1 vs. 1→10 vs. 10→100
4. GTM motions and their EPD implications: PLG, sales-led, and what each demands
5. Distribution fit: the thing after PMF: why great products still fail
6. Red flags EPD leaders should watch for: the patterns that kill GTM
7. Building for distribution from day 1: what to change now

---

The shift EPD leaders are missing

For most of software history, the constraint was building. Can we build it? Can we build it well? Can we build it on time? Engineering velocity was the bottleneck, and everything else waited for shipping.

AI changed the equation. With agentic engineering workflows, a small team can now ship what used to take a quarter in weeks. The build phase compressed. But the distribution phase didn't.

The result: the constraint moved from "can we build it?" to "can we get it to the right people, at the right time, through the right channel, at a price they'll pay?"

This is a GTM problem. And it's not someone else's job.

Every EPD decision has GTM consequences. Your API design determines whether developers can self-serve. Your onboarding flow determines whether free users convert. Your instrumentation determines whether anyone can tell which features drive retention. Your architecture determines whether you can price by usage, by seat, or by outcome.

If you don't understand GTM, you'll build the wrong things for the wrong stage and wonder why the product isn't growing.

---

The concepts that actually matter

You don't need an MBA's worth of GTM knowledge. You need five concepts.

ICP (Ideal Customer Profile)

The customer segment most likely to buy now, get value, and renew. Not "everyone who could use our product." The narrow slice where your product is a must-have, not a nice-to-have.

Stripe started with startup developers. Not enterprise procurement teams. Not SMBs. Developers at startups who needed to accept payments in an afternoon.

Product-Market Fit

When your ICP pulls the product from you, rather than you pushing it to them. The clearest test: if you took the product away, would more than 40% of your users be "very disappointed"?

Slack had PMF before they had a sales team: organic adoption, high daily engagement, teams refusing to use anything else.

Distribution Fit

The thing after PMF that most people skip. Can you reach your ICP through a channel they trust, at a cost that makes the economics work?

Figma had PMF early, but their distribution fit came from designers sharing files that pulled collaborators into the product. The product was the distribution channel.

GTM Motion

The primary mechanism you use to acquire and convert customers: PLG, sales-led, community-led, partnership-led. Each one demands different things from EPD.

GTM Stage

Where you are in the journey: 0→1 (finding PMF), 1→10 (making it repeatable), 10→100 (scaling efficiently). The right thing to build at each stage is completely different.

---

How GTM stage changes what you build

This is where GTM literacy becomes practical. The features, infrastructure, and design priorities that make sense at 0→1 are actively harmful at 10→100, and vice versa.

GTM Stage	Engineering	Product	Design
0 → 1	Instrument everything. Build for speed, not scale.	Validate one ICP's must-have problem. Kill scope ruthlessly.	Fastest path to the 'aha moment.' Remove every unnecessary step.
1 → 10	Reliability, basic multi-tenancy, pricing/metering infra.	Harden onboarding. Define the PQL trigger. Nail packaging.	Activation flow tied to the PQL event. Progressive disclosure.
10 → 100	Enterprise features (SSO, audit logs, compliance). Optimize infra cost.	Segment expansion. Upsell paths. Partner integrations.	Localization. Cross-product transitions. Retention nudges.

The most common mistake: building 10→100 features at the 0→1 stage. SSO before you have 10 paying customers. Multi-region infra before you've validated one market. An analytics dashboard before you know which metrics matter. These feel productive but they're premature optimization of a distribution problem you haven't solved yet.

The second most common mistake: staying in 0→1 mode at the 1→10 stage. You found PMF, users love it, but your onboarding drops 70% of signups. You don't have pricing infrastructure. You can't tell which users are ready to buy. The product works, but the distribution machine doesn't.

Figma navigated this well. At 0→1, they built a browser-based design tool that worked without installation. At 1→10, they added team plans and sharing mechanics that turned every shared file into a growth loop. At 10→100, they added enterprise features (admin controls, SSO, org-level billing) that unlocked a completely different buyer persona without changing the core product.

---

GTM motions and their EPD implications

The choice of GTM motion isn't a sales decision. It's an architecture decision.

Product-Led Growth (PLG)

Users discover, adopt, and expand without talking to sales. The product itself is the primary acquisition channel.

What it demands from EPD:

• Frictionless onboarding: the user must reach value in the first session
• In-product instrumentation for PQL (Product Qualified Lead) triggers: you need to know when usage signals buying intent
• Usage metering and pricing infrastructure baked into the product, not bolted on

Notion is the textbook case: blank page → template selection → team invite. Every step is both product value and a distribution mechanism.

Sales-Led

A sales team drives deals, typically for high-value contracts.

What it demands from EPD:

• Demo environments and guided experiences that support the sales narrative
• Enterprise features: SSO, audit logs, compliance certifications, role-based access
• CRM integration and lead scoring instrumentation

Salesforce built the entire CRM category this way: the product required implementation support, which justified the sales team, which justified the price point.

Community/Developer-Led

Adoption grows through communities, open source, or developer ecosystems.

What it demands from EPD:

• Excellent documentation, SDKs, and API design: your docs are your onboarding
• Public changelogs, transparent roadmaps, developer-friendly pricing (free tier with generous limits)

Stripe's developer experience is legendary: the API is so well-designed that integration itself is a distribution event. Every Stripe integration brings Stripe into another company.

The key insight: your GTM motion determines your engineering priorities. A PLG product that requires a demo call has a broken motion. An enterprise product without SSO has a broken motion. The motion and the product must be aligned.

---

Distribution fit: the thing after PMF

Product-market fit gets all the attention. Distribution fit is equally important and far less discussed.

Distribution fit means: you can reach your ICP through channels they trust, at a cost that improves (or at least holds) as you scale.

Four questions to pressure-test it:

1. Channel-ICP match: Are we reaching our ICP where they already are? GitHub for developer tools. LinkedIn for B2B SaaS. Industry conferences for enterprise.
2. Economics at scale: Does our acquisition cost hold as we grow, or does it blow up? If you're 100% dependent on paid ads, every competitor bidding on the same keywords makes your economics worse.
3. Channel concentration: Are we over-dependent on one channel? If more than 50% of acquisition comes from a single source, you have a distribution fragility problem.
4. Product-as-channel: Does using the product create distribution? Figma files that require collaborators to sign up. Notion pages shared publicly. Calendly links that introduce the product to every meeting participant.

Atlassian scaled to $1B+ in revenue with almost no outbound sales force. Their distribution fit came from: self-serve pricing that removed procurement friction, inbound content that ranked for every "project management" query, and a product (Jira) that spread within organizations because one team's adoption created demand from adjacent teams.

Why EPD should care: Distribution fit determines your onboarding UX priorities, your instrumentation requirements, and your pricing model. If your distribution depends on virality, your product must have sharing mechanics that are core to the workflow, not bolted-on invite modals.

---

Red flags EPD leaders should watch for

GTM failures rarely announce themselves. They show up as product decisions that seem reasonable in isolation but kill distribution in aggregate.

• Building without knowing the ICP. "Our product is for everyone" means your product is for no one. If engineering doesn't know who the ICP is, they'll build generic features that solve no one's problem deeply enough to drive adoption.

• No PQL definition in a PLG motion. If your product-led growth motion doesn't have a clear definition of which product usage signals buying intent, your sales team is chasing poor-fit leads and your product team is guessing at what drives conversion.

• Enterprise deals before a repeatable motion. Moving upmarket before the 1→10 motion is stable is a classic trap. Sales cycles stretch to 9 months, custom requests pile up, the roadmap gets hijacked by one whale customer's requirements, and your burn rate spikes.

• Pricing tied to inputs, not outcomes. Especially dangerous for AI features. "We spent $5,000 on API calls" is a cost. "We resolved 3,000 support tickets automatically, saving $45,000" is an investment. If customers can't articulate the ROI, they'll churn at renewal.

• Single-channel dependency. If 70% of your leads come from one source, you're one algorithm change or partner dispute away from a distribution crisis.

• Scaling headcount before repeatable GTM. Hiring 10 salespeople doesn't fix a distribution problem. It multiplies it. Fix the motion first, then scale the team.

---

Building for distribution from day 1

If you take one thing from this post, it's this: distribution is not someone else's job. It's an EPD concern that starts at architecture and ends at the user's first experience.

For engineering leaders

• Instrument for distribution, not just reliability. Track activation events, PQL triggers, and funnel drop-offs with the same rigor you track p99 latency.
• Build pricing and metering infrastructure early. Retrofitting usage-based pricing onto a product designed for flat-rate billing is painful and expensive.
• Design APIs and integrations as distribution channels. Every integration partner is a potential acquisition source.

For product leaders

• Define the PQL trigger before building the feature. If you can't articulate what usage pattern signals buying intent, you're not ready to ship.
• Nail onboarding before adding features. A product with 10 features and 30% activation is worth less than a product with 3 features and 80% activation.
• Know your GTM stage and build accordingly. The right feature at the wrong stage is waste.

For design leaders

• The first five minutes of the product are the GTM. If users don't reach the "aha moment" in the first session, no amount of sales follow-up will save you.
• Design for the distribution mechanic. If your GTM relies on sharing, make sharing the most natural action in the product, not a button buried in a menu.
• Show value before the paywall. Users who understand what they're paying for convert. Users who hit a paywall before experiencing value churn.

---

The companies that win aren't the ones that build the fastest. They're the ones that build things people can find, try, love, and pay for. That's a distribution problem. And in an era where AI makes building trivially fast, it's the only problem that matters.

---

For the engineering workflow that makes building fast, see Agentic Engineering with Claude Code. For how to write the specs that feed that workflow, see Spec-Driven Engineering.