147. Product Templates

Use these templates to keep product work tied to customer value. Early product documents should be short, opinionated, and easy to review.

For an early startup, the product document is a thinking tool, not bureaucracy. If a PRD does not change what you build, cut it down. If it prevents a wrong build, keep it.

PRD

Field	Fill this
Problem	What customer problem are we solving?
Target user	Who will use this?
Buyer or stakeholder	Who cares if this works?
Current workflow	What happens today?
Proposed solution	What are we building?
First value moment	When does the user feel value?
Success metric	What should move?
Non-goals	What are we not doing?
Risks	Product, technical, UX, business, compliance
Launch plan	Who gets it first?
Owner

PRD quality check:

Question	Good answer
Does this name a real customer problem?	Yes, with evidence from calls, usage, support, sales, or retention.
Is the first value moment clear?	A user can tell when the product helped.
Are non-goals explicit?	The team knows what not to build.
Is success measurable?	One primary metric and a few guardrails are named.
Is launch narrow?	First users/accounts are identified.

MVP scope

Field	Answer
Riskiest assumption
Target customer
Must-build
Manual workaround
Not-now list
Success metric
Kill criteria
First users
Review date

Add a scope boundary:

Must build	Do manually	Do later	Refuse
Needed for first value	Helps learn workflow	Useful after validation	Custom request from wrong segment

The “do manually” column is often the most useful MVP design space. It lets founders learn without pretending everything is already scalable.

Product assumption ledger

Keep a running ledger of assumptions. This helps a small team avoid treating guesses as product requirements.

Assumption	Type	Evidence	Confidence	Next action
	Customer / problem / UX / technical / pricing / channel	Interview, usage, support, sales, data, experiment	High / medium / low	Build / test / cut / revisit

Examples:

Assumption	Type	Good next action
Users will upload invoices without help	UX	Concierge 5 uploads and observe friction.
Admins need WhatsApp reminders	Problem	Ask for current reminder threads and frequency.
AI output will be trusted without review	Customer/trust	Test reviewed vs unreviewed output in a pilot.
Customers will switch from spreadsheet	Channel/adoption	Identify trigger that makes switching worth it.

Review this ledger before planning a sprint. If the riskiest assumption has not been tested, the roadmap may be fiction.

User story

Use this format:

As a [user], I want to [do action] so that [outcome/value].

Add acceptance criteria:

Criteria	Done?
User can complete the core action
Error state is clear
Success state is visible
Event is tracked
Support or help text exists if needed

User journey map

Map the smallest path from user intent to value.

Step	User question	Product response	Risk
Arrive	Am I in the right place?	Clear promise and context	Wrong audience or unclear copy
Start	What do I do first?	Simple first action	Setup friction
Input	What information is needed?	Minimal fields, import, or guided flow	Too much work
First value	Did this help me?	Output, insight, task completion, saved time	Value hidden or delayed
Repeat	Why come back?	Reminder, workflow, team use, habit	One-time novelty
Share/pay	Who else cares?	Export, invite, report, invoice, upgrade	Buyer not engaged

This map is especially useful before building onboarding, dashboards, and AI workflows where value can be hidden behind too much setup.

Activation checklist

Use this when users sign up but do not reach value.

Question	Notes
What is the first value moment?	The exact moment the user knows the product helped.
How many steps before value?	Count clicks, fields, imports, approvals, waiting time, and confusion.
What can be pre-filled or skipped?	Reduce setup where possible.
Where does trust need to be earned?	Data access, payments, AI suggestions, compliance, team invites.
What human help is acceptable early?	Founder onboarding, WhatsApp support, setup call, done-for-you import.
What event proves activation?	A tracked behavior, not a vague impression.

Early Indian B2B customers may accept human onboarding if the outcome is valuable. Do not confuse “not self-serve yet” with “not scalable ever.” First learn the value path; automate later.

Feature prioritization

Feature	Customer evidence	Impact	Confidence	Effort	Decision
	Quote, ticket, usage, revenue, churn, sales blocker	High / medium / low	High / medium / low	S / M / L	Build / test / defer / reject

