Approaches to consider

# Approaches to consider

Use early in definition, or when a feature has more than one viable solution and the team needs the trade-offs side by side.

## Definitions

Use these meanings consistently in every step.

- **Feature:** The feature record being explored, or the feature whose record link the user pasted into the chat
- **Approach:** One distinct way to solve the problem, described by what the customer would do differently
- **Effort:** A rough size of small, medium, or high, based on how much has to be built and how many parts of the product it touches
- **Extends the system:** Builds on records, fields, views, relationships, or workflows that already exist rather than introducing an isolated capability

## Workflow

1. Read the feature, its description, its linked ideas, and the records on the **Related** tab
2. Restate the problem in one or two sentences and confirm it with the user. Approaches are only comparable against a shared problem.
3. Confirm how many approaches to include and what criteria to compare them on. Default to three approaches compared on effort, pros, and cons.
4. Generate the approaches. Each uses a different mechanism, not the same mechanism at a different scope.
5. For each approach, describe what the customer does, then list three to five pros and three to five cons. Cons include what the approach forecloses later, not only what it costs now.
6. Assign a rough effort and state what drives it
7. Note how well each approach fits the existing product model, and say plainly which ones would introduce a one-off capability
8. Recommend one approach and state what would have to be true for a different one to win

## Rules

- If the feature or the problem is unclear, ask short follow-up questions before generating approaches
- Approaches that differ only in scope are one approach. Merge them and say so.
- Every approach gets a genuine set of cons. An approach with no downside has not been examined.
- Prefer approaches that extend existing systems, and name the long-term cost when one does not
- Reference the feature and related records by reference number and name
- Do not update the feature. Present the table and let the user decide.
- Headers use sentence case. No em dashes, en dashes, or curly quotes.

## Output

```
## Problem  
<one to two sentences, without a solution in it>  
  
## Approaches  
| Approach | What you would do | Effort | Fits the product model |  
  
### <approach name>  
\*\*Pros\*\*  
- <pro>  
  
\*\*Cons\*\*  
- <con, including what it forecloses>  
  
## Recommendation  
<which approach, and why, in three to five sentences>  
  
## What would change the recommendation  
- <condition, and the approach it would favor>
```

## Quality checks

- The problem statement contains no solution
- Every approach uses a different mechanism
- Every approach carries both pros and cons
- The recommendation names the conditions that would overturn it