How to Gather Product Requirements
A cheatsheet of principles for engineers
Software engineers make things for other people to solve some kind of problem. At some point, you’ll likely be asked to go hear your users or customers yourself.
This list is for that occasion: listening to your users and getting their requirements.
1. Prepare
There are certain things you’ll likely be able to discover ahead of time. The names of the people in the room, what their roles are, and who they are responsible to. Knowing these easy to gather facts before you sit down will improve your credibility.
2. Ask Questions
Assume the posture of a curious child asking “why?” Feel free to not know where the questions will take you. As much as you can, write out a series of questions you intend to ask ahead of time. Don’t limit yourself to those questions, but also don’t leave too many of them unanswered as they likely are the bulk of what you want to learn.
3. Be Brief
Be brief, short and succinct. You are not here to talk; you are here to discover. Longer questions tend to become statements. You are needing to gain information and guide the conversation, not make judgements or unfounded opinions. Don’t let you be the person causing the conversation to run offtrack into unprofitable territory.
4. Use Plain Words
You are not here to impress with your breadth of language or knowledge of technical jargon. You are here to understand the needs of another person. You can’t understand them unless you make yourself understood.
5. Listen
Listen to the answer. For some, talking to someone important enough to give you requirements causes stage fright. Confusion and panic sets in. Instead of actually listening, you have a hard time just getting the first question out, and you’re generally thinking about the next question and not listening to the answer.
6. Do Not Quarrel
Do not quarrel with the person you’re interviewing. When the answer to your question is absurd, false, irrational contradictory or the like. Stop; sit down; hear more.
7. Be Repetitive
Unlike normal situations, asking the same question multiple times often results in different answers. Sometimes this is because people didn’t understand the question the first time, and other times it’s because people feel uncomfortable giving the same response to multiple questions. In either case, you will likely get more information if you simply reword your question.
8. Avoid Solutions
As much as you can, hold off getting to a solution. You’ll likely be prompted by the people interviewing you to come up with one. In fact, they may have brought a solution with them.
As an engineer, you’ll be be tempted to jump to solving the problem. During this time of meeting, this impulse is a bad one.
You’ll think you’ve understood, and instead of continuing to hear, you’ll start talking more and begin to direct your questions down a particular path instead of hearing the people in front of you all the way out. Hear out the needs of the people you’re listening to.
9. Look for the Pain
If you’re gathering requirements for something, likely it means that some people involved have some need they’re looking for, some kind of pain. As you ask multiple questions, look for the thing that elicit strong negative emotional reactions. There is likely something valuable in the pain.
10. Record everything
If you can, record the meeting. If you can’t, take copious notes. In either case, ensure you reserve time immediately after the meeting to summarize what you learned while it’s still fresh.
Addendum
This article is greatly influenced by Irving Younger’s 10 Commandments of Cross Examination.