Product Analyst agent
The Product Analyst agent turns a goal into requirements with clear acceptance criteria and scope limits. It runs in Feature SDLC and Discovery & Spec.
The Product Analyst agent works out what should be built before anyone decides how. It converts the goal you describe into requirements, each with clear acceptance criteria, and draws the scope boundary: what is in and what is out.
Where it runs
| Workflow | Step |
|---|---|
| Feature SDLC | Requirements |
| Discovery & Spec | Requirements |
In Feature SDLC it is the first of eight steps, so everything after it, from the Project Planner to the Technical Writer, works from its requirements. In Discovery & Spec it runs after the Researcher has surveyed prior art, and before the Project Planner.
Inputs
- The session task, usually a goal in plain words such as "let customers export their data".
- A read-only snapshot of relevant files from the project's repository, so requirements fit what exists.
- In Discovery & Spec, the Researcher's survey.
Outputs
A written set of requirements with acceptance criteria and scope boundaries.
In Discovery & Spec, its requirements are the decision the workflow exists to produce, so the platform saves them to the workspace's ADR log as a proposed record, linked to the session. A person accepts or rejects it. In Feature SDLC its output steers the rest of the session.
On the Auto tier its step goes to the Premium tier first, because everything after it depends on it.
Example run
Illustrative example, not a recorded session. Matt runs Discovery & Spec with "let customers export their data". The Researcher finds an existing CSV export for invoices and a background job runner. The Product Analyst writes four requirements: an owner can request an export of all workspace data; the export is built in the background and emailed as a link; the link expires after a set time; and only owners can request it. Each has acceptance criteria, such as "a member who is not an owner sees no export button". Out of scope: scheduled exports and per-project exports. The requirements are saved as a proposed ADR.
Limits
- It does not talk to your users. Requirements come from your task, the code and the model's general knowledge.
- Ambiguous goals produce assumptions. Read the scope section and correct it before building.
- It does not track requirements over time. Use the plan board and change records for that; see projects.
Frequently asked questions
Are the requirements saved anywhere?
In Discovery & Spec, yes. Its requirements are saved to the workspace's ADR log as a proposed decision. In Feature SDLC they are passed to the later steps of the session.
Can I edit what the Product Analyst produced?
The proposed ADR can be reviewed, accepted or rejected in the console. To change the requirements themselves, start a follow-up session with your corrections in the task.