/define — Product Owner Interview
Overview
Define requirements by interviewing the user. The interview IS the value — a requirements doc produced without conversation is just guessing.
Core principle: Ask, don't assume. Every assumption is a question you didn't ask.
When to Use
-
User describes a new feature, bug, or change request
-
Work needs to be broken down before architecture or implementation
-
You need to understand scope, personas, and success criteria
The Process
- Gather Context (silent — don't show this to user)
-
Read CLAUDE.md and recent commits
-
Identify relevant source files for the topic
-
Note existing patterns and constraints
- Interview — One Question at a Time
Use AskUserQuestion with multiple-choice options where possible.
You MUST ask questions. You MUST NOT produce requirements without interviewing.
Cover these areas, one question per turn:
Area What to Ask
Scope What should this do? What should it NOT do?
Personas Who uses this? What's their context/skill level?
Success How will we know it works? What does "done" look like?
Edge cases What happens with empty/invalid/unexpected input?
Constraints Backward compat? Performance? Dependencies?
After each area, summarize what you heard (200-300 words) and ask the user to confirm before moving on.
- Produce User Stories
Use INVEST format. Each story must be:
- Independent, Negotiable, Valuable, Estimable, Small, Testable
Template:
Story N: [Title]
As a [persona from interview], I want [functionality], So that [benefit].
Acceptance Criteria
Given [context]
When [action]
Then [expected result]
Edge Cases
Given [edge case context]
When [action]
Then [expected handling]
Present stories to user for validation before finalizing.
### 4. Save and Commit
Ask user for a short name, or derive from the topic.
docs/plans/YYYY-MM-DD--requirements.md
Commit: `docs: add <name> requirements`
### 5. Next Step
> Requirements saved. When ready, use `/architect` to design the solution.
## Common Mistakes
| Mistake | Fix |
|---------|-----|
| Producing requirements without interviewing | STOP. Ask questions first. Always. |
| Asking multiple questions at once | One question per `AskUserQuestion` call |
| Including implementation/architecture details | Stay in problem space. Code design is `/architect`'s job. |
| Listing "open questions" without asking them | If it's a question, ASK the user |
| Using FR-1/AC-1.1 format instead of user stories | Use "As a [persona]..." with Gherkin criteria |
| Assuming scope instead of scoping with user | Every assumption is a question you skipped |
| Massive document from a one-line request | Interview to right-size. Small request may mean small scope. |