1. Describe the current problem
Explain what happens today. For example, a team may copy orders between two tools and reconcile mistakes manually. Include the people involved, the frequency and the consequences. A description of the current workflow is more useful than a request for a dashboard.
2. Identify the first useful outcome
Define what should become possible in the first release. Separate essential tasks from improvements that can wait. For an order workflow, the first goal might be a validated import and a review screen rather than a replacement for every business system.
3. List users, data and access
Record user roles and the information each role can access. Identify source systems, API documentation, sample data that can be shared safely and any restrictions on external services. Unknown access requirements can change the estimate.
4. Set acceptance criteria
Write observable checks. Can a user complete the core task? What happens with a duplicate record or a failed connection? Who approves the release? Clear acceptance criteria help both sides distinguish a defect from a new requirement.
5. Explain constraints and tradeoffs
Share a budget range, target date and the reason for the deadline. Identify who supplies content and who can make decisions. If timing is fixed, a smaller initial scope may be more useful than an unsupported promise.
6. Ask for a handover plan
Clarify repository access, deployment documentation and responsibility for updates. Discuss support expectations and data export before signing. These questions make a proposal easier to compare and the software easier to operate.