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 have defined the audience, found the people, started connecting, and begun publishing around their problems. The sequence below shows how to carry that preparation through a launch. Its numbers are planning examples for your own funnel.
Section 01First, check whether this playbook fits
This is one relationship-led acquisition motion, not a complete 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. |
Section 02Plan 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.
Section 031. 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 even warns that an overly specific persona may return no results.
- Write the person filters: job title, seniority, function, location, and any disqualifying role.
- Write the company filters: industry, headcount, geography, business model, and any condition required for the pain to exist.
- Separate must-haves from context: a must-have decides fit; context only helps you understand the person.
- Save the persona and add exclusions: current customers, competitors, irrelevant regions, unsuitable company types, and anyone you should not contact.
- 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.
Section 042. 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 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. |
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. |

Section 053. 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 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.
Section 064. 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? |
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
- Open on one recognizable moment. Name the meeting, spreadsheet, handoff, alert, or choice where the pain becomes real.
- Show the costly default. Explain what the team usually does and why that response fails.
- Add one concrete observation. Use a decision, example, screenshot, small piece of analysis, or firsthand lesson you can defend.
- Give one usable move. A check, template, sequence, or sentence is more useful than broad encouragement.
- 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.
Section 075. 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.
- Publish the day's post after one edit for specificity and one edit for unsupported certainty.
- Reply to useful comments with a real answer, follow-up question, or example. Do not convert a comment into an instant sales message.
- Read selected buyers' posts and comment only when you can add something specific.
- Update the ledger with the exact event, date, pain language, and stage change.
- 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.
Section 086. 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. |
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.
Section 097. Segment the launch by earned relationship state
When the product is ready, Apollo's 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. |
For United States commercial email, the FTC says CAN-SPAM applies to B2B messages too. 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.
Section 10The 2,000-person scenario, without the wishful math
Suppose the audited Apollo 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 counts illustrate the funnel math; replace them with your own observed numbers.
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.
Section 11Copy 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.
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.
Section 12What 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.
Section 13Patient 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.


