![\"Parlel](\"/product/agent.webp\")
The first ten customers are a learning project before they are a growth channel. You need people with a real problem, enough authority to try a solution, and patience for a product that is still becoming itself. YC’s advice is blunt: do work that does not scale and talk directly to customers before trying to automate acquisition. That does not mean one channel always wins. The SBA also lists networks, referrals, communities, events, partnerships, online presence, and targeted prospect lists as possible sources.
\n| Period | \nFocus | \nEvidence to collect | \n
|---|---|---|
| Days 1-14 | \nDefine one buyer and problem; speak with prospects | \nTheir last incident, workaround, urgency | \n
| Days 15-45 | \nOffer a narrow paid pilot | \nOutcome, payment, implementation friction | \n
| Days 46-75 | \nDeliver manually and document results | \nBefore/after evidence, quote, limitation | \n
| Days 76-90 | \nAsk for specific introductions and test lookalikes | \nSource, fit, referral consent, next action | \n
Do not treat “ten conversations a week” or “customer three brings customer ten” as benchmarks. They are possible operating choices, not evidence-backed rules. Choose a weekly conversation target your calendar can sustain and report what happened.
\nStart with former colleagues, communities, relevant events, partners, customer interviews, and carefully researched companies that visibly encounter the problem. Write a list with name, role, why_now, source, and permission_or_relationship. Ask for a conversation before pitching:
I am researching how [role] handles [specific workflow]. I noticed [evidence]\nand want to understand the last time this caused trouble. Could I ask three\nquestions? This is research, not a sales pitch.\nDuring the conversation, ask about the last incident, current workaround, cost or risk, previous attempts, and what would make a fix worth paying for. Someone who has never tried to solve the problem may be curious but is not yet a qualified early customer.
\nprospect:\nsource:\nbuyer_and_role:\nproblem_in_their_words:\nlast_incident_and_date:\ncurrent_workaround:\nimpact_and_source: # buyer estimate, report, or observation\nurgency:\ndecision_maker:\nbudget_status:\npilot_success_metric:\nnext_step_owner_and_date:\npilot_status: # not offered, proposed, paid, active, complete\npayment_status:\nreferral_potential_and_consent:\nAdvance a prospect when the problem is evidenced, the person can influence a decision, and there is a dated next step. Mark nurture when urgency is unclear; mark disqualified when the problem is absent or the buyer is outside your scope. This prevents polite conversations from becoming imaginary pipeline.
A useful pilot has one team, one workflow, one outcome, a start and end date, and a written decision point. Price depends on the buyer and the value of the work; do not copy a universal dollar range from another startup. A modest payment can test willingness to allocate money, but it must still cover your delivery burden.
\nPILOT BRIEF\nScope: [one workflow for one team]\nDuration: [dates]\nCustomer effort: [hours, access, owner]\nSuccess metric: [baseline -> target, measurement method]\nPrice: [amount and payment terms]\nReadout: [date and attendees]\nIf it misses: [what both sides learn and what happens next]\nIllustrative example, not a benchmark: A workflow product might test 30 researched accounts, hold 10 conversations, offer 3 pilots, and convert 1-2. The numbers are planning assumptions. If the first pilot cannot provide access to the required data, stop and redesign the pilot instead of calling the customer a failure.
\nFounder-led onboarding is not a permanent advantage; it is a fast way to learn. Set expectations in writing, send a midpoint update, record decisions, and show the result in the customer’s own terms. Document what was manual, what broke, and what the buyer would not pay for. A case study is only useful if the customer consents to the quote, logo, and numbers.
\nAfter a successful readout, ask for a specific introduction, not “anyone you know.” Give the customer a forwardable note and make clear that sharing is optional. Ask about a referral at a value moment, not during an outage, dispute, or unresolved support issue. The customer referrals guide includes the consent and tracking details.
\nLookalikes are hypotheses. If the first customer is a 50-person SaaS company with a support team, find other companies with the same problem evidence, not merely the same logo category. Keep the source and proof attached to each new account.
\nEarly enthusiasm is not the same as buying intent. Use a simple readiness test before offering a pilot:
\n| Evidence | \nWhat it tells you | \nNext move | \n
|---|---|---|
| Recent incident described in detail | \nThe problem is concrete | \nDefine a narrow outcome | \n
| Manual workaround with an owner | \nSomeone bears the cost | \nConfirm authority and access | \n
| Previous attempt to solve it | \nThe problem has priority or history | \nLearn what failed | \n
| Budget or approval path identified | \nA purchase may be possible | \nWrite commercial terms | \n
| General curiosity only | \nInterest, not urgency | \nKeep in research or nurture | \n
Ask the prospect to describe the last occurrence, not their ideal future. If they cannot remember an incident, have not tried a workaround, and would not allocate time or money to a pilot, do not pressure them into becoming a design partner. Their lack of urgency is evidence about the segment.
\nIllustrative scenario, not a benchmark: A founder offers a two-week pilot to three operations teams. One team cannot provide the data needed to measure the outcome. One completes the setup but says the workflow is too infrequent to justify a purchase. One reaches the agreed result but needs an integration the product does not support. None of these is simply “the customer failed.” The first reveals an access requirement, the second challenges the problem frequency, and the third defines a product boundary. The founder should narrow the next pilot brief and say what changed.
\nDo not publish a success story that hides a failed implementation, manual work, or a customer limitation. Ask whether the customer approves the wording, numbers, name, logo, and use of their quote separately. If approval is not given, use an anonymized internal note rather than a public case study.
\nAfter each pilot, record five things: the trigger that started the conversation, the buyer who paid or sponsored it, the work you performed manually, the evidence the customer accepted, and the objection that remained. Compare customers by problem shape, not only industry. Two companies may share a vertical but have different urgency, ownership, or compliance constraints.
\nCreate a one-page customer proof file with:
\nThis file makes referrals and lookalike research more honest. It also tells a future salesperson what not to promise.
\nCustomer consent applies to outreach as well as proof. A customer may introduce a peer without authorizing you to mention the customer’s name or results. Keep those permissions separate.
\nEarly customers often ask for custom work because the product is still forming. Decide which requests teach you about the core problem and which requests create a one-off service obligation. Put the boundary in the pilot brief. If the customer needs an integration, data export, or security review, say whether it is included, separately priced, or outside the pilot.
\n| Request | \nUseful if... | \nWarning sign | \n
|---|---|---|
| Custom onboarding | \nIt reveals a repeatable setup path | \nOnly one customer could use it | \n
| New integration | \nSeveral target customers need it | \nIt changes the product’s core buyer | \n
| Manual service | \nIt helps test the outcome | \nThe buyer values labor, not the product | \n
| Free extension | \nThere is a clear unresolved setup issue | \nNo payment or decision date exists | \n
| Discount | \nIt has a stated reason and end date | \nIt hides weak willingness to pay | \n
Do not promise roadmap items as though they are shipped. State what the product does now, what the founder will do manually, and what is only being considered. A first customer who buys an honest scope is more useful than a customer who agrees to an attractive but impossible promise.
\nAt the end of each week, review the conversations and pilots together. Look for repeated words, not just repeated feature requests. Ask whether the same buyer owns the problem, whether the trigger is similar, whether the workaround is costly enough, and whether the customer accepted the same proof. If not, narrow the segment before adding more prospects.
\nKeep a “do not claim” list. It might include an unverified time saving, a result from one unusual customer, a feature still in testing, or a logo that has not been approved. The list protects future outreach and prevents a founder’s memory from turning a pilot detail into a public promise.
\nThis guide is written for a reader who needs to use first 10 customers in a real workflow, not merely understand the definition. The dependable version starts with the decision that must be made, names the evidence available today, and keeps the next step small enough to complete. That is the editorial standard used throughout this guide and across the Parlel library: practical guidance should help a founder, operator, candidate, or freelancer act without hiding uncertainty behind confident language.
\nWrite the result in one sentence: “After this exercise, I will know whether , and the next action will be .” For first 10 customers, that sentence prevents the most common failure mode — doing more research after the useful question has already been answered. If the work concerns a person, company, role, client, or vendor, record the source and date as you go. If it concerns a template or message, define the recipient, context, and desired response before polishing the wording.
\nUse a small fixture rather than an abstract example. Pick three to five real records, situations, or drafts and run the method end to end. Keep one case that should succeed, one ambiguous case, and one case that should be rejected. That mix exposes whether the process can distinguish a useful signal from a convenient story. It also gives you material for a later review without pretending that a tiny sample is a benchmark.
\nA high-quality result should survive a handoff. Another person should be able to see what was known at the time, which assumptions were made, what action was taken, and what would change the decision. For this topic, preserve the original input alongside the conclusion. Keep a short “why now” note, the owner, the due date, and the stop condition. This makes first 10 customers useful in an agency-style operating system: the work is repeatable without becoming mechanical, and a reviewer can improve it without rewriting the whole process.
\nThose checks matter more than adding another paragraph of general advice. They also protect search quality: the page earns attention by resolving the reader's problem, not by repeating first 10 customers unnaturally. If the evidence is thin, say so and explain how to improve it. If the answer changes by country, role, plan, or company size, make that branch visible instead of burying it in a footnote.
\nUse Parlel to refill a reviewed target list and keep the customer record honest.
\nFIRST-10 DIGEST (weekly)\n- new_matches: { company, source_url, fit, signal_date, confidence }\n- stakeholder_moves: { person, old_company, new_company, consent_context }\n- customer_proof: { metric, source, approved_for_sharing: true|false }\n- next_action: { conversation|pilot|readout|referral|nurture }\nVerify signals in the company directory and people in the people directory. The digest proposes research; the founder decides whom to contact and what to claim.
\nContinue the workflow with three closely related guides:\n- sales prospecting\n- how to ask customers for referrals\n- how to get a job at a startup
\nDheeraj Kumar is a founder building Parlel, an open professional network for structured company, people, and role data. He writes practical guides for founder-led sales and hiring. See his Parlel profile.
\nCreate your company page — turn hiring signals into inbound. Start on Parlel.
","related":[{"slug":"sales-prospecting","title":"Sales Prospecting for Founders: A Lean, Measurable System","description":"A practical sales prospecting system for founders: define an ICP, prioritize buying signals, research accounts, write useful outreach, and track outcomes.","url":"https://parlel.com/guides/sales-prospecting"},{"slug":"customer-referrals","title":"How to Ask Customers for Referrals: Scripts and Tracking","description":"Learn when and how to ask for customer referrals, with copy-ready scripts, consent and incentive guardrails, and a simple tracking template that works.","url":"https://parlel.com/guides/customer-referrals"},{"slug":"how-to-get-a-job-at-a-startup","title":"How to Get a Job at a Startup (Founder's View)","description":"How to get a job at a startup, from a founder: startup interview questions, startup vs corporate trade-offs, career changes, gaps, and why founders hire you.","url":"https://parlel.com/guides/how-to-get-a-job-at-a-startup"}]}