How to Use Playbooks

Playbooks are for doing, not reading. Each playbook should produce evidence, a decision, or an artifact.

Use a playbook when the problem is practical: “We need customer interviews this week”, “We need to scope the MVP”, “We need a first sales call structure”, “We need to send a better investor update”.

Before starting a playbook

Fill this out:

Field	Your answer
Playbook	Which playbook are we running?
Owner	Who is accountable?
Timebox	When does this end?
Input	What information or list do we need before starting?
Output	What should exist when done?
Decision	What decision will this help us make?

If there is no owner, output, or decision, the playbook will become busywork.

How to run a playbook

1. Read the goal and “when to use this” section.
2. Gather the inputs before starting.
3. Timebox the work.
4. Use the included tables or templates.
5. Review the evidence with the person closest to the work.
6. Decide what changes next.

Choosing the right playbook

Choose the playbook that attacks the current bottleneck, not the one that feels most interesting.

Current bottleneck	Use this playbook first	Do not start with
You do not know who has the problem	7-Day Customer Discovery	MVP Scope
People like the idea but nobody acts	Pricing Test or Founder Sales Call	More homepage copy
Product scope is expanding	MVP Scope	Hiring or fundraising
You need first paying proof	First 10 Customers	First 100 Customers
Leads exist but calls are messy	Founder Sales Call	Paid marketing
Fundraising story is fuzzy	Investor Memo before Pitch Deck	Design polish
Team is reactive every week	Weekly Founder Review	More tools
You need help from advisors	Monthly Board/Advisor Update	Vague “can you help?” messages
You are stretched and want to hire	Hiring First Employee	A job post
Runway or conviction is collapsing	Startup Shutdown or survival review	Another growth experiment

Wrong playbooks are expensive because they create polished work around the wrong question.

Playbook cadence by stage

Run fewer playbooks than you think. A startup needs learning rhythm, not process overload.

Stage	Useful cadence
Idea/discovery	One discovery playbook per week until customer/problem patterns become clear.
MVP	One scope/review playbook per build cycle, usually weekly or biweekly.
First customers	Weekly sales call review and customer delivery review.
Fundraising	Investor memo once, deck practice weekly, investor CRM daily during active raise.
Hiring	One hiring playbook per critical role. Do not run a generic hiring process for every person.
Operating	Weekly founder review every week; monthly update every month.
Survival	Cash/runway/shutdown review as often as needed, sometimes weekly or twice weekly.

Process should match risk. When risk is high, review more often. When the company is stable, keep the rhythm lighter.

The playbook review meeting

Every playbook should end with a short review. Keep it practical.

Question	What a good answer includes
What did we do?	Actual activity, not intention. Calls made, tests shipped, offers sent, interviews completed.
What evidence did we collect?	Quotes, metrics, payments, objections, usage, replies, referrals, or failed attempts.
What changed our mind?	A concrete update to customer, problem, product, price, channel, or risk.
What decision follows?	Continue, narrow, change, stop, build, sell, hire, raise, cut, or wait.
What is the next owner/date?	One owner and one deadline.

Do not let the review become a status meeting. The point is to convert work into judgment.

Evidence types

Different playbooks produce different evidence. Treat them differently.

Evidence type	Strong examples	Weak examples
Customer evidence	Recent stories, artifacts, current workaround, willingness to introduce buyer	Compliments, survey opinions, “I would use this”
Sales evidence	Paid pilot, decision meeting, buyer email, procurement path, objection pattern	Demo praise, “circle back later”, vague interest
Product evidence	Activation, repeat use, completed workflow, support pattern, retained cohort	Signups, page views, one-time curiosity
Pricing evidence	Payment, budget owner conversation, negotiated scope, discount resistance	”Price seems fine” from non-buyer
Fundraising evidence	Investor follow-up, diligence request, partner meeting, committed amount	Friendly call, generic encouragement
Hiring evidence	Work sample, reference pattern, trial project, scorecard match	Resume brand, confidence, urgency
Cash evidence	Bank balance, collected cash, due invoices, signed payment terms	Booked revenue, optimistic pipeline

If the evidence is weak, the next playbook should create stronger evidence before the company makes a larger decision.

Good playbook outputs

Playbook	Good output
7-Day Customer Discovery	Interview notes, pattern table, continue/change/stop decision.
First 10 Customers	Target list, outreach, call notes, pilot next steps.
MVP Scope	Must-build, manual, not-now, success metric, kill criteria.
Pricing Test	Pricing hypothesis, buyer reactions, payment evidence, next price.
Founder Sales Call	Call structure, discovery notes, objections, follow-up action.
Weekly Founder Review	Scoreboard, decisions, risks, cash view, focus for next week.

Playbook mistakes

Mistake	Fix
Running too many at once	Pick the one tied to the riskiest assumption.
No timebox	Set a start date, end date, and review date.
No evidence	Define what proof counts before starting.
No decision	End with continue, change, stop, narrow, build, sell, hire, raise, or cut.
Treating templates as homework	Use only the parts that change behavior.

Playbook red flags

Stop and reset if you see these:

Red flag	Meaning
The owner cannot explain the decision the playbook supports	Busywork has replaced judgment.
The output is mostly internal opinion	You need customer, product, sales, cash, or hiring evidence.
The same playbook runs repeatedly with no new conclusion	The team may be avoiding a hard decision.
The founder keeps expanding the scope	Fear of learning may be hiding as thoroughness.
The playbook produces many tasks but no priority	The review failed to decide what matters most.

