Describe a completed job
“Build a CRM” describes a category, not a result. Start with one person and one job: a coordinator receives a service request, assigns it to a technician and sees whether the customer has been contacted. Name the first user, the source of the information and the decision the system helps them make. This gives the Architect something concrete to structure before screen names and frameworks enter the conversation.
Separate rules from preferences
A rule might say that a technician cannot see another team’s requests. A preference might say that status labels should be compact. Both matter, but a permission failure and a visual preference need different acceptance checks. Add one positive example and one forbidden example for critical rules. Explain where the rule came from: an owner decision, an existing procedure or observed legacy behavior that still needs confirmation.
State what the first release excludes
Exclusions protect the first useful journey. For the request coordinator, scheduling may be necessary while automatic invoicing is not. Write exclusions next to scope, not in a forgotten message. A later idea can become a separate Project rather than silently expanding the running task. Also distinguish unknown decisions from exclusions: not yet knowing the invoice process is different from deliberately choosing not to build it.
End with a demonstration you can inspect
Specify a small set of representative records and the actions that should succeed or fail. Ask to see the actual request created, its assignee and the access boundary. A screenshot of a dashboard is insufficient if the saved record is wrong. In Forge, the brief becomes versioned Product knowledge and an initiative-specific Project scope, with evidence linked to the agreed acceptance criteria.
A worked brief: service requests
Imagine a company coordinating repairs for several customers. Its first useful release is not “a dashboard with AI”. It lets a customer submit a request, a coordinator assign it and a technician report a result. Start the brief with that sequence. Specify the minimum fields: customer, description, priority, assignee and status. Describe who may see an attachment and whether reopening a completed request is allowed.
Then separate an operational goal from a feature idea. “Stop requests becoming ownerless” is the goal; a queue, an assignment action and an overdue indicator are possible mechanisms. Ask the Architect to preserve the goal even if a simpler interface achieves it. A useful brief gives room for technical design while keeping the business obligation precise.
| Decision | Useful requirement | Evidence |
|---|---|---|
| Ownership | Every open request has a responsible team. | Create, assign and reload a request. |
| Privacy | Customer A cannot access B’s attachments. | A denied request with a different customer session. |
| Scope | No invoicing in the first release. | An explicit exclusion in the accepted specification. |
Where this goes wrong
A vague approval such as “looks good” cannot resolve an undocumented access rule. Before development, choose the owner of each unanswered question. Do not let the agent silently turn an assumption into a requirement. Keep a short decision log with the answer, reason and scope; later changes can then be reviewed as deliberate product decisions rather than accidental regressions.
A useful brief reduces ambiguity; it does not remove the owner’s decisions.
Turn it into a working checklist
- Name one user and one completed job.
- Give a positive and forbidden example.
- Write explicit exclusions and open questions.
- Define what evidence you will inspect.
A concrete next step
Finish with a one-page brief, a small role matrix, five example records and the first acceptance journey. Add unresolved decisions and a named decision-maker. This is enough to begin a bounded planning conversation; it is not a reason to write a hundred-page specification before testing a simple product idea.
Watch a related case
The video could not be loaded. Try again later.