To build a successful product, you need a toolkit of different techniques to "dig out" requirements. Depending on the project size and the type of stakeholder, you might use one or a combination of these.
🎤 Interviews
The most common technique. You sit down with stakeholders and ask them about their needs.
Structured: You have a fixed list of questions. Great for getting specific data.
Unstructured: A free-flowing conversation. Great for discovering "hidden" needs you didn't think to ask about.
Best for: Getting a deep understanding of a specific user’s role.
📝 Surveys and Questionnaires
When you have hundreds or thousands of users (e.g., building a new feature for Instagram), you can't interview everyone.
Pros: Fast and provides statistical data.
Cons: People often skip them or give low-quality "multiple choice" answers.
Best for: Quantifying requirements (e.g., "70% of users prefer Dark Mode").
🧠 Brainstorming & Joint Application Development (JAD)
This involves bringing all stakeholders (users, managers, developers) into one room for an intensive session.
JAD: A highly structured workshop where everyone agrees on requirements in real-time to avoid long email chains later.
Best for: Resolving conflicts between different departments quickly.
🧐 Observation (Ethnography)
Sometimes users do things differently than how they say they do them. By watching a user do their job in their actual environment, you can spot "pain points" they forgot to mention.
Passive: You just watch and take notes.
Active: You ask questions while they work.
Best for: Understanding complex manual workflows that need to be automated.
🖼️ Prototyping
Instead of talking about a feature, you build a "dummy" version of it (a wireframe or mockup).
When a user sees a visual, they often say, "Oh, now that I see it, I actually need this button to do X instead of Y."
Best for: Refining the User Interface (UI) and User Experience (UX).
📑 Document Analysis
This involves reviewing existing business documents, manuals, or the "Help" tickets of the current system.
Goal: To understand the existing business logic and "rules" that the new software must follow.
📊 Choosing the Right Technique
Scenario | Best Technique |
|---|---|
Brand new, innovative product | Prototyping & Brainstorming |
Replacing an old manual system | Observation & Document Analysis |
Adding a feature for millions of users | Surveys & Questionnaires |
Building a niche tool for 5 experts | Deep Structured Interviews |
⚠️ The "Golden Rules" of Gathering
Listen more, talk less: You are there to learn their problems, not sell your solutions.
Avoid Jargon: Don't ask about "SQL databases"; ask about "how you want to store your client's phone numbers."
Confirm Everything: Always send a follow-up email: "Just to confirm, you said you needed X, correct?"