When a playbook exposes bad news, respect it. The purpose is not to feel good; the purpose is to avoid fooling yourself.

Quality bar

A playbook is not complete because the team filled a page. It is complete when one of these is true:

Completion signal	Example
Evidence improved	Ten interviews reveal the same painful workflow and current spend.
A decision was made	The team narrows from three customer segments to one.
A risk was reduced	A paid pilot proves someone will commit budget.
A risk was exposed	Users like the demo but the buyer has no urgency.
Work was stopped	A feature, campaign, or hire is paused because the evidence is weak.

Good playbooks sometimes tell you to stop. That is not failure. That is saved time.

India operating notes

For Indian founders, playbooks should include trust, collections, compliance, and human follow-up where relevant.

Playbook area	India-specific check
Discovery	Did the conversation source matter: warm intro, WhatsApp group, trade body, CA/CS/lawyer, customer referral?
Sales	Is the buyer the user, owner, promoter, finance head, procurement team, family member, or institution?
Pricing	Does the price account for onboarding, support, GST/TDS/payment friction, and delayed collection?
Product	Does adoption require training, regional language, mobile-first usage, WhatsApp support, or offline handoff?
Finance	Are signed contracts, invoices, and cash received tracked separately?
Hiring	Are salary, ESOP, notice period, remote work, equipment, probation, and first-month outcomes explicit?
Shutdown	Have CA, CS, lawyer, payroll, customers, employees, investors, vendors, and data/access obligations been mapped?

This is not bureaucracy. It is how operating reality enters the playbook.

Playbook roles

Even a tiny team should assign playbook roles. Otherwise the work becomes “everyone knows” and nobody owns the result.

Role	Responsibility
Owner	Runs the playbook and makes sure it ends with evidence or a decision.
Evidence keeper	Captures raw notes, screenshots, metrics, calls, quotes, and artifacts.
Decision maker	Makes or escalates the final call when evidence is reviewed.
Skeptic	Names weak assumptions and asks what would prove the team wrong.
Customer-facing lead	Handles outreach, interviews, demos, sales calls, or support follow-up.

One person can hold multiple roles. The point is clarity, not bureaucracy.

Before-and-after rule

Every playbook should have a before state and an after state.

Before starting	After finishing
Decision to be made	Decision made or explicitly deferred
Assumption being tested	Evidence strength updated
Owner and deadline	Owner for next action
Evidence standard	Actual evidence captured
Risk if wrong	Risk reduced, exposed, or escalated

If the after state is not clearer than the before state, the playbook was too vague or the review was too soft.

Playbook stop conditions

Some playbooks should stop early.

Stop condition	What it means
Evidence strongly contradicts the assumption	Do not keep collecting data to protect ego. Review and decide.
The wrong person is being interviewed	Fix the segment or buyer map before continuing.
The action depends on a missing prerequisite	Do the prerequisite first: prospect list, scorecard, pricing hypothesis, or cash view.
The team cannot name the decision	Pause and rewrite the playbook goal.
The work creates customer or team risk	Reduce scope, get advice, or change the process.

Finishing a playbook is less important than learning the right thing at the right time.

Playbook evidence review

At the end, review evidence in this order:

1. Raw evidence: what customers, users, buyers, candidates, metrics, or cash actually showed.
2. Pattern: what repeated across similar cases.
3. Contradiction: what did not fit the team’s story.
4. Decision: what changes now.
5. Next test: what remains uncertain.

Do not start with opinions. Opinions should respond to evidence, not replace it.

Playbook portfolio limit

Do not run too many playbooks at once. A small team can only absorb so much process before the process becomes the work.

Company state	Maximum active playbooks	Why
Solo founder	1	Focus beats breadth.
Two co-founders	1-2	Each founder needs direct ownership, not shared vagueness.
Early team under 10	2-3	More than this usually fragments attention.
Scaling team	3-5	Only if each has a clear owner, cadence, and decision.
Crisis mode	1	Survival, cash, trust, and decision speed matter more than process coverage.

If you feel the need to run five playbooks, the real problem is probably prioritization. Pick the one tied to the biggest risk.

7-day playbook sprint

Most practical founder questions can use a 7-day sprint.

Day	Work
1	Name the decision, owner, evidence standard, and stop condition.
2	Gather inputs: list, notes, metrics, cash view, candidates, or customer artifacts.
3-5	Do the field work: calls, tests, demos, pricing asks, reviews, or references.
6	Review raw evidence before interpretation.
7	Decide: continue, narrow, change, stop, build, sell, hire, raise, cut, or wait.

The sprint should end with a written decision. If the answer is “we need more information”, name exactly which information and why the first sprint was insufficient.

Playbook handoff note

When a playbook affects another person, write a handoff note. This matters when founders delegate sales follow-up, product fixes, hiring steps, customer onboarding, finance cleanup, or investor material.

Field	Prompt
Decision	What did the playbook decide?
Evidence	What raw evidence supports it?
Open risks	What remains uncertain?
Next owner	Who owns the next action?
Deadline	When does it happen?
Review	When will the founder inspect outcome?

Without a handoff note, the playbook’s learning stays trapped in the founder’s head.

Reader action

Pick one playbook and complete this:

We are running [playbook] from [date] to [date] so we can decide [decision]. The output will be [artifact/evidence].