How to Find Paying Customers Who Need the Same Product

Lorikeet deliberately parted ways with four of its six early design partners, according to Clarify’s account. Their needs differed too much for the small team to serve them well.

That’s the trap to avoid while chasing your first sales. You need people who pay, but you also need enough overlap that serving one helps you serve the next.

Find buyers yourself. Sell a narrow result. Keep checking whether you’re building one useful product or taking on a string of unrelated jobs.

How to get your first 10 customers when you’ve already shipped

Recruit your first paying customers one at a time around one painful problem. Stripe’s guide to starting sales puts the starting point bluntly: “If you build it, they will do absolutely nothing.”

A working product gives you something to sell. It doesn’t tell you who needs it enough to pay, or how to reach them. Your next job is to find that out through direct conversations and paid work.

Use a simple sequence:

1. Pick one kind of buyer and one result your product can deliver.
2. Find people with a visible reason to need that result.
3. Research each person before you contact them.
4. Offer something useful and ask for a small next step.
5. Propose a paid offer with clear limits.
6. Follow up and record what happened.

Keep the definition of a customer strict. 100 Tasks distinguishes commercial commitments from followers, waitlist emails, free trials, and friendly pilots. For a goal of ten paying customers, count money received. Track other signs of interest separately.

A compliment can help you improve the pitch. It can’t tell you whether someone will pay.

Don’t turn this sequence into a rigid script. A former colleague might be ready for a paid trial immediately. Someone who doesn’t know you may need to see the product working first. Match the next step to what the buyer needs to feel comfortable.

Aim for ten buyers who want roughly the same result. Ten unrelated requests can fill your calendar without showing you what product to keep building.

Choose a buyer whose problem you can recognise

A useful target describes a person, a visible reason to act, and a narrow result. 100 Tasks recommends defining the buyer through those details, including the costly workaround they use today.

“Small businesses that need AI” gives you almost nothing to work with. You can’t tell who needs help now. You can’t write a specific message. You can’t tell whether a new request fits the product.

Try a sentence you could test in a conversation:

We help [specific buyer] after [visible change] achieve [specific result] without [current workaround].

Suppose you’ve built software that turns approved project details into client updates. An illustrative starting point might be an agency owner who has just taken on more projects and still writes every update by hand.

That description gives you questions to investigate. Does the owner write those updates? Does the extra work hurt enough to change tools? Can your product handle their existing process?

Write down what would make a prospect a poor fit, too. Perhaps your product needs structured project data. Perhaps it can’t meet a buyer’s security requirements. Perhaps the buyer wants you to run their entire client process.

Treat those limits as part of the offer, rather than awkward facts to reveal after payment.

You don’t need to pick your permanent market before making a sale. Pick a starting group narrow enough to compare conversations. Keep it steady while you gather evidence, then change it when the evidence gives you a reason.

If every conversation describes a different job, narrow the buyer or the problem before broadening the feature list.

Find prospects through introductions and visible needs

Start with people you know, then ask for introductions to people who match your chosen buyer. Mistral Venture Partners’ playbook describes early customers coming from founders’ networks, introductions, and direct outreach.

The playbook draws on more than 200 interviews. It says the first one to three customers tend to come from a founder’s network or past job, with later early customers coming through outreach. That’s a reported pattern, not a requirement to arrive with a useful address book.

Make introduction requests easy to understand. “Know anyone who might use this?” forces your contact to work out the market for you.

Instead, describe the buyer and the situation. For the project-update example, ask whether they know an agency owner who still writes client updates manually. Give them a short description they can forward without rewriting.

If you don’t have relevant contacts, build a prospect list from public evidence. Look for clues such as:

• A person describing the exact problem in a public discussion.
• A job advert that includes work your product helps complete.
• A company change that could make the current workaround harder to maintain.

These are reasons to investigate, not proof that someone wants your product. A job advert might show a need, or it might show that the company prefers hiring someone.

Record the evidence next to each name. Before sending a message, finish this sentence: “I’m contacting this person because…”

If the answer is only their job title, keep researching. You want a credible reason for the conversation, not a large list you can claim to have contacted.

Useful outreach earns a small next step

Show that you understand something specific about the prospect before asking for their time. Stripe’s sales guide recommends proving you did some work, providing value, and asking for a specific, small thing.

Keep the message close to the problem you actually solve. Mentioning someone’s university or latest social post doesn’t help if it has nothing to do with the work.

For a prospect who publicly described struggling with client updates, an illustrative message could read:

You mentioned that writing client updates takes time away from project work. I built a tool that drafts them from approved project details. I made a sample using dummy data so you can see what it does. Would you like me to send it?