Rule: if customer evidence is weak, confidence should be low no matter how exciting the feature feels.

Feature request triage

Not every customer request should become product.

Request type	How to respond
Repeated by target customers	Consider for roadmap after understanding the underlying problem.
From a large but off-segment customer	Treat carefully; may distort the product.
Custom workflow for one account	Price as services or reject unless it teaches the core market.
Compliance/security requirement	Evaluate seriously if it blocks target customers.
”Nice to have” convenience	Defer until core activation and retention are strong.
Workaround possible manually	Learn manually before automating.

Response template:

Thanks, this is useful. I want to understand the problem behind the request before we commit. Can you show me when this came up last and what happens if it stays unresolved?

This keeps the founder from accidentally letting the loudest customer write the roadmap.

Scope cut line

Use this when a feature is getting larger every day.

If the scope expands because…	Cut or move this
One customer wants a special case	Move to manual support, services, or a later enterprise path.
The team wants polish before proof	Ship the smallest credible version to trusted users.
Integration work is growing	Import/export manually for the first pilot if safe.
Edge cases dominate	Document known limits and solve the main path first.
Reporting is requested before usage exists	Track manually until the workflow proves it matters.

The founder’s job is not to make version one impressive. It is to make version one useful enough to produce truth.

Roadmap

Timeframe	Theme	Customer problem	Work	Success metric
Now
Next
Later

Keep roadmap items problem-led. “Build dashboard” is weaker than “help finance users identify overdue accounts in under 5 minutes.”

Roadmap health check

Run this before sharing a roadmap with team, investors, or customers.

Check	Good sign
Problem-led	Each item connects to customer pain, revenue, retention, risk, or learning.
Sequenced by risk	The riskiest unknowns are tested early.
Small enough	Work can ship in useful slices.
Sales-aware	Near-term product work reflects real buying blockers, not random requests.
Support-aware	Repeated support pain is visible.
Metrics attached	Each theme has a success signal.
Non-goals named	The team knows what is intentionally not happening.

If the roadmap is only a list of features, rewrite it as a list of customer outcomes.

India product notes

Add these checks when relevant:

Check	Why it matters
Mobile and low-bandwidth usage	Many users may inspect, approve, or coordinate from phone.
WhatsApp/email workflow	Product may need to fit existing coordination habits before replacing them.
GST/invoice/vendor context	B2B workflows often touch finance/admin realities.
Language and support	Adoption can depend on local language, training, or human support.
Data trust	Customers may worry about privacy, misuse, migration, or vendor lock-in.
Implementation burden	A product that requires heavy setup may need concierge onboarding or services pricing.

Do not add all of these by default. Use the ones that change adoption for your segment.

Release notes

Internal release note:

Field	Notes
Release name
Customer problem solved
What changed
Who is affected
How to use it
Metrics to watch
Known issues
Support note

Customer-facing version:

We improved [workflow] so you can [outcome]. You can find it under [location]. If you notice [known limitation], contact [support path].

Launch readiness checklist

Before releasing anything important, ask:

Area	Check
Customer	Which users/accounts will get this first?
Value	What job does it help them complete?
Data	Are events, logs, or manual tracking ready?
Support	Does the team know what changed and how to help?
Sales	Does this change pitch, demo, pricing, or objection handling?
Reliability	What could break and how will we know?
Rollback	Can we disable, hide, or manually recover if needed?
Communication	Who needs an email, WhatsApp note, call, or release note?

Early-stage launch discipline is not about ceremony. It is about protecting trust while still moving fast.

Bug report

Field	Notes
Summary
User/account affected
Severity	Critical / high / medium / low
Steps to reproduce
Expected behavior
Actual behavior
Screenshot/log/link
Business impact
Owner
Status

Product analytics plan

Value path step	Event	Properties	Success signal
Signup or account creation		segment, source, role
Setup completed		steps, time, errors
First value reached		workflow, account, user
Core workflow repeated		frequency, output
Output shared or used		recipient, channel
Payment or upgrade		plan, price, source

