Demand generation

Demand generation is often confused with demand capture. A sales team captures existing intent—the buyer is already aware of the problem, already looking at solutions, already in motion. A demand generation function creates intent—it makes a problem visible, shows it matters, and builds urgency where none existed before.

Most founders and GTM teams blur this distinction. They run paid ads and send emails, then measure how many people convert. They declare it “demand generation.” But they are doing something much narrower. They are amplifying awareness to people already looking. The true demand generation problem is harder: how do you make someone aware of a problem they did not know they had? And more importantly, how do you do this cost-effectively in a market where 95% of buyers are not actively shopping?

The answer is that different markets have different demand machinery. Understanding which machine your market runs on is the difference between a dominant motion and a mediocre one.

The diagnostic matrix: what wakes up buyers in each segment

Demand wakes up through different channels depending on the segment and the buyer type. The mistake is thinking one channel works everywhere.

Engineering-focused markets. Engineers learn about new tools from peers, open-source communities, and technical content. They do not watch ads. They do not go to events. They read blog posts, GitHub documentation, and Stack Overflow answers. They trust hands-on proof (a working code example) over case studies (a logo). For engineers, demand generation is creating technical content, building developer communities, and making the product frictionless enough to try in an afternoon. Examples: HashiCorp built demand with Terraform tutorials and community. Stripe built demand by publishing API documentation that was better than the incumbents’. Figma built demand by releasing browser-based design collaboration to developers who could fork it and deploy it in Slack.

Demand generation for engineers means: write technical guides, open-source components, working examples, and API walkthroughs. Make the problem textual and googleable (“How to manage infrastructure as code,” not “Enterprise configuration automation”). Be where engineers spend time: GitHub, Twitter, conferences where they speak.

VP and executive markets. VPs and executives learn through peer networks, events, and advisory relationships. They do not read technical blogs. They do not download whitepapers. They talk to peers, attend industry events, and listen to analysts they trust. They trust social proof (does everyone else I know use this?) and comparative benchmarks (are we falling behind?). For executives, demand generation is creating perception that this solution is standard practice or that the gap from not having it is severe.

Demand generation for VPs means: get on the dais at industry events, build advisory boards, create comparative data (benchmarks that show the gap), build analyst relationships, and seed peer networks. Make the problem narrative and status-driven (“What are high-performing companies doing differently?”). Be where VPs are: events, advisory boards, analyst briefings.

Healthcare and regulated markets. Healthcare buyers respond to regulatory signals, clinical evidence, and physician peer endorsement. They do not respond to marketing. Regulatory approval creates demand. Clinical validation creates demand. A peer physician recommending a treatment creates demand. For healthcare providers, demand generation is clinical evidence, regulatory milestone announcements, and peer adoption signals.

Demand generation for healthcare means: publish clinical data, announce regulatory approvals, create physician peer groups, and make evidence publicly visible (so hospitals can cite it internally). The demand problem is “convince our clinical leadership this is safe and effective,” not “make people aware it exists.”

Mid-market and enterprise sales buyers. These buyers respond to trusted advisors, events, and relationship signals. They respond to “your peer company just bought this” or “we helped your closest competitor reduce costs by 30%.” Demand generation is case studies within their industry, peer advisory boards, and relationship signals from people they trust.

Demand generation for mid-market means: build industry-specific case studies, run advisory boards with their peers, create benchmarks showing competitive gaps, attend vertical-specific events, and use peer signals in outbound.

Consumer and SMB markets. These buyers respond to direct experience and peer recommendations. They use freemium product, they read reviews, they try the free tier. Demand generation is frictionless product access, word-of-mouth, and consumer app review visibility.

Demand generation for consumer means: lower friction to trial (freemium, free tier, 30-second signup), make reviews and word-of-mouth visible (App Store ranking, G2, community), and create network effects (the product is more valuable when friends use it).

The pattern: demand generation follows information flow. If your buyer learns from peers, demand generation is peer networks. If your buyer learns from technical content, demand generation is blogs and tutorials. If your buyer learns from regulatory signals, demand generation is announcements and certifications.

Most founders get this backwards. They ask, “Which channels should we use?” The right question is, “Where do our buyers learn about problems?” Then build demand generation there.

Asymmetric contrast: the same product, different demand machinery

