What is Requirements Gathering?
Requirements gathering is the process of identifying what a product or feature needs to do, for whom, and under what constraints. It involves conversations with users (what do they need?), stakeholders (what does the business need?), and engineers (what is feasible?).
Modern requirements gathering is iterative, not waterfall. Instead of spending months documenting every requirement upfront, agile teams gather requirements continuously, refining them as they learn more through product discovery.
Why Requirements Gathering Matters
Vague requirements cause rework. When the PM says "build a notification system" without specifying channels, frequency, user preferences, or edge cases, engineering makes assumptions. Those assumptions are often wrong, and the resulting rework wastes sprints.
Good requirements also prevent scope creep. When requirements are explicit and agreed upon, it is easier to push back on additions: "That was not in the requirements we agreed to. Let's evaluate it for the next iteration."
How to Gather Requirements
Start with user research. Observe users performing the task your feature will support. What are they doing? What is frustrating? What is missing? Requirements derived from observation are more reliable than requirements derived from asking "what do you want?"
Interview stakeholders. Understand business goals, compliance requirements, technical constraints, and timeline expectations. Different stakeholders have different needs. Document all of them, then prioritize.
Write requirements as user stories when possible. "As a [role], I want to [action] so that [benefit]." This format keeps requirements user-centric and outcome-focused.
Validate requirements with engineering. Before finalizing, review requirements with the technical team. They will identify feasibility issues, suggest alternatives, and estimate effort. This prevents writing requirements for things that are technically impractical.
Requirements Gathering in Practice
Amazon uses a "Working Backwards" process where the PM writes a press release and FAQ before gathering detailed requirements. This ensures requirements serve a clear customer outcome rather than becoming a wish list of features.
At ThoughtWorks, requirements are gathered through "story mapping" workshops where cross-functional teams map the user journey and identify requirements at each step. This produces requirements that are naturally organized by user flow rather than by technical component.
Common Pitfalls
- Requirements from one source. Gathering requirements only from the VP or only from users produces a biased picture. Triangulate across multiple sources.
- Specifying solutions, not needs. "Build a dropdown menu" is a solution. "Users need to select from a list of options" is a requirement that allows design freedom.
- Over-specifying. Exhaustive requirements documents become outdated quickly. Capture the essential needs and constraints, not every detail.
- No validation. Requirements should be validated with users before engineering begins. Show prototypes, walk through flows, and confirm that the requirements match real needs.
Related Concepts
Requirements gathering produces PRDs and user stories. It is a component of product discovery and relies on user research and stakeholder management. For structuring requirements conversations, see JTBD.