Product decision memo

Use this for major build/cut/pivot decisions.

Section	Prompt
Decision	What are we deciding?
Customer evidence	Calls, usage, support, sales, churn, revenue, or artifacts.
Options	The real options, including doing nothing.
Tradeoff	What do we gain and what do we give up?
Chosen path	The decision and owner.
Success signal	What should improve?
Review date	When will we judge it?

This is especially useful when founders disagree. The memo turns debate into evidence and tradeoffs instead of memory and volume.

Product review cadence

Review product work weekly in the early stage:

Review item	Question
Customer evidence	Which customer problem drove this work?
Activation	Are users reaching first value faster?
Support	What questions or manual help repeated?
Bugs/reliability	What broke trust?
Sales blockers	Which product gaps blocked good prospects?
Retention	What makes users return or disappear?
Scope	What should be cut, delayed, or refused?

Product packet by stage

Use different product templates depending on what the product is trying to prove. A pre-PMF company does not need the same product process as a scaling company.

Stage	Product packet	Main question
Problem exploration	User journey map, assumption ledger, customer notes, artifact review.	Do we understand the real workflow and pain?
MVP	MVP scope, scope cut line, PRD-lite, activation checklist.	What is the smallest useful product that can create evidence?
Early users	Release notes, bug report, product analytics plan, feedback triage.	Are people reaching value and coming back?
Sales-led product	Pilot success criteria, roadmap, objection map, decision memo.	Which product work helps sell, retain, or expand real customers?
Scaling product	Roadmap, prioritization, launch readiness, analytics dashboard.	Which bets improve retention, revenue, efficiency, or defensibility?

A founder-led product process should be opinionated but not stubborn. The founder brings taste, vision, and speed. Customers bring workflow reality. Analytics brings behavioral truth. Sales and support bring urgency and objections. Good product decisions combine these signals instead of worshipping one of them.

Product evidence gate

Before building a significant feature, answer these questions.

Question	Strong evidence	Weak evidence
Who needs this?	Named segment, customer, user role, or workflow.	”Users have asked for it.”
What problem does it solve?	Recent examples, support tickets, lost deals, usage drop, manual workaround.	Internal opinion or competitor copying.
Why now?	Revenue, retention, activation, compliance, trust, or strategic deadline.	It has been on the roadmap for a long time.
What is the smallest version?	Clear scope cut line and learning goal.	A large feature bundle with unclear success.
How will we know it worked?	Activation, usage, retention, conversion, support, revenue, or qualitative evidence.	”People will like it.”
What will we not build?	Explicit exclusions.	Scope grows during implementation.

Decision rule:

Build now if the evidence is strong and the success measure is clear.
Prototype if the workflow is unclear but the pain looks real.
Talk to customers if the request is repeated but poorly understood.
Park if the feature is mostly competitive anxiety.
Cut if the feature helps a few loud users while hurting focus.

In India, product evidence often hides in support calls, WhatsApp messages, implementation work, and founder-sales conversations. Do not wait only for dashboard data if the product is still early. But do not ignore behavior once usage data exists.

Copy-paste PRD-lite

Use this lightweight PRD for early-stage product work. It is intentionally shorter than an enterprise PRD because speed matters, but it still forces clarity.

Feature / experiment:

Customer segment:

Problem:

Why this matters now:

Riskiest assumption:

User job:

Success metric:

Non-goals:

Must include:

Can be manual:

Not now:

Edge cases intentionally ignored:

Instrumentation:

Launch audience:

Review date:

Kill / continue criteria:

Add the scope table:

Item	Build now	Manual	Later	Cut

And the launch risk table:

Risk	Guardrail
User does not understand value
Setup takes too long
Data is wrong or missing
Support burden rises
Metric is hard to read
Customer trust is at risk

A useful PRD-lite should make the team confident about what not to build. If the document only adds requirements, it is not doing its job.

Pilot Success Criteria Template

