# Feature Evaluation Memo

## When to use

Use this template when you need to decide whether a feature, request, idea, or proposed improvement is worth building now, later, as an experiment, or not at all.

## Input needed

Prefer to gather the minimum useful context:

- request summary
- who proposed it
- target user or affected segment
- expected outcome
- available evidence
- current constraints
- timing or deadline pressure

If 1-2 critical premises are missing and would materially change the decision, ask about those first.

## Output goal

Produce a clear evaluation memo that helps a PM, lead, or stakeholder make a decision and understand why.

---

# Feature Evaluation Memo

## 1. Request summary

- What is being requested?
- Who raised it?
- What change is being proposed?

## 2. Problem behind the request

- What real problem is this trying to solve?
- Is this mainly a user problem, business problem, growth problem, retention problem, or perception problem?
- Is the request itself the right framing, or only one possible solution?

## 3. Target user and scenario

- Who is affected?
- In what scenario or workflow does the problem appear?
- How often does it happen?
- How important is it in the current user journey?

## 4. Expected value

### User value

- What user pain is reduced?
- What user outcome improves?

### Business value

- What metric or business result may improve?
- Is the impact direct or indirect?

### Strategic value

- Does it strengthen positioning, retention, monetization, efficiency, or differentiation?

## 5. Evidence and confidence

### Existing evidence

- user feedback
- usage data
- support tickets
- sales/customer requests
- competitive signals
- prior experiments

### Missing evidence

- What do we still not know?
- What assumptions are currently carrying the recommendation?

### Confidence level

- High / Medium / Low
- Why?

## 6. Cost, complexity, and risk

### Build cost

- engineering / design / ops effort

### Complexity

- cross-team coordination
- system dependencies
- rollout or support burden

### Risks

- weak adoption
- unclear value
- opportunity cost
- negative side effects
- delivery or quality risk

## 7. Trade-offs

- If we do this, what are we not doing?
- Does this strengthen a core workflow or distract from it?
- Is this a foundational improvement, a leverage point, or a short-term spike?

## 8. Recommendation

Choose one:

- Build now
- Prioritize later
- Run a lightweight experiment first
- Do not build now

### Recommended decision

- [Fill in the decision]

### Why this is the right call

- 2-4 bullets explaining the logic

## 9. Conditions that may change the decision

- Which missing facts would change the recommendation?
- Under what future conditions would this move up or down in priority?

## 10. Next actions

- What should happen next?
- Who needs to be involved?
- What evidence or experiment is needed before final commitment?

---

## Notes for use

A strong evaluation memo should:

- define the real problem, not only restate the request
- make assumptions explicit
- separate value from enthusiasm
- show trade-offs clearly
- end with a usable recommendation
