Technical founders often describe early sales as a task they will hire somebody to do once the product is ready.

This reverses the order. Before the sales motion is understood, the founder is not handing over a process. They are handing over a question.

The first sales calls are product work conducted in another company’s language.

Define the customer narrowly enough to find

“Small businesses” is not a prospect list. Neither is “marketing teams.”

Name a group that shares a visible condition:

  • security leads at software companies preparing an enterprise launch;
  • independent clinics still scheduling a particular workflow by phone;
  • agencies manually rebuilding the same client report each month;
  • finance teams hiring their first collections specialist;
  • founders opening a public beta after building with AI tools.

The condition should make the problem plausible before you contact anybody. It gives the message a reason to exist.

YC’s collection of first-time founder advice repeatedly returns to precise customer definition, clear value, and doing a role before hiring for it. Early sales becomes easier to learn when the target is not constantly changing.

Build a list by hand

Find twenty organizations where the condition is visible. Use public websites, job posts, product documentation, community discussions, company announcements, or people you already know.

For each account, record:

  • why the problem may exist now;
  • the person closest to the work;
  • the person who can approve a purchase;
  • the current tool or workaround, when public;
  • the evidence behind your guess;
  • the next honest action.

Do not collect a thousand addresses to avoid thinking about twenty companies. The first list is research. Its quality is part of the product hypothesis.

The recent Hacker News discussion around YC’s first-customer guidance echoed a familiar founder pattern: the first few customers often come through personal and warm networks, followed by direct work that does not scale. Use the warm path when it reaches the right buyer. Do not treat familiarity as qualification.

Write an email that can be wrong

An early outreach message needs four things:

  1. A specific observation about their situation.
  2. The problem you think it may create.
  3. One plain sentence about the result you are building.
  4. A small request for a conversation or test.

For example:

I saw that your team is opening self-serve access next month. We are building a public launch check that catches unclear product claims, missing trust pages, crawler blocks, and visible deployment issues before an announcement. I may be wrong about whether that is painful for you. Would you be open to running it against the new site together for twenty minutes?

Do not pretend to have followed somebody’s career when you found them five minutes ago. Do not insert a generic compliment between automated paragraphs. Relevant beats personalized.

YC’s sales advice for technical founders argues for targeted prospects and a conversation built around their needs rather than indiscriminate outreach. The useful principle is attention, not a magic template.

Diagnose before demonstrating

The first call is not a tour of every feature.

Ask about the last time the problem occurred:

  • What triggered the work?
  • Who performed each step?
  • Which tools and files were involved?
  • Where did it slow down or fail?
  • What was the consequence?
  • Who else cared about the result?
  • What have they already tried?
  • What would need to be true to change the process?

Stay with the current system until you can explain it back accurately. Then show only the path that addresses it.

Segment founder Peter Reinhardt describes this distinction in a YC conversation about finding product-market fit at Segment: a polished pitch followed by a yes-or-no decision teaches less than a real sales process built around the customer conversation.

The non-leading interview guide helps prevent the demo from turning every question into a request for approval.

Demonstrate their job, not your interface

Use realistic inputs from the prospect’s work when privacy and permission allow. Begin at the trigger and end at the result they care about.

Do not spend ten minutes explaining navigation before showing value. Do not hide the manual work still required. If an import needs cleanup, say who performs it. If the founder reviews every output, say so. If an integration is planned rather than live, separate the two.

A useful demo ends with a concrete gap: the result was valuable, the result was wrong, the setup was too costly, or the workflow did not fit. “Looks interesting” is not a result.

Sell a bounded pilot

A pilot should answer a purchasing question, not postpone it.

Write down:

  • the user and workflow in scope;
  • the result to produce;
  • the data and access required;
  • responsibilities on both sides;
  • a start and end date;
  • success and stop conditions;
  • the price and what happens afterward;
  • security, privacy, and support boundaries.

Free pilots often drift because neither side must make a decision. Charge when you can make an honest promise, even if the amount is modest or the service contains manual work. When a free design partnership is necessary, require real access, time, and a scheduled decision in return.

Do not call custom consulting a scalable software pilot. It may still be valuable. Name it correctly and record what would need to become product.

Treat objections as evidence

Keep the prospect’s exact words and classify the obstacle:

  • no urgent problem;
  • wrong user or company stage;
  • unclear value;
  • missing capability;
  • implementation cost;
  • trust or security concern;
  • price or purchasing process;
  • bad timing;
  • existing alternative is good enough.

“Too expensive” may mean the value is weak, the buyer is wrong, the budget cycle is closed, or the price truly exceeds the result. Ask what comparison produced the objection.

One objection is a case. Repeated objections from qualified prospects are a pattern. Change the product or offer when the pattern is strong enough, not to reward the most forceful person on the latest call.

Protect the product from one large prospect

The first credible company can make every request feel like strategy.

Before accepting custom work, ask:

  • Does it deepen the same core job for the intended market?
  • Have other qualified prospects shown the same need?
  • Can the customer commit money, data, access, or distribution?
  • Does the work create a reusable capability or permanent exception?
  • What current product work will be delayed?

YC’s discussion of the balance in early B2B sales describes the tension between listening closely to initial customers and becoming a consultancy for one or two of them.

You do not need to refuse every special request. You need to know whether you are learning about a market or renting the roadmap. Use the feature-request prioritization guide to separate a broken core job from table stakes, expansion, and private custom work.

Make the public product survive the sales process

A prospect who replies will inspect the website before the call, share it internally afterward, and return when asking for approval.

Check that the homepage explains the product, audience, and result. Publish accurate pricing or explain why it is custom. Identify the operator. Provide contact, privacy, terms, and security information appropriate to the data and access requested. Make the demo and signup path work from a clean account.

Use the website trust signals guide and launch readiness checklist before sending a hard-won prospect into an avoidable dead end.

Trust does not close a weak deal. Missing trust can stop a strong one from reaching the next person.

Keep a tiny sales record

For each account, track:

Observed condition: Why might the problem exist? User: Who performs the work? Buyer: Who approves the decision? Current process: What happens now? Consequence: What does failure cost? Commitment: What did they give up to proceed? Obstacle: Why is the next step not happening? Next action and date: Who owns it? Product lesson: What changed our belief?

This is enough for the first conversations. A complex CRM cannot compensate for vague next steps.

Review the record weekly beside the startup traction signal guide. Count qualified conversations, completed evaluations, paid pilots, successful outcomes, renewals, and referrals. Email volume alone proves little.

Hire after the founder can explain the motion

Do not wait until sales is effortless. Do wait until there is something another person can repeat.

The founder should be able to describe:

  • which accounts feel the problem;
  • which role begins the conversation;
  • which evidence earns a reply;
  • how discovery exposes urgency;
  • what the demo must prove;
  • common objections and honest answers;
  • the path from pilot to paid use;
  • approximate cycle length and founder effort;
  • why customers continue or leave.

a16z’s founder interviews in My First 16 document how varied the first major customers can be across B2B companies. The shared lesson is not one channel. It is proximity: founders remain close enough to early customers to shape the offer and product together.

Your first salesperson can improve an imperfect motion. They should not be expected to discover the customer, product, message, price, and process while the founders retreat to building.

Founder-led sales ends gradually. The founder leaves behind language, evidence, judgment, and a product that has learned how to keep its promises. That is what the next salesperson can scale.