Use this when a product is being tested with early customers, especially in B2B, enterprise, or India-specific segments where pilots can become vague and endless.

Field	Fill this before the pilot starts
Pilot customer	Company/account and segment.
Buyer	Person who can approve payment or rollout.
Users	People who will actually use the product.
Problem	Specific workflow or pain being tested.
Current baseline	Time, cost, error, leakage, delay, manual effort, or current conversion before the pilot.
Product scope	What the pilot includes.
Manual support allowed	What founders/team will do manually during the pilot.
Success metric	The measurable outcome that means the pilot worked.
Trust requirement	Security, data, reliability, support, or implementation proof needed.
Commercial next step	Paid plan, contract, expansion, reference, or stop decision.
Review date	Date when the pilot is judged.

Pilot decision table:

Result	Decision
Success metric hit, buyer agrees value is real, payment path is clear	Convert to paid rollout or expansion.
Users get value but buyer is unclear	Run buyer discovery before extending product work.
Buyer likes it but users do not adopt	Fix workflow, onboarding, or user value before selling wider.
Value exists only with heavy manual founder work	Decide whether this is services, implementation, or a product gap.
No clear value by review date	Stop or redesign; do not let the pilot drift.

For Indian B2B, also confirm GST/invoice needs, payment owner, procurement steps, and who will chase internal approvals. A pilot that proves product value but never becomes cash is incomplete evidence.

Copy-paste feedback triage board

Use this when feedback comes from sales calls, support, customer success, analytics, and founder intuition at the same time.

Feedback	Source	Customer fit	Problem behind request	Evidence strength	Decision
	Sales / support / usage / founder / churn / renewal	Exact / adjacent / weak		Strong / medium / weak	Build / test / document / defer / reject

Decision guide:

Pattern	Product response
Repeated by exact ICP and blocks activation or payment	Prioritize or test quickly.
Repeated by weak-fit customers	Add to disqualifier list or defer.
One large customer asks for custom workflow	Price services or require strategic reason.
Support asks repeat but product value is clear	Improve onboarding, docs, or product affordance.
Sales asks for a feature to close one deal	Check whether the pain repeats across target customers.
Analytics shows drop-off but customers do not mention it	Observe users and inspect the workflow.

The goal is to understand the problem behind feedback. Customers request features in the language of their current workaround. Founders must translate that into product judgment.

Release decision record

Use this before shipping something that affects customers, trust, pricing, onboarding, security, or sales.

Release:
Owner:
Customer/user affected:
Problem solved:
Success metric:
Guardrail metric:
Known limitation:
Support plan:
Rollback or manual recovery:
Who must be told:
Review date:

Release readiness:

Area	Green	Red
Value	User can reach a clear outcome.	Team cannot explain the first value moment.
Scope	Limits and non-goals are clear.	Edge cases keep expanding.
Data	Required tracking/manual review exists.	Nobody knows how success will be judged.
Support	Team knows expected questions and owner.	Support will learn from customers live with no context.
Trust	Risk and communication are handled.	Customer data, billing, or reliability risk is vague.

Early startups should ship quickly, but not carelessly. The release record keeps speed connected to learning and trust.

Product debt review

Review product debt monthly, especially when support load grows or sales promises start shaping roadmap.

Debt	Symptom	Business impact	Decision
Onboarding friction	Users need founder help each time.	Slower activation, less delegation.	Fix / document / manually support / ignore for now
Fragile workflow	Errors or edge cases break trust.	Support load, churn risk.
Missing analytics	Team argues from opinions.	Weak product decisions.
Custom customer branch	One customer gets special behavior.	Roadmap complexity.
Technical shortcut	Change is slower or riskier.	Slower shipping, reliability risk.

Product debt is not automatically bad. Some debt buys learning speed. Bad debt hides whether the product is valuable, sellable, supportable, or trustworthy.

Use this rule:

Pay down debt when it blocks activation, retention, revenue, trust, or team speed. Leave it alone when it is ugly but not yet limiting learning.