- Who owns outcome, budget, and scope decisions?
- Name the product owner, executive sponsor, operational owner, security or privacy reviewer, and acceptance authority. Record the review cadence and who can approve a trade-off or change request.
- Which user and task define the first release?
- Describe the user context, frequency, current alternative, critical completion event, staff dependency, and failure consequence. Keep future audiences and secondary journeys in a separate roadmap list.
- Which systems and interfaces are authoritative?
- Inventory identity, CRM, ERP, booking, payment, content, notifications, analytics, and reporting. Confirm supported APIs, sandbox access, rate limits, responsible vendors, data fields, and the safe unavailable state.
- What are the role, privacy, and security boundaries?
- Define user roles, minimum data, consent, retention, deletion, encryption expectations, audit needs, prohibited records, incident escalation, and test-data rules. Requirements that need formal assessment should be identified, not improvised in marketing copy.
- Who owns release identities and provider relationships?
- Confirm legal entity details, Apple and Google accounts, domains, cloud billing, payment merchant, messaging sender, analytics property, signing access, and the staff who can respond to provider questions.
- What counts as accepted and supportable?
- Write user-acceptance cases for the full journey, integration failure, duplicate action, permissions, accessibility, target devices, approved languages, recovery, staff receipt, and support handover. A successful build command is not business acceptance.