The best template for a feature kick-off document should answer five questions before any design or engineering work begins: why does this feature exist, who is it for, how will we know it succeeded, what are the constraints, and what decisions are still open.
Most feature kick-offs fail not because the PM didn't write enough — they fail because the document answers the wrong questions. This template is organized around what engineering, design, and data science actually need to do their jobs, not around what looks good in a PRD review.
Feature Kick-Off Document Template
1. Problem Statement
One-sentence problem: [Complete this sentence: "Right now, [persona] can't [do X] without [experiencing friction Y], which causes [business impact Z]."]
Evidence:
- Quantitative: [metric, current value, and how it was measured]
- Qualitative: [customer interview findings, support ticket volume]
Why now: [What changed recently — competitor launch, user research wave, OKR cycle — that makes this the right time to solve this]
2. User and Persona
Primary user: [Be specific — "enterprise account admins with >100 seats" not "enterprise users"]
User goal: [What job is the user trying to get done when they hit this problem]
Frequency and context: [How often does this user encounter this problem, in what context]
3. Proposed Solution
Solution description: [2–3 sentences maximum. No wireframes here — those go in the design section]
Out of scope: [Explicit list of what this feature does NOT do]
Key user flows:
- [Primary flow]
- [Secondary flow, if any]
- [Error or edge case handling]
4. Success Metrics
Primary metric: [One metric only. Must be measurable before launch]
Secondary metrics: [2–3 supporting metrics that indicate the feature is working as intended]
Counter-metrics / guardrails: [What must NOT degrade as a result of shipping this feature]
Measurement plan: [How and when each metric will be measured — event names, dashboard links, measurement window]
5. Constraints
Technical constraints: [Existing system limitations that bound the solution space]
Timeline constraint: [Hard deadline if one exists, and why it exists]
Resource constraints: [Engineering bandwidth, design availability, data requirements]
Compliance/legal constraints: [GDPR, SOC 2, ADA, or other requirements that apply]
6. Open Questions
| # | Question | Owner | Decision Needed By | |---|---|---|---| | 1 | | | | | 2 | | | | | 3 | | | |
7. Launch Checklist
- [ ] Feature flags configured (rollout % defined)
- [ ] Analytics events implemented and verified in staging
- [ ] Documentation updated (internal and/or user-facing)
- [ ] GTM and sales enablement notified with launch date
- [ ] On-call runbook updated with rollback procedure
- [ ] Success metrics dashboard created and shared
How to Fill Out Each Section
Section 1: Problem Statement
According to Lenny Rachitsky's writing on PRD best practices, the most common failure mode in feature kick-off documents is a vague problem statement that everyone interprets differently — engineering builds what they think was asked for, design solves a slightly different problem, and PM ships something that doesn't move the metric.
Good problem statement: "Right now, enterprise admins can't provision user accounts in bulk without using our CSV import, which breaks for files over 500 rows and causes support tickets on 30% of enterprise onboardings."
Bad problem statement: "Users need a better way to manage their accounts."
Section 2: User and Persona
The persona section should be specific enough that every team member could describe the same user in an interview. Avoid "users" or "customers" — both are meaningless without qualification.
Section 3: Success Metrics
According to Shreyas Doshi on Lenny's Podcast discussing good product work, the discipline of defining exactly one primary metric per feature — before any design work begins — is the single highest-leverage practice for making product teams more outcome-oriented and less output-oriented.
The primary metric must be:
- Measurable with instrumentation that already exists (or that can be built in the same sprint)
- Attributable to this feature specifically (not a lagging indicator that combines many factors)
- Agreed upon by PM, engineering lead, and data science before kick-off begins
Section 4: Constraints
According to Annie Pearl on Lenny's Podcast about Calendly's product process, the constraints section is the most underwritten section in most kick-off documents — explicitly documenting technical constraints prevents the design team from producing concepts that can't be built in the given timeline.
Section 5: Open Questions
The open questions table has two purposes: it documents what is unknown at kick-off, and it assigns ownership for resolving each question by a specific date. Questions without an owner and a deadline don't get answered.
FAQ
Q: What is a feature kick-off document? A: A structured document that aligns product, engineering, design, and data science before any implementation work begins, covering problem statement, user persona, success metrics, constraints, and open questions.
Q: What should be included in a feature kick-off document? A: Problem statement with evidence, specific user persona, proposed solution with explicit out-of-scope items, exactly one primary success metric plus guardrails, technical and timeline constraints, and an open questions table with owners and deadlines.
Q: How is a feature kick-off document different from a PRD? A: A kick-off document is a shorter, decision-enabling artifact focused on alignment before implementation. A PRD is a more complete specification that evolves through implementation. The kick-off document typically becomes the header section of the PRD.
Q: Who should be in a feature kick-off meeting? A: PM, engineering lead, design lead, and data science or analytics. Optional: legal/compliance representative if the feature has regulatory implications.
Q: How long should a feature kick-off document be? A: One to two pages. If it is longer than two pages before design artifacts are attached, the scope is too broad for a single kick-off.
HowTo: Create a Feature Kick-Off Document
- Write the one-sentence problem statement using the formula: right now, persona cannot do X without friction Y, causing business impact Z
- Define the primary user specifically enough that every team member would describe the same person
- Define exactly one primary metric that is measurable with existing instrumentation and attributable to this feature
- Document all constraints explicitly: technical, timeline, resource, and compliance
- Create an open questions table with a named owner and decision deadline for every unresolved item before kick-off begins