Requirements documents often aim for completeness. Delivery aims for reality. If those goals fight, teams waste weeks aligning on the wrong details - until the project finds out what's actually possible.

Create a constraint map

A constraint map isn't just 'things we can't do'. It's a categorized inventory: operational constraints, user constraints, technical dependencies, and rollout realities.

1. List the constraints stakeholders mention

   Capture the constraints in their words. Don't translate immediately - you need the original intent.

2. Categorize them by impact radius

   Local constraints affect a feature. System constraints affect architecture or adoption. This distinction changes how you plan.

3. Attach evidence to each constraint

   Examples: integration timelines, SLA assumptions, data availability, and operational lead time.

4. Turn constraints into scope choices

   Once you know what matters, pick the smallest scope that respects the constraint set and still produces learning.

Design the smallest workable scope

Teams often confuse 'small scope' with 'limited ambition'. We use small scope to mean 'high signal'. You're shipping the part of the product that proves the core assumptions.

• ✓ The release proves a core assumption (not a nice-to-have)
• ✓ We can observe outcomes quickly (metrics or operational signals)
• ✓ Rollout constraints are respected (timing, permissions, reversibility)

Reduce debate with evidence

When evidence is missing, teams argue about interpretations. When evidence exists, teams argue about decisions - and decisions are faster.

- Discovery facilitation note

assumptions:
  - id: 'data-availability'
    hypothesis: 'We can query the required dataset within SLA'
    evidenceRequired:
      - 'sample query under 200ms'
      - 'data completeness >= 99% for target cohorts'
    decision:
      ifEvidencePasses: 'ship MVP with monitoring'
      ifEvidenceFails: 'reduce scope to cached workflow'

• Translate stakeholder uncertainty into explicit assumptions.
• Attach evidence requirements to assumptions (so the team knows what 'good' looks like).
• Choose a scope that produces learning quickly, not just agreement.