# The Patient GTM Playbook: Start Months Before Launch

> Use Apollo, LinkedIn, and 100 days of useful posts to identify the right buyers, track familiarity, and make an honest launch ask months later.

- Author: Rishikesh Ranjan · Published: Sep 16, 2026
- Type: Playbook
- Tags: GTM, Acquisition, Frameworks
- Growth levers: Acquisition (primary), also Revenue
- ~2507 words

---

A launch works differently when it is the first time you ask for attention, not the first time the market sees you. If you already know who you are building for, start the go-to-market work months before the product is ready. Build the right list, become useful to that audience in public, learn from their response, and save the commercial ask for the moment you can fulfill it.

I am running the pre-launch portion of this process now. I have defined the audience, found the people, started connecting, and begun publishing around their problems. The complete sequence has not reached launch and conversion, so this is a playbook in progress, not a field note claiming a finished result. The numbers later in the article are planning examples, not my results.

> **The operating rule:** A person can be a perfect fit and still be cold. [Apollo](https://get.apollo.io/rishikeshranjan) helps you select relevant people. Your work over the following months may earn familiarity. Only an observable interaction supports a warmer relationship label.

## First, check whether this playbook fits

This is one relationship-led acquisition motion, not a complete [customer acquisition strategy](https://www.productgrowth.blog/p/customer-acquisition-strategy). It assumes you can already describe the buyer, the painful situation, and the reason your product should help. You will still need positioning, pricing, onboarding, sales, and a product that keeps its promise. If the audience is still a guess, use the time for discovery interviews before you build a large contact list.

| Condition | Ready to proceed | If it is missing |
| --- | --- | --- |
| Named buyer | Two people on the team would approve or reject the same profile. | Write narrower role, company, geography, and exclusion rules. |
| Painful moment | You can describe when the problem happens and what the buyer does today. | Interview or observe buyers before creating content. |
| Credible product direction | The product and its core promise are stable enough to discuss the problem honestly. | Keep the work in discovery; do not tease a product you may not build. |
| Audience channel | The intended buyer actually reads or posts on LinkedIn, X, or another chosen channel. | Move the public work to the channel where they already spend time. |
| Named owner | One person owns list quality, publishing, replies, and the weekly review. | Reduce the scope until someone can run it consistently. |
*Readiness check for a relationship-led pre-launch motion.*

## Plan backwards from the earliest honest launch date

Six months is a useful planning frame, not a magic duration. Pick the earliest date when a new user could receive the value you intend to promise. Work backwards from that date and give each stage an output you can inspect. If engineering slips, extend the useful audience work. Do not create false urgency or keep hinting that a product is almost ready when it is not.

From roughly month six to month four, define the persona, audit the first records, build the ledger, and collect the language of the problem. From month four to month two, connect selectively and publish the first half of the content matrix. Use the response to remove weak topics and bad-fit people. In the final two months, deepen the useful topics, invite appropriate people into real conversations, confirm who explicitly wants an update, and prepare launch segments. The sequence matters more than the dates. List quality comes before scale, public usefulness comes before a commercial ask, and evidence of interaction comes before a warm label.

Give every stage one owner and one weekly deliverable. A founder can own the persona and publish, while a teammate maintains the ledger and checks exclusions, but nobody should assume the other person recorded a reply or opt-out. End each week with a short decision note: what changed in the audience, which problem language repeated, what you will adjust, and what stays frozen. That record will matter at launch, when memory tries to turn a weak signal into a warm relationship.

## 1. Build the Apollo persona, then audit the people

Start with the smallest useful persona. Apollo describes a persona as a reusable set of people and company filters, and its People search lets you combine that persona with more filters. That makes it suitable for a repeatable named-market search, but the software cannot decide which details matter to your product. [Apollo's persona guide](https://knowledge.apollo.io/hc/en-us/articles/4409500253837-Create-and-Use-a-Persona?utm_source=productgrowth.blog) even warns that an overly specific persona may return no results.

1. **Write the person filters:** job title, seniority, function, location, and any disqualifying role.
2. **Write the company filters:** industry, headcount, geography, business model, and any condition required for the pain to exist.
3. **Separate must-haves from context:** a must-have decides fit; context only helps you understand the person.
4. **Save the persona and add exclusions:** current customers, competitors, irrelevant regions, unsuitable company types, and anyone you should not contact.
5. **Audit the first 30 records manually:** read the profile, company page, and role. Mark fit or no fit and write one sentence explaining why.

Do not export thousands of records because the result count looks impressive. If the first 30 include many people who cannot experience the problem, return to the filters. The output of this step is not a big list. It is a search whose false positives you understand.

## 2. Export a working ledger, not a blast list

Apollo says a contact export can include business email details, email status and verification fields, and a LinkedIn URL. It also notes that export and enrichment behavior can vary. Treat those fields as inputs to review, not permission to contact everyone immediately. [Read Apollo's current export notes](https://knowledge.apollo.io/hc/en-us/articles/4409237712141-Export-Contacts-to-a-CSV?utm_source=productgrowth.blog) before choosing fields or spending credits.

| Ledger field | What it is for | Rule |
| --- | --- | --- |
| Person, company, role, geography | Identity and basic qualification. | Keep the source date so stale records can be reviewed. |
| Why this person fits | One human-written reason tied to the persona. | If you cannot write it, remove the contact. |
| LinkedIn URL and business email status | Find the public profile and prepare later segmentation. | A populated field does not establish accuracy, consent, or warmth. |
| Relationship state | Listed, followed, connected, exposed, engaged, conversed, opted in, or suppressed. | Move the state only after a recorded event. |
| Last meaningful touch and pain language | Preserve context for replies, content, and a possible launch note. | Record what happened, not what you assume they think. |
| Next action and owner | Make the motion operable across weeks. | Every active row has one owner and one truthful next step. |
*Minimum fields for a named-market relationship ledger.*

My rule is deliberately strict: relevance is selected, but familiarity is earned. An accepted connection is an event. It does not prove that the person remembers you, reads your posts, trusts your judgment, or wants a product update.

| State | Minimum observable evidence | What you may honestly infer |
| --- | --- | --- |
| Listed | The person matches the audited persona. | Relevant, but cold. |
| Connected | They accepted an invitation. | The connection exists. Nothing more. |
| Exposed | You have credible platform evidence that the person saw relevant work. | Possible awareness, not trust. |
| Engaged | They left a substantive comment, asked a question, replied, or repeatedly interacted with the topic. | Observable interest in the subject. |
| Conversed | You exchanged useful context about the problem. | A real relationship context exists. |
| Opted in | They explicitly asked for an update, beta, or launch notice. | You may send the promised update, subject to applicable rules. |
| Suppressed | They opted out, are a bad fit, or must not be contacted. | Do not send. |
*Proposed operating states. This is a measurement vocabulary, not an industry-standard funnel.*

![Six relationship states for patient go-to-market: listed, connected or exposed, engaged, conversed or opted in, match the launch ask, and keep list-only contacts cold.](https://www.productgrowth.blog/media/posts/patient-gtm-playbook/01-relationship-state-workflow.webp)
*The launch message should never claim a warmer relationship than the recorded event supports.*

## 3. Connect slowly and behave like a useful peer

Open the profile before you act. Follow the person when you do not know them. Send a connection request only when they already know and trust you, or when a genuine prior relationship means they can recognize you. For an unknown but relevant prospect, use following, InMail, Groups, or another channel that fits the platform and your context. A short invitation note can state the real relationship, but it should not disguise a pitch as networking. After acceptance, do not send an automatic sales sequence.

There is no honest universal daily quota in the platform guidance reviewed for this playbook. [LinkedIn says](https://www.linkedin.com/help/linkedin/answer/a551012/invitation-limitations?lang=en&utm_source=productgrowth.blog) it may restrict invitations when a member sends many quickly, accumulates ignored or pending invitations, receives spam reports, or uses prohibited automation. The same page says to invite only people you know and trust, and points to InMail and Groups for communicating with people you do not know. For eligible invitations, use a small manual batch that you can review. Slow down when pending invitations accumulate or the platform warns you. Do not automate invitations.

> **A connection request is not the campaign:** The work begins after the request. Publish something useful, reply when people engage, and learn their language. If the invitation exists only to unlock a pitch, the long horizon has already collapsed back into short-term outreach.

## 4. Turn one persona into 100 useful post prompts

Daily publishing becomes possible when you stop asking, ‘What should I post today?’ Build the backlog before you need it. Write ten painful moments the persona experiences, using their language wherever possible. Then examine each pain through ten editorial lenses. Ten pains multiplied by ten lenses gives you 100 prompts to judge, combine, or discard. It does not give you 100 good posts automatically.

| Lens | Question to answer | Example using a slow buyer-research problem |
| --- | --- | --- |
| Symptom | What does the painful moment look like? | The buyer-research doc has 80 links and no decision. |
| Cause | Why does it keep happening? | The team collects sources before agreeing on the question. |
| Diagnostic | How can the reader tell which problem they have? | Three checks for a research problem versus an approval problem. |
| Mistake | Which reasonable-looking move makes it worse? | Adding another tool before fixing the decision owner. |
| Tradeoff | What does the common advice ignore? | Faster research can reduce confidence when source quality is hidden. |
| Workflow | What sequence can the reader follow? | Question, evidence threshold, source review, decision note. |
| Template | What can the reader copy? | A one-page evidence memo with an owner and expiry date. |
| Teardown | How would you improve a familiar example? | Rewrite a cluttered research brief around one decision. |
| Objection | What would a skeptical reader challenge? | ‘We cannot decide with only five interviews.’ |
| Question | What narrow experience can the audience contribute? | Which research step causes the longest delay on your team? |
*Use these ten lenses across ten real pains to create 100 candidate prompts. The example pain is illustrative.*

The default in this playbook is one useful post a day for 100 days because the long run forces you to understand more than one obvious pain. Keep that cadence only while the usefulness floor holds. Batch the research and rough drafts, but spend real time editing each post. If the persona is active on X, adapt the same insight to the way people read there. Do not copy and paste a LinkedIn essay into every channel and call it distribution.

### A five-part LinkedIn post anatomy

1. **Open on one recognizable moment.** Name the meeting, spreadsheet, handoff, alert, or choice where the pain becomes real.
2. **Show the costly default.** Explain what the team usually does and why that response fails.
3. **Add one concrete observation.** Use a decision, example, screenshot, small piece of analysis, or firsthand lesson you can defend.
4. **Give one usable move.** A check, template, sequence, or sentence is more useful than broad encouragement.
5. **Ask one narrow question.** Invite the reader's experience without fishing for empty agreement.

Weak: ‘Great GTM is about knowing your customer. Here are five ways to improve customer understanding.’ Nothing in that opening tells a product marketer that the post came from someone who understands their day.

Stronger: ‘Your launch brief says the buyer is a head of product. The sales calls say the decision stalls with security. Before writing another campaign, label the last ten lost deals by the person who stopped them. You may have a buying-committee problem, not a messaging problem. Which role appears latest in your deals?’ The rewrite identifies a moment, a default mistake, a usable check, and a question the intended reader can answer.

## 5. Run the daily relationship loop

Publishing is only half the work. The other half is paying attention. A bounded daily routine keeps the audience research attached to the content instead of turning the account into a broadcast feed.

1. **Publish the day's post** after one edit for specificity and one edit for unsupported certainty.
2. **Reply to useful comments** with a real answer, follow-up question, or example. Do not convert a comment into an instant sales message.
3. **Read selected buyers' posts** and comment only when you can add something specific.
4. **Update the ledger** with the exact event, date, pain language, and stage change.
5. **Feed the learning back** by turning the best question, objection, or phrase into a future prompt.

If the intended people do not respond, do not solve the problem by posting twice as much. Inspect the audience, topic, specificity, and distribution. A month of silence from the right people is a reason to interview them, narrow the pain, or change the channel. It is not evidence that you need more motivational hooks.

## 6. Review the motion every week

The weekly review is where patience becomes a system instead of a slogan. Keep raw counts beside rates so a small denominator cannot create a dramatic story. Compare the motion with your own previous weeks, not with a creator's screenshot or a universal engagement benchmark.

| Question | Record | Decision |
| --- | --- | --- |
| Is the list still clean? | Profiles audited, accepted, rejected, and rejection reasons. | Keep, narrow, or rewrite a persona filter. |
| Are invitations appropriate? | Sent, accepted, pending, declined, and any platform warning. | Continue, slow down, or follow without inviting. |
| Which topics reached the intended people? | Named relevant engagers and the post or question involved. | Extend, revise, or stop a topic. |
| Did familiarity move? | Counts in listed, connected, exposed, engaged, conversed, and opted-in states. | Continue the motion or investigate the stuck transition. |
| What did the market teach us? | Repeated phrases, objections, workarounds, and questions. | Change content, product assumptions, positioning, or the persona. |
*Weekly scorecard. Each rate should show its numerator, denominator, and time window.*

Assign one owner to write the weekly note. The note can be short: what changed, why you think it changed, what you will do next week, and what evidence would prove that explanation wrong. The point is not a dashboard. The point is to stop the team from repeating 100 days of an unhelpful behavior.

## 7. Segment the launch by earned relationship state

When the product is ready, [Apollo's](https://get.apollo.io/rishikeshranjan) email field becomes useful because it gives you a way to reach the named market. It does not make one launch email appropriate for every person. Clean the ledger, remove suppressed and bad-fit records, verify the current audience and sending setup, and match the message to the strongest truthful state. When the history is incomplete, downgrade the contact.

| Segment | Honest opening | Do not say |
| --- | --- | --- |
| Conversed or opted in | ‘You asked me to share this when it was ready. We just opened...’ | Anything beyond the conversation or permission that actually occurred. |
| Engaged | ‘You joined the discussion about [specific problem]. I built a first version for that workflow...’ | ‘As you know’ unless they truly do. |
| Connected or exposed | A brief, relevant note that explains why the problem may matter to their role. | A claim that they follow your work or have been waiting for the launch. |
| Listed only | Cold outreach, if appropriate, with a clear reason for relevance and an easy way to stop messages. | Any invented shared history. |
| Suppressed or wrong fit | No message. | Nothing. Keep them excluded. |
*Message templates are starting points. Check accuracy, audience rules, and applicable law before sending.*

For United States commercial email, [the FTC says CAN-SPAM applies to B2B messages too](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business?utm_source=productgrowth.blog). Its guide calls for accurate sender information, non-deceptive subjects, identification as an advertisement, a valid physical postal address, a clear opt-out, and honoring opt-outs within 10 business days. That is a scoped US baseline, not a global permission slip. Other jurisdictions and campaign facts can impose different requirements. Get appropriate legal advice for your audience, geography, data source, and channel.

## The 2,000-person scenario, without the wishful math

Suppose the audited [Apollo](https://get.apollo.io/rishikeshranjan) search contains 2,000 people. You send selective connection requests over time and 500 accept. Later, 100 of those people produce an observable engagement around the problem. These are illustrative counts, not a benchmark and not a forecast for this playbook.

| Metric | Value |
| --- | --- |
| Illustrative connection acceptance | 25% — 500 accepted connections / 2,000 listed contacts |
| Illustrative engagement among connections | 20% — 100 engaged contacts / 500 accepted connections |
| Illustrative engagement from the full list | 5% — 100 engaged contacts / 2,000 listed contacts |

The useful conclusion is smaller than ‘100 people will try the product.’ At most, 100 people qualify for an engagement-based launch segment. Some may not remember you, care about this version, have budget, or be ready now. The other 1,900 are not warm by subtraction. They are connected without observed engagement, merely listed, or excluded. Treat each group according to its evidence.

## Copy these operating templates

### Apollo persona spec

- Buyer role and seniority: *\[who owns or feels the problem]*
- Company conditions: *\[industry, size, geography, business model, relevant technology]*
- Painful moment: *\[when the problem becomes visible]*
- Current workaround: *\[what they do today and its cost]*
- Must-have filters: *\[conditions without which the pain is unlikely]*
- Exclusions: *\[bad fits, existing relationships, competitors, restricted audiences]*

### Daily publishing and engagement check

- The post teaches one thing to one persona.
- The opening names a moment the persona can recognize.
- The example is real, clearly illustrative, or properly sourced.
- The post still helps after every product mention is removed.
- Useful replies receive useful answers.
- Every relationship-state change has an event and a date.
- One audience lesson returns to the prompt backlog.

> **Steal this:** The launch is not the start of distribution. It is the moment distribution finally has something to ask for. Spend the months before it making the audience definition sharper and your usefulness visible.

## What this playbook cannot promise

Familiarity does not guarantee trust, trial, or purchase. A useful public body of work may reveal that the audience is wrong, the pain is weak, or the product promise is unconvincing. That is valuable information before launch, even though it is not the outcome you hoped to report. Apollo records can be incomplete. Platform rules can change. A connection can forget you. A thoughtful reader can still prefer another product.

The strategic advantage is not a guaranteed warm list. It is time. Starting months early gives you more chances to correct the persona, learn the buyer's language, improve the product story, and make a launch request that follows evidence instead of pretending a scraped address is a relationship.

## Patient GTM FAQs

#### How early should a founder start this GTM playbook?

Start when the buyer and painful situation are stable enough to guide a persona and useful content. Three to six months creates room for a meaningful body of work, but the right lead time depends on the product and market. If the audience is still uncertain, begin with discovery rather than list building.

#### Does an accepted LinkedIn connection make a lead warm?

No. It proves only that the connection was accepted. This playbook reserves engaged, conversed, and opted-in labels for observable events so the later message does not invent familiarity.

#### Should I really post every day for 100 days?

Daily posting is the operating default here, not a universal law. Use the 10 x 10 matrix to prepare 100 prompts, then keep the cadence only while every post clears the usefulness floor. Fewer specific posts are better than daily filler.

#### When should I use the email Apollo provides?

Use it when you have a legitimate, appropriate message and a product or next step you can deliver. Segment by the actual relationship state, verify the data, suppress bad-fit and opted-out contacts, and check the law and provider requirements that apply to the audience and geography.

#### Can I automate LinkedIn invitations?

Do not automate them. LinkedIn's reviewed guidance names suspected prohibited automation as one reason an account may be restricted. It also says to invite people you know and trust, with InMail and Groups as alternatives for people you do not know. For eligible invitations, use a small manual batch and respond to platform feedback.

#### What if the product or persona changes before launch?

Pause the outreach, update the persona, and re-audit the list. Keep publishing only where the subject is still useful to the same audience. Do not force old contacts into a new story because you already spent time collecting them.

**Next job: Audit the first 30 people.** Define one Apollo persona, inspect the first 30 results manually, and write one sentence explaining why each accepted contact fits before you export the full list. Create the persona and complete a 30-profile fit audit.

---

All posts: https://www.productgrowth.blog/archive · Site: https://www.productgrowth.blog