Only say you made a sample if you made one. Use dummy or permitted data, and label it clearly. Don’t imply that you’ve worked with a buyer’s private information.

The message gives the buyer a reason for the contact, something concrete to inspect, and an easy reply. It doesn’t ask them to book a long call before they know whether the product is relevant.

When someone responds, ask about their current process. Find out what happens when the work slips and what would make a trial worthwhile. Listen for the buyer’s own words rather than steering every answer toward your demo.

Follow up with a useful reason to return to the conversation. You might answer an unresolved question or share a relevant sample. Refer to what you discussed, and give them room to decline.

Record replies and refusals. Silence doesn’t tell you whether the problem is unimportant, the message missed, or the timing was wrong. Don’t rebuild your product around a guess about an unanswered email.

A paid pilot needs an outcome and an end date

Write down the promised result, the deadline, and the work you won’t do before accepting payment for a pilot. That boundary helps you avoid the conflicting demands described in Clarify’s account of Lorikeet.

Lorikeet’s co-founder described six early design partners whose needs diverged. The small team couldn’t give them enough attention to make them successful. Taking on a buyer creates work; you need to understand that work before you agree to it.

Keep the paid offer short enough for the buyer to understand without another meeting. Include:

• Outcome: the specific job the product will help complete.
• Deadline: when the pilot ends and you review the result.
• Price: what the buyer pays and when payment is due.
• Inputs: what access or information the buyer must provide.
• Exclusions: what you won’t build or operate during the pilot.

For a hypothetical tool that drafts client updates, the pilot might cover one existing project workflow. It might exclude moving historical records or building an unrelated billing feature.

Those limits aren’t an excuse to deliver less than you sold. They make the promise clear enough to judge. The buyer should know what success looks like, and you should know what you’ve agreed to deliver.

If a new request appears, compare it with the written offer. You can defer it, decline it, or agree to separate paid work. Don’t silently absorb it because the customer has already paid.

A short paid pilot gives you a defined piece of work to assess. An open-ended promise leaves you negotiating the product after the sale.

Reject requests that turn your product into unrelated jobs

Lorikeet reduced six early design partners to a smaller group with more needs in common. In Clarify’s account, co-founder Steve Hind explains that the original partners’ needs diverged beyond what the small team could support.

That example doesn’t mean you should reject every feature request. It means you should examine whether the work helps the product you intend to sell again.

Before accepting a request, ask:

1. Does it help the buyer achieve the result we already promised?
2. Would another buyer in our chosen group use it?
3. Can we support it without maintaining a separate version of the product?
4. What agreed work would we delay to build it?

Use the answers to make a decision, rather than treating a willingness to pay as the whole argument.

A request that improves the same workflow for another likely buyer deserves serious attention. A request that opens an unrelated business process deserves a separate decision. Neither becomes sensible just because someone calls it a small change.

You can offer hands-on help while learning how buyers use the product. Label that help and record the time it takes. Don’t describe a job as self-service if it only works because you quietly do the work behind the scenes.

If you’ve already agreed to unsuitable work, review your commitments before changing course. Explain what you can support and discuss a fair way to finish or end the arrangement.

Turning down a sale is uncomfortable when revenue is scarce. So is discovering that every customer expects you to build a different product. Make the trade-off visible before your calendar makes it for you.

Track paid results and the work behind each sale

Record why each buyer paid or refused, alongside what it took to serve them. 100 Tasks frames the first ten wins as a way to learn who buys, why they act, and what delivery earns another purchase.

Use a simple tracker you’ll actually update. Give each prospect one row and record:

• Buyer type and the reason you contacted them.
• Where the introduction or conversation started.
• The problem in the buyer’s own words.
• The offer, payment, and promised outcome.
• Setup hours, support time, and custom requests.
• The result and the reason they continued or stopped.

Keep cash received separate from expressions of interest. Keep delivery work visible beside the payment. You need both to judge whether you want another customer like this one.

After each paid engagement, compare what happened with what you expected. Did the buyer use the feature you thought mattered? Did setup require work you hadn’t priced? Did the promised result happen?

Look for repeated needs before rewriting your offer. One buyer’s unusual request may deserve a polite refusal. A request that keeps appearing among suitable buyers deserves investigation.

Use completed work to support your next conversation. With permission, publish a narrow case study showing the starting problem, what the product did, and the result you can verify. If you can’t verify a number, leave it out. A specific, honest account beats an inflated claim.

Before sending your next pitch, write down the buyer, the outcome, and the exclusions. Then find a person who matches. Count the payment when it arrives, record the work it creates, and ask whether you want to make that same sale again.