Here is the asymmetry that breaks most GTM teams. The same product needs radically different demand machinery for different buyer archetypes.

Consider a cybersecurity platform selling to both:

1. Security engineers (individual contributors deciding which tools to evaluate)
2. CISO teams (executives buying for the whole company)

Same product. Opposite demand machinery.

For security engineers, demand generation is technical content. Write blog posts on how to detect a specific attack pattern. Create a working Kubernetes detection rule. Publish a tool that integrates with their deployment pipeline. A security engineer discovers this through a GitHub search or a tweet from a peer. Demand is generated through hands-on proof and community reputation.

For CISOs, demand generation is regulatory compliance anxiety and peer adoption. A CISO learns about a new security solution because three peers at the industry conference just implemented it, or because they heard it reduces audit time. A CISO discovers this through events, analyst reports, and peer conversations. Demand is generated through social proof and risk mitigation narratives.

Now the trap: many founders run a single demand generation machine. They choose either “engineer content” or “executive events.” The choice is wrong. You need both, because you are not selling to one buyer type—you are selling to both, and they learn differently.

The error is thinking “demand generation” is a single cost center. It is not. It is a portfolio of machines, one per buyer type, each with different costs and rhythms. Engineer content is slow to build but compounds. Executive events are expensive but create narrative fast. Running only one is leaving entire segments of your demand unreached.

The second error is thinking the same message works everywhere. It does not.

For engineers, your message is functional: “Here’s how to detect X. Here’s the code. Here’s the GitHub repo.” The engineer wants to try it themselves.

For CISOs, your message is comparative and risk-driven: “Here’s how many breach hours this reduces. Here’s how this stacks against the compliance framework you operate under. Here’s which of your peers are using it.” The CISO wants to understand the risk equation.

Running demand generation for both buyer types means:

1. Segment your target market by how they learn (engineers vs executives vs procurement vs ops).
2. Build demand machinery for each segment (content for engineers, events for executives, compliance frameworks for procurement).
3. Measure demand separately (engineers: GitHub stars, tutorial engagement; executives: event inquiries, analyst mentions; procurement: RFP volume).
4. Do not force-fit one message or channel to all segments. Asymmetric contrast means different segments need different proof.

The founder mistake: copying demand approach from a different market

The most expensive demand generation error is this: a founder succeeds in one market using a specific demand approach, then launches into a new market with the same approach and fails.

Example: A founder builds a developer platform. Engineers discover it through technical content and community. Demand machinery: blog, GitHub, tutorials, open-source. It works. 100 engineers adopt the platform.

The founder thinks: “This is working. Let’s go upmarket and sell to enterprises.” The founder expects enterprise buyers (CISOs and infrastructure teams) to discover the platform the same way. The founder keeps running the engineer demand machinery, writes more technical content, sponsors more engineering conferences.

Enterprises do not discover through technical content. They do not read GitHub. They care about benchmarks, compliance, and peer adoption. The founder’s demand machinery is optimized for engineers. Enterprises never learn about the product. Growth stalls.

The mistake was assuming the same demand machinery works in different markets. It does not. Different markets have different information flows. Different buyer types learn differently. Copying the demand approach from a successful market into a new market without understanding the information flow is a structural failure.

The test: before launching into a new buyer segment, answer this:

1. Where do these buyers learn about new solutions? Not where do you think they should learn. Where do they actually learn? (Interviews, not intuition.)
2. What signals matter to them? For engineers: technical proof. For executives: peer adoption. For procurement: compliance. For ops: integration ease.
3. Who influences their decision? For engineers: online peers, GitHub stars. For executives: peers at events, analysts. For procurement: compliance officers, legal.
4. What medium reaches them? For engineers: content, open-source, technical events. For executives: industry events, advisor calls, analyst reports.

If your answer to any of these changes, your demand machinery must change.

Real examples: content for engineers, events for VPs, regulation for hospitals

Stripe and content for engineers. Stripe’s demand came from documentation. They wrote API references clearer than competitors. They wrote guides (“How to accept payments”) that ranked in Google searches. They created webhook tutorials that engineers shared. Stripe’s demand generation was textual and searchable. Any engineer looking to solve payment collection found Stripe through search and documentation. Demand was generated through information architecture and SEO, not ads or sales.

This worked because engineers search for problems. They Google “how to accept payments in Node.js.” They find Stripe. They read docs. They try it. Demand is generated through information access.

Slack and events for VP communication. Slack’s growth came not from engineering evangelism but from a VP insight: team communication was broken, and synchronous tools (email, chat) were creating communication debt. Slack ran webinars on “async communication at scale.” They built advisory boards of VPs at fast-growing companies. They went to HR and ops conferences. They created peer networks. A VP heard from two peers that Slack was “the new way” and championed it internally. Demand was generated through narrative and peer validation.

This worked because VPs learn from peers. They trust benchmarks that show others using the tool. They sponsor pilots when other companies did. Demand is generated through narrative, not through product access.

Apple and ecosystem for consumers. Apple’s demand generation for iPhone came through ecosystem perception: the iPhone is not just a phone, it’s the entry to an ecosystem (App Store, Apple Watch, AirPods). Demand is generated through perceived completeness, not through the phone itself. A consumer buys an iPhone because their friends have one and apps work. Demand is generated through network effects and ecosystem narrative.

Epic and regulation for hospitals. Epic’s dominance in healthcare came not through clever marketing but through regulatory capture. Meaningful Use (now MACRA) required certain EHR capabilities. Epic met them first. Hospitals adopted Epic to meet requirements. When meaningful use changed, Epic adapted. Hospitals were locked in. Demand was generated through regulatory alignment, not through product narrative.

Hospitals do not choose EHR software because they read an article. They choose based on clinical workflow fit and regulatory requirements. Epic’s demand machinery is regulatory events, clinical advisory boards, and compliance certifications—not marketing campaigns.

The rules of demand generation for different markets

Rule 1: Demand generation is market-specific.

Do not import demand machinery from a successful market to a new one without understanding the information flow. The machinery that built demand for engineers (content, community, open-source) will not build demand for hospital executives (regulation, clinical evidence, peer networks). The machinery that built demand for VPs (events, benchmarks, peer signals) will not work for engineers (technical content, working code, GitHub). Understand where your buyer learns first.

Rule 2: Demand generation requires segmentation clarity.

You must know exactly who the buyer is, how they learn, and what signals matter to them. “Enterprise” is not a segment. “CFOs at companies with $50M+ ARR who own the automation budget” is a segment. When your segment is clear, your demand machinery becomes clear. Different segments, different machines.

Rule 3: Demand generation scales with information structure.

The cheapest demand generation is structured information. If you can make the problem and the solution textual and searchable, anyone looking for it finds you. The expensive demand generation is presence and noise (ads, events, sales). Both can work, but structured information compounds over time. Noise does not. Prioritize information structure first.

Rule 4: Demand generation must separate from sales motion.

Sales motion captures demand. Demand generation creates it. If you blend them, you cannot tell whether leads came from real demand or from your sales team’s noise. If you run demand generation and sales from the same budget, you will cut demand generation first when leads slow down, thinking it is not “converting.” But demand generation does not convert; it creates intent. Measure them separately.

Rule 5: Demand generation for one buyer type does not reach other buyer types.

If your product has multiple buyers (engineers and executives, compliance and users, procurement and users), you need separate demand machinery for each. Running engineer-focused demand machinery will get you engineers. It will not get you executives. Many founders scale to 100 customers, all engineers, then get stuck because they never created demand with the decision-maker. Segment your demand machinery by buyer type.

Rule 6: The demand machinery must scale with market size.

Some markets are large enough to support expensive machinery (events, analyst relations, advisory boards). Some are not. If you are selling to 50 possible customers (ultra-niche), events are wasteful. Content and direct relationships work. If you are selling to 500,000 possible customers (consumer), events do not scale; freemium and word-of-mouth do. Match machinery to market size.

The next step: where demand generation meets sales motion

Demand generation creates intent. Sales motion captures it. But the boundary between them is blurry and prone to error. The hard question is: what does a lead look like after demand generation has done its job? Is it someone aware of the problem? Someone convinced the problem is urgent? Someone ready to buy?

The answer depends on your sales motion. If your motion is self-serve (the buyer buys without talking to anyone), demand generation needs to move all the way to purchase readiness. If your motion is sales-assisted, demand generation needs to move the buyer to “interested in talking to a sales person.” The point where demand generation hands off to sales is different in every market.

Understanding this handoff is where demand generation connects to sales motion. But that is a system question that comes next.