Write the brief your product team needs before it estimates

Describe the current event: who initiates it, which information is needed and where progress becomes difficult to see or complete.

Name the change the product must enable, such as a customer completing a request or a team acting from one current status.

Add why the commission matters now. A genuine deadline, service change or failing workaround affects priority and scope.

List customer, staff, partner and owner roles. Describe what each must see, decide or complete.

Write a normal scenario from trigger to confirmation, including handoffs and approvals.

Add a hard exception: missing information, changed details, duplicate requests, unavailable systems or escalation.

Name existing products and records, their owners and the authoritative source for important data. Include known API or export limits.

Record constraints covering permissions, privacy, retention, language, accessibility, devices, hosting, procurement, deadlines and support.

Label facts, assumptions and open questions separately. This gives discovery a finite investigation list.

Choose one audience and one end-to-end job. State what the release deliberately excludes.

Write acceptance as observable behavior: a task completes with the correct role, a record reaches its source, or an exception reaches its owner.

Define what you will examine after release—completion, correction effort, support cases, failure categories or feedback—to decide what follows.

• One complete and valuable job
• Usable exceptions and failure states
• Explicit exclusions and dependencies
• Evidence for the next investment decision

Combine the outcome, scenarios, systems, constraints, first-release boundary, stakeholders and genuine date in one concise document.

Attach explained examples, not context-free screenshots. Ask bidders to identify assumptions, risks and alternatives.

A strong response clarifies what will be designed, built and tested first. It may recommend configuration or integration instead.