A first customer message should explain why you chose this person. Connect a verifiable fact about their business to a problem your product might help with, then ask a question they can answer or correct.
For personalized first customer outreach, start with one recipient. Aim to learn how the work happens today and whether your problem hypothesis holds up. A substantive reply gives you something to investigate; willingness to buy remains a separate question.
Choose the recipient before writing the opener
Finish this sentence privately:
This person may care about our product because [public evidence connecting their role to the work], and [observable business context] makes [possible difficulty] worth asking about.
Look for a business page, product announcement, job description, or public professional post that connects the person or team to the work you address. Check the date and whether the information still applies.
You need a credible connection to the work, though exact ownership may remain uncertain. A title alone can leave too much unexplained: two heads of operations may own different workflows. If you cannot connect the role to the task, keep researching or choose another person.
April Dunford’s positioning guide starts with customers’ alternatives, then connects differentiated capabilities to value and the customers who care about it. Those alternatives can include spreadsheets, manual work, or keeping the current process. Read Dunford’s positioning guide.
Use that preparation to narrow your question. If you build software for reviewing client reports, ask how report review works today. A broad promise to improve agency productivity leaves the recipient to figure out where your product fits.
Keep the observation separate from the hypothesis
Write two lines before drafting:
- Observation: What does the public source establish?
- Hypothesis: What might that mean for the recipient’s work?
Suppose an agency’s service page says it provides weekly client reports. That establishes a reporting cadence. It tells you nothing about whether reports are late, employees dislike preparing them, or the agency needs new software.
You might hypothesize that checking those reports takes manual effort. Ask about the process so the recipient can confirm or reject that possibility. Opening with “Your team must be wasting hours on reporting” presents a guess as knowledge.
Keep only the business context that explains your question. Personal hobbies, family details, and unrelated posts add little to a question about report review. Remove a detail if its only purpose is to show how much research you did.
Use the FindVex pain-point evidence sheet guide to record observations and keep your interpretation separate. For this task, collect enough evidence to explain why one question belongs with one recipient.
Borrow the customer’s vocabulary carefully
In a hypothetical reporting conversation, a prospect might call the task “checking numbers before the client call.” That phrase makes the work easier to recognize than “AI-powered reporting quality assurance.”
Joanna Wiebe’s review-mining method asks writers to identify the audience, the solutions they want, and what they already use. In her Flow example, customer reviews also prompted questions for the developer about what the app could actually do. Read Wiebe’s guide to customer-language research.
Apply that method with clear boundaries. Another company’s employee may describe a complaint worth investigating, but their account cannot establish that your recipient has the same problem. Keep exact source wording separate from your interpretation. Write “you mentioned” only when that person did.
Check your product sentence just as carefully. Call a prototype a prototype. If it works only with uploaded files, say so instead of implying it connects to the recipient’s systems. The recipient needs an accurate description to decide whether the conversation is relevant.
Build a message around one answerable question
Include a business observation, your reason for asking, and one question in a short paragraph. Cut anything that does not help the recipient understand or answer; there is no required word count.
Use this template, then rewrite it to fit the recipient:
Hi [name], I saw [specific, current business fact] on [source]. I’m building [accurate product or prototype description] for [specific task]. I wondered whether [problem hypothesis]. How do you currently handle [one concrete part of that task]?
Keep the hypothesis and question focused on the same part of the work. A workflow question, a feedback request, and a meeting invitation ask for different commitments. When you still need to learn whether the problem exists, start with the workflow question.
State your commercial interest honestly. If you are building a product you hope to sell, say you are building it. Describing the conversation as “just research” would hide that purpose.
Worked hypothetical example: an agency reporting tool
Imagine a founder building a prototype that flags discrepancies between draft client reports and uploaded source spreadsheets. The founder finds a fictional agency, Cedar Lane Studio, whose services page describes weekly client reporting. Its team page lists Maya as the operations lead.
The reporting service and her operations role give the founder a reason to ask about the workflow. They leave report-review ownership and any problems unconfirmed.
A generic message might read:
Hi Maya, I love what Cedar Lane is doing. We’re building an innovative AI platform that saves agencies time and improves efficiency. Are you free for a 30-minute demo this week?
The praise could apply to almost any company. The product claim is broad, and the meeting request arrives before Maya has a reason to care.
A more specific draft would be:
Hi Maya, Cedar Lane’s services page mentions weekly client reporting. I’m building a prototype that compares draft reports with uploaded source spreadsheets and flags mismatches. I wondered whether checking those numbers is still manual for your team. How do you handle that check today?
This message explains the selection and describes a limited capability. Maya can explain the process, refer the founder to someone else, or say the check is already handled.
Suppose Maya replies, “Our reporting software handles that. Getting client commentary approved is the slow part.” This fictional reply challenges the founder’s hypothesis. Record it as a correction, with commentary approval as a separate problem to investigate.
Acknowledge the correction. If Maya seems willing to continue, ask about the approval process and be clear if the prototype cannot help with it. Her answer gives you a new question, not a feature you can promise.
If she instead confirms that manual checks are a recurring problem, offer a small next step suited to that answer, such as a walkthrough using synthetic data. Ask whether she wants it before sending it.
Keep LinkedIn outreach manual and selective
Use this approach for individual messages where LinkedIn makes messaging available to you. LinkedIn’s User Agreement prohibits scraping its services and using bots or other unauthorized automated methods to access the service, add contacts, or send messages. See LinkedIn’s User Agreement, section 8.2.
Set a stopping rule for research: once you have a credible business observation, a plausible connection to the person’s role, and one useful question, draft the message. If those remain unclear, skip the contact. Additional personal details will not repair a weak business connection.
Respect a refusal. If you follow up after silence, keep it brief and add a relevant clarification. Silence alone cannot tell you whether the message was seen, the timing was wrong, or the hypothesis missed.
Use a message log to decide what to change
For an initial learning exercise, choose a handful of recipients with comparable responsibilities and business context. Keep the core question consistent while making each observation specific. Record warm contacts separately from strangers because the relationship gives the conversation a different starting point.
Copy this log for each recipient:
Recipient and connection to the work:
Existing relationship, if any:
Business observation:
Source URL and date checked:
Problem hypothesis:
Exact message and date sent:
Reply, or no reply as of [date]:
What the reply established:
Outcome: confirmation / correction / acknowledgment / referral / stop request
Agreed next step, if any:
What to investigate or change:For Maya’s fictional reply, the outcome would be “correction.” The log would record that she says reporting software handles the checks, while commentary approval is slow. No next step has been agreed. The founder’s next decision is whether to investigate approvals and whether the product could plausibly help.
Count an agreed next step separately from a reply. A polite acknowledgment tells you less about the problem than a description of the current process. A small set of conversations can suggest where to investigate, but it cannot establish a reliable response-rate benchmark or prove that one wording caused better results.
Draft one message and check the reason for sending it
Choose one recipient and complete the observation and hypothesis fields in your log. Draft the message, then check it:
- The source is current enough to support the observation, and the person’s role has a credible connection to the question.
- The possible problem is phrased as a hypothesis the recipient can correct.
- Every product claim matches what exists today, including prototype and input limits.
- There is one main question the recipient can answer without booking a meeting or opening an attachment.
Underline the sentence that explains why you chose this person. If it would work unchanged for almost anyone, revise the recipient choice or business observation before sending. Record what an answer would help you decide.
