The Requirements Problem
How to gather requirements for AI projects when nobody knows what's possible.
The Paradox
Traditional requirements gathering assumes stakeholders know what they want. But with AI projects, they often don't—because they don't know what's possible.
This creates a paradox: you need requirements to build the solution, but you need to show the solution before people can articulate requirements.
Why Traditional Approaches Fail
"What do you need?"
This question assumes the person knows:
- What problems AI can solve
- What data is available and usable
- What "good enough" looks like
- What trade-offs are acceptable
Most stakeholders can't answer these questions accurately before seeing options.
Waterfall Documentation
Comprehensive requirements documents assume:
- Requirements won't change once discovered
- Edge cases can be anticipated upfront
- Integration complexity is predictable
With AI systems, none of these assumptions hold.
A Different Approach
Show, Don't Tell
Instead of asking "what do you need?", build rough prototypes and ask "would this help?"
This approach:
- Makes abstract concepts concrete
- Reveals hidden assumptions
- Surfaces real constraints early
- Builds stakeholder confidence
Discover Through Doing
Use a structured discovery process:
- Observe current work - Watch people do the task today
- Identify pain points - Where do they struggle, wait, or work around systems?
- Prototype quickly - Build something in days, not weeks
- Test with real data - Use actual (or realistic) data immediately
- Iterate based on feedback - Short cycles, frequent adjustments
Focus on Outcomes, Not Features
Instead of "the system should automatically classify documents," ask:
- What decisions depend on document classification?
- What happens when classification is wrong?
- How fast does classification need to happen?
- Who needs visibility into the classification process?
Embrace Uncertainty
Accept that you'll learn as you build. Plan for:
- Changing requirements (build modular systems)
- Unknown edge cases (build monitoring and escalation paths)
- Evolving AI capabilities (avoid over-optimization)
The Three Questions
When gathering requirements for AI projects, focus on three questions:
- What would success look like? (Not features—outcomes)
- What would failure look like? (Risk tolerance and constraints)
- How would we know? (Measurement and feedback mechanisms)
Practical Techniques
Process Mining
Use existing system logs to understand actual behavior, not documented procedures.
Day-in-the-Life Observation
Shadow users doing real work. Note what they actually do, not what they say they do.
Exception Analysis
Study the edge cases and exceptions. These often reveal the most important requirements.
Rapid Prototyping
Build throwaway prototypes to test assumptions. Expect to rebuild.
Need help understanding what's possible for your processes? Schedule a discovery session with our team.