Describe the work before the feature list
Explain what happens today and where it is difficult. Name the people involved, the tools they use and the result they need. ‘Our team copies requests into two systems and loses the approval status’ is a useful starting point because a delivery team can investigate it.
Include evidence you actually have, such as repeated steps or a sample request. If you do not know the volume or time spent, label it as an open question. Name the person who understands the process and can make decisions during the project.
Choose a first release and its boundaries
List the tasks users must complete in the first release. Identify who can view, create, change or approve information. Separate essential tasks from later ideas and write down what is outside scope.
For an illustrative request portal, the first release might let a customer submit a request and see its status, while staff review and update it. Payments, a native app and automated approval may wait. This is a scoping example, not a feature list every business should buy.
Explain data, connections and completion checks
Name the existing systems and the records they own. Describe which information must move, who approves access and what should happen when a connection fails. A short phrase such as ‘integrate the CRM’ leaves too many assumptions for a reliable estimate.
Turn success into a checkable statement. For example: an authorised staff member can update a request, the customer sees the agreed status and a user without access cannot view it. Include missing information, unavailable services and useful error messages in the review, not only the normal route.
Agree the practical details and handover
Share the budget range, timing and reason for any deadline. Ask whether the proposal includes design, development, migration, tools, hosting and support. Make assumptions and exclusions visible, and agree how changes affect effort and timing.
Confirm source-code access, ownership terms, accounts, documentation and training before the build begins. Decide who looks after the release and what further work costs. A rough brief is enough to begin a conversation; it becomes useful when both sides can see the remaining decisions.