Requirements Gathering & Discovery
The stage every failed project skipped, and every successful one spent real time on.
8.1.1Definition
Requirements gathering is the process of determining what a product actually needs to do — for its users, its business, and its constraints — before significant design or engineering work begins. Discovery is the broader research activity underlying it: talking to users, studying the problem space, and validating that the intended solution actually addresses a real need.
8.1.2Why It Exists
Building the wrong thing efficiently is still building the wrong thing — and the cost of discovering a misunderstood requirement grows sharply the later it's found, from a conversation early on to a full rebuild after launch. This stage exists to front-load that discovery, when a wrong assumption costs a conversation to correct rather than months of engineering work to undo.
8.1.3Core Discovery Activities
- Stakeholder interviews — understanding what the people commissioning or funding the work actually need, which is not always what they initially say they want.
- User research — understanding the people who will actually use the product, their existing workarounds, and their real pain points.
- Constraint mapping — technical, budget, timeline, and regulatory constraints that will shape what's actually feasible.
- Documented requirements — the findings captured in a form (a brief, a spec) that can be referenced and validated against later, rather than left as tribal knowledge.
8.1.4Common Mistakes
- Treating the first stated request as the actual requirement, without probing the underlying problem it's meant to solve — often leading to a technically correct solution to the wrong problem.
- Skipping discovery under time pressure, only to discover a fundamental misunderstanding weeks into engineering work, at far higher cost to correct.
- No documented requirements at all, relying on verbal understanding that different stakeholders remember differently later.
8.1.5Best Practices
- Ask "why" behind a stated request at least once before treating it as the actual requirement.
- Document requirements in a form stakeholders can review and confirm, closing the loop before work begins.
- Timebox discovery deliberately — thorough enough to catch major misunderstandings, not so long it becomes its own form of delay.