Toolkit · Feature Alignment Document
Feature Alignment Document (FAD)
A problem-first alternative to the traditional PRD. Use this template to slow down on the problem, align stakeholders, and avoid shipping solutions in search of a problem.
- Forces you to write the problem before the feature.
- Builds a trail of evidence from discovery to solution.
- Makes “no” easier when a request doesn't clear the bar.
- Re-usable across features, teams, and roadmap cycles.
How to use this template
- 1. Start with just the problem name. No feature names yet.
- 2. Work through Problem Discovery and the checklist first.
- 3. Fill in constraints and pre-mortem before writing solutions.
- 4. Only then describe the solution and success criteria.
Tip: keep each FAD small enough to be read in under 10 minutes. If it feels like a spec novel, the problem might actually be multiple problems.
The Feature Alignment Template
Below is the full FAD template in a readable format. Use it as a starting point: copy, adapt, and make it your own for your team's rituals and tools.
[Problem / Feature Name]
Start with just the problem name before you know what the feature will be. That's not only okay, it's preferable.
1. Problem Discovery
The Problem Statement
What user or business problem does this solve? Be specific about the pain point. No solutions yet.
Discovery Tool: The Five Whys
If your problem statement feels surface-level, ask “why” 3–5 times. Stop when you hit something actionable within your domain. Document the root cause above.
Problem Validation Checklist
Before you build anything, ask yourself:
- Whose problem is this, specifically?Can you name the exact user segment or role? Not “our customers” — which ones?
- How painful is it?What evidence do we have from support messages, calls, data, behavior?
- What are they doing today to cope?Workarounds reveal pain depth; the more elaborate, the more serious.
- What measurable change would tell us the problem is gone?Define results (efficiency gains, reduced errors, lower stress), not the solution. How will we know if we've solved it?
- What are the competing constraints?Who else is affected? What trade-offs or conflicts exist across stakeholders?
- What won't we do?Set explicit boundaries — appetite, scope, and no-gos.
- Where does this problem begin?Trace it upstream. Is this problem a symptom of something earlier (process, policy, product)?
- What assumptions are we making?List them openly so they can be tested, not buried.
- What could make this the wrong problem?Pre-mortem the work — what would prove we're solving the wrong thing?
- If we solve this, what becomes possible next?Solving the right problem should expand what's possible for us and for our users.
2. Discovery Notes
What We Learned
Key insights from customer interviews, support tickets, usage patterns.
Edge Cases & Technical Complications
Potential challenges identified during discovery.
Open Questions
What still needs validation before we build.
3. Constraint Budget
Time & Effort Allocation
How much time are we willing to spend? We're solving this problem within constraints. There's always a better solution — we're finding the right solution for our budget.
Resource Considerations
Team size, dependencies, and technical debt affecting the timeline.
What We're NOT Doing
Explicit exclusions to fit our budget and keep the problem tractable.
4. Pre-Mortem: What If We're Wrong?
Failure Scenarios
It's 6 months later and this failed. What happened?
What Would Prove Us Wrong
What evidence would show we're solving the wrong problem?
Early Warning Signs
What metrics or feedback would signal we're off track?
5. Solution
What It Is (Plain English)
Describe the solution in terms anyone can understand.
Problem-Solution Fit
Map each pain point to how the solution addresses it.
- Pain Point 1: [from Problem Discovery]
How We Solve It: … - Pain Point 2: [from Problem Discovery]
How We Solve It: …
Why This Solution
Opinionated decisions and rationale. Why this approach over alternatives?
What This Doesn't Solve
Be honest about remaining pain and accepted trade-offs.
6. Success Criteria
Problem-Solved Metrics
How we'll measure whether the problem is actually gone (not whether the feature shipped).
Leading Indicators (early signals)
…
Lagging Indicators (ultimate outcomes)
…
7. Confidence Assessment
Rate your confidence (1–10):
- Problem Understanding: ___ /10
- Solution Fit: ___ /10
- Scope Accuracy: ___ /10
- Success Metrics: ___ /10
Overall: ___ /40 (need 32+ to proceed).
8. Logistics
Team & Responsibilities
List the team members involved, along with their roles and responsibilities.
Important Links
- Asana card / ticket
- Wireframes / design doc
- Overview video
Include links to relevant resources like the project management ticket, design documents, and any overview videos or briefs.
Terminology (define important terms)
List and define key terms related to the feature, alphabetized for easy reference, e.g.:
Term: definition