Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Customer

Pattern

A reusable solution you can apply to your work.

“Your customer is not everyone.” — Seth Godin

Understand This First

  • Problem – the customer is defined by the problem they need solved.

Context

At the strategic level, a Problem only becomes a business opportunity when someone is willing to pay to have it solved. The customer is the person or organization that pays, approves, or otherwise causes the product to exist. Identifying the customer is a prerequisite for defining the Value Proposition, choosing a Revenue Model, and planning Go-to-Market strategy.

A common and costly mistake is assuming the customer and the User are the same person. They often aren’t. In enterprise software, a VP of Engineering may approve the purchase while individual developers use the tool daily. In consumer apps, a parent may pay for an app their child uses. Understanding who holds the budget, and what they care about, is distinct from understanding who holds the mouse.

Problem

Who exactly is going to pay for this? Many teams describe their customer in terms so broad they describe no one: “businesses that want to be more efficient” or “people who use the internet.” A vague customer definition makes every downstream decision (pricing, messaging, feature priority, distribution channel) guesswork.

Forces

  • Broad appeal feels safer but makes targeting impossible.
  • The buyer and the user often have different motivations, constraints, and evaluation criteria.
  • Multiple stakeholders in enterprise sales mean multiple customers with competing priorities.
  • Customer identity shifts as a product moves from early adopters to mainstream market.

Solution

Name a specific customer segment and describe them concretely enough that you could find ten of them in a room. Include their role, their budget authority, the size of their organization, and the alternatives they currently use. “Series A fintech startups with 10-50 engineers, where the CTO owns the dev tooling budget” is actionable. “Tech companies” is not.

Separate the economic buyer (who authorizes the purchase), the champion (who advocates internally), and the user (who interacts with the product daily). A successful product must satisfy all three, but their needs differ. The economic buyer cares about ROI and risk. The champion cares about looking good. The user cares about whether the tool makes their work easier.

In agentic coding workflows, the “customer” may be internal. A platform team building developer tools within a company still needs to identify their customer (the engineering teams who will adopt the tools) and understand their approval dynamics.

How It Plays Out

A developer tools startup builds a code review assistant powered by AI. The founders initially target “software developers.” After months of slow sales, they narrow their focus: their customer is the engineering manager at mid-size SaaS companies who is responsible for code quality metrics and has budget authority for developer tooling. This specificity transforms their marketing, sales pitch, and feature priorities.

A team uses an AI agent to generate a landing page. The first prompt is “create a page for our product.” The agent produces generic copy. The second prompt includes: “Our customer is a head of compliance at a bank with 500+ employees who currently manages audit trails in spreadsheets.” The agent produces copy that speaks directly to that person’s fears and workflow.

Note

In B2B products, the person who signs the contract often never uses the product. Your demo, pricing page, and ROI calculator serve the customer. Your onboarding, documentation, and daily UX serve the user. Conflating the two leads to products that are easy to buy but painful to use, or delightful to use but impossible to sell.

Consequences

A well-defined customer makes prioritization easier. When a feature request arrives, you can ask: “Does our customer care about this?” If the answer is unclear, the customer definition needs sharpening.

The cost is exclusion. Naming a specific customer means explicitly not targeting others, at least for now. This feels risky but is necessary. A Beachhead strategy depends on this discipline.

Customer definitions also carry the risk of premature lock-in. The customers you start with may not be the customers who carry you to scale. Revisit the definition as you approach Crossing the Chasm.

  • Depends on: Problem — the customer is defined by the problem they need solved.
  • Contrasts with: User — the user interacts with the product; the customer pays for it.
  • Enables: Value Proposition — a proposition must be addressed to a specific customer.
  • Enables: Beachhead — the initial customer segment defines the beachhead.
  • Enables: Go-to-Market — distribution strategy follows from who the customer is.
  • Enables: Revenue Model — how money flows depends on who is paying.