The Builder's GTM Playbook: Templates, Prompts, and Checklists
A dependable go-to-market process starts with verified product facts, turns market signals into testable positioning, and carries launch results into the next decision. This playbook gives technical founders a compact system they can run without a large marketing stack.
What problems and language appear in the evidence?
Evidence notes and open questions
3. Positioning
Which narrow claim is worth testing?
Hero and positioning hypothesis
4. Launch readiness
Can people reach value without preventable failures?
Launch checklist and channel plan
5. Learning loop
What happened, and what changes next?
Daily log and weekly decision
The sequence matters. Product facts keep research grounded. Research informs positioning. Positioning shapes the launch. Launch results create better questions for the next round.
Copy the Master GTM Runbook
Copy this template into your repository or working notes as GTM_RUNBOOK.md.
Markdown
# Builder GTM Runbook
## 1. Verified Product Facts
- Product name:
- Target user and operating context:
- Core input or trigger:
- Functional outcome:
- Current setup or deployment model:
- Verified constraints:
- Out of scope / non-goals:
- Claims we cannot make yet:
## 2. Market Research
- Research question:
- Sources reviewed:
- Recurring signals within the sample:
- Isolated observations:
- Important contradictions:
- Missing evidence:
- Next validation step:
## 3. Positioning Hypothesis
- User:
- Job to be completed:
- Current friction:
- Candidate headline:
- Supporting explanation:
- Verified proof line:
- Main assumption to test:
## 4. Launch Readiness
- [ ] Primary activation path completed with realistic input.
- [ ] Activation event visible in analytics.
- [ ] Error telemetry tested with an intentional failure.
- [ ] Billing sandbox covers success, decline, authentication, and refund paths.
- [ ] Webhook handling is verified and idempotent.
- [ ] Sensitive input masking is checked in telemetry tools.
- [ ] Recovery or rollback path is documented and tested.
- [ ] Launch channel rules and disclosure requirements are reviewed.
## 5. Learning Loop
- Primary channel:
- Two saved problem queries:
- Daily 30-minute block:
- Useful conversations this week:
- Activated users and observed blockers:
- Unknown attribution:
- Continue:
- Change:
- Stop:
Stage 1: Build a Product Fact Sheet
Before researching competitors or drafting copy, separate product facts from market assumptions.
Fact type
Question
User
Who can use the product in its current form?
Input
What must the user install, connect, upload, or provide?
Outcome
What task can they complete and verify?
Mechanism
What does the product do to produce that outcome?
Constraint
Where does it not work, or what still requires manual effort?
Non-goal
What is the product intentionally not designed to do?
Proof
Which claims are supported by a test, demo, record, or current product behavior?
Do not place an unverified customer pain inside the product fact sheet. A founder may believe users dislike a manual workflow, but that remains a research question until the evidence supports it.
A running example
Imagine a hypothetical CLI that removes common secrets from staging logs before upload. For this example, assume only these facts are verified:
It runs locally as a single binary.
It reads logs from standard input and writes a redacted stream to standard output.
It includes rules for common API keys and database connection strings.
It is released under the MIT License.
These facts do not prove that the tool catches every secret, meets a compliance standard, saves a specific amount of time, or replaces a security review.
Stage 2: Turn Public Signals Into Research Questions
Public material can reveal useful questions. It cannot tell you the whole market.
Source
Useful for
Cannot prove on its own
Customer reviews
Workflow friction and the language used to describe it
How common the problem is across all users
Pricing pages
Current limits, units, and feature gates
Whether a restriction is unfair or creates demand for another product
Changelogs
What a company chose to announce during a period
Full engineering effort, maintenance level, or roadmap priority
Community discussions
Problem context, terminology, and attempted workarounds
Market size or whether your product solves the problem
Label a problem as recurring only within the sample you reviewed. Two similar comments can justify another question. They do not justify a claim about most customers.
Copyable competitor research prompt
Markdown
You are helping a technical founder analyze market evidence.
Use only the source text provided below. Do not use outside knowledge about the
company, product, market, or user.
Research question:
[QUESTION]
Source type and capture date:
[REVIEWS, PRICING PAGE, CHANGELOG, OR COMMUNITY DISCUSSION]
[DATE]
Source text:
"""
[PASTE CONCISE SOURCE MATERIAL HERE]
"""
Start with 10-15 short, relevant excerpts. Split larger source sets into separate
passes instead of combining unrelated material.
Rules:
1. Separate direct observations from interpretation.
2. Call a finding "recurring within this sample" only when at least two
independent items support the same underlying issue.
3. Label a one-item finding "isolated observation."
4. Attach a short supporting quote or exact documented field to each finding.
5. Do not infer market size, user intent, product quality, or willingness to pay.
6. A user complaint can support a pain point. It cannot prove that our product
solves that pain point.
7. If the material does not support a conclusion, write "Insufficient evidence."
Return:
- Supported observations
- Recurring signals within this sample
- Isolated observations
- Contradictions or missing context
- Claims this evidence does not support
- The three smallest questions to validate next
For the hypothetical log-redaction CLI, a useful research question would be: "Do developers describe maintaining custom redaction rules as a repeated operational problem?" The research should test that question. It should not begin with the conclusion that the product has found demand.
Stage 3: Write a Positioning Hypothesis
Positioning should connect one user, one job, one friction point, and one supported reason to believe the claim.
Use this as a drafting model:
text
Positioning hypothesis = user + job + current friction + verified proof
The headline does not need to contain every element. The page, sub-headline, and proof line can share the work.
Pattern
Formula
Example
Remove a known friction
[Do task] without [workaround]
Verify database restores without maintaining custom recovery scripts.
Transform an input
Turn [input] into [output]
Turn webhook events into reconcilable ledger entries.
Name the specialist
The focused [category] for [user or environment]
An uptime monitor for single-container homelabs.
Replace a fragile process
Stop [fragile process]. [Reach outcome].
Stop scrubbing production logs by hand. Redact common secrets before export.
Divide the work
You [high-value work]. We handle [system work].
You write the queries. We handle pooling, caching, and failover.
For the running example, a cautious first hypothesis might be:
H1: Redact common secrets from staging logs before upload.
Sub-headline: Pipe logs through a local CLI that masks supported API keys and database connection strings before passing the cleaned stream to your upload script.
CTA: View the install command.
Proof line: Runs locally. Standard input/output workflow. MIT licensed.
Every statement comes from the fact sheet. The copy does not claim complete detection, compliance, or measured time savings.
Copyable positioning prompt
Markdown
You are helping a technical founder draft a positioning hypothesis.
Use only the verified product facts and supported research observations below.
Do not invent performance, privacy, compliance, customer, pricing, integration,
or setup claims.
Verified product facts:
[PASTE FACT SHEET]
Supported research observations:
[PASTE EVIDENCE-BOUND FINDINGS]
Instructions:
1. Draft three distinct hero options.
2. For each option, provide an H1, sub-headline, CTA, and proof line.
3. State the audience assumption behind each option.
4. Identify the strongest unsupported claim a careless writer might add.
5. Replace missing proof with "Missing evidence."
6. End with the smallest user test that could clarify which option is easiest
for the intended audience to understand.
A prompt can produce candidates. It cannot validate the position. Show the complete hero to relevant users and ask what task, audience, and difference they understood.
Stage 4: Verify Launch Readiness
A launch is a sequence, not one announcement.
Period
Focus
Evidence of readiness
T-14 to T-7
Activation, error handling, billing, privacy
Core path and failure paths tested
T-6 to T-1
Message, assets, channel rules, support ownership
Launch package reviewed and support plan assigned
Day 0 to Day 2
Smoke tests, replies, issue triage
Product remains usable and incoming problems have owners
Activation: Complete the primary value action with realistic input. Confirm the expected event appears in analytics.
Errors: Trigger a deliberate exception and confirm that the right person can find enough context to investigate it.
Billing: Use Stripe's testing environment to simulate the payment paths your product supports. Do not test with real payment details in live mode.
Webhooks: For Stripe, verify the webhook signature against the unmodified request body using the endpoint secret. Make processing idempotent and record processed event IDs. Follow Stripe's current webhook guidance.
Telemetry: Check the actual settings and captured payloads in your session recording or logging tools. Do not assume masking is enabled everywhere.
Recovery: Document and test the recovery or rollback path that fits your architecture. A database migration, serverless function, and desktop app may need different procedures.
Capacity: Protect expensive endpoints with appropriate limits, queues, or timeouts, then test the behavior users will see when a limit is reached.
Channels: Read current community rules, prepare disclosure where needed, and assign someone to answer questions after posting.
The goal of a daily routine is not to post everywhere. It is to keep useful conversations, product learning, and follow-up moving without taking over the workday.
Window
Action
Output
00 to 10 minutes
Check two saved problem queries and help with one relevant discussion when possible
One useful reply or a better search query
10 to 20 minutes
Turn a real product change, bug fix, or lesson into a short update
One reviewed post or draft
20 to 30 minutes
Follow up with one user or investigate one activation blocker
One next action with an owner
Stop when the timer ends. If no suitable conversation or follow-up exists, improve the search, document a question, or return to product work.
On Friday, replace the middle block with a review:
Which conversations involved the intended audience?
Which users reached the activation event?
Where did they stop or need help?
Which source brought them in? Mark it unknown when you do not know.
The hypothetical log-redaction CLI would move through the system like this:
Stage
Example decision
Product facts
Confirm local execution, supported secret patterns, standard input/output, and license.
Research
Test whether developers repeatedly describe custom redaction rules as a burden.
Positioning
Draft a narrow claim about masking supported secrets before export. Avoid complete-security or compliance promises.
Launch readiness
Test realistic log streams, failure behavior, documentation, telemetry, and recovery.
Learning loop
Record who understood the use case, who completed the first redacted export, and where setup failed.
The result of one launch might change the position. If users care more about local processing than script maintenance, the next headline should test that insight. The loop is working when evidence changes the next decision.
Where Tomako Fits
Manual work is useful at the start because it shows which context, evidence, and judgments matter. When the process becomes repetitive, Tomako is designed to turn connected product and market context into prioritized, reviewable growth work. Direction, publishing, outreach, spending, and other consequential decisions remain under human control.
Check your GTM readiness
Use the free GTM Readiness Checklist to identify product, positioning, launch, and measurement gaps before you promote the product.
Tiny is a co-founder of Tomako, working across the full path from growth strategy to channel execution. His experience spans influencer marketing, affiliate marketing, SEO/GEO, and paid acquisition. As an indie maker and creator, he is especially interested in how small teams can make better growth choices with limited resources. On the Tomako Blog, he writes about channel decisions, practical execution, and lessons from building and growing products.
Tiny
