Requirements Start With You, Not the User
“How can I write requirements without a gathering session with the users?”
🔹By studying.
🔹By researching.
🔹By understanding your domain.
🔹By making educated assumptions.
🔹By putting yourself in the shoes of the end user. 👣
➤ Your job is not to get the requirements from a user. Your job is to validate them. If the user knew exactly what they wanted, why would they need you?
➤ They need you because they don’t know what’s needed in full. They have a problem. You need to come up with a solution. 🧩
➤ They just know their own narrow problem. Your job is to build for the industry. This is where you become more than a documenter.
💡 This is the lonely individual grind work that sets your role apart. 💻☕️
“But as per requirement lifecycle management guides, gathering is an essential step before documenting.”
💡 Guides are supposed to be taken as references, not rule books. Who said you can’t skip or flip a few steps? Do what’s applicable in your situation. Devise your own guidebook. 📚
“What if the requirements I wrote don’t align with the user?”
That’s where planning and negotiation come into the picture.
🔹 If they’re asking for something valid that you didn’t include—why not add it?
🔹 If they want something that doesn’t align with your roadmap—why not tell them?
These are the conversations and decisions you need to drive. 🎯
➤ Your job is to come up with requirements based on your research and conversations with users, and build a rinse-and-repeat product for the market. That’s your edge. That’s your responsibility.
💡 Bringing alignment is exactly your job.
“Okay, but shouldn’t an ideal requirement gathering start with interviewing the user?”
🔹 If that means having a conversation to understand high-level pain points—sure, to some extent.
🔹 If that means waiting for them to lay down all the information, reasoning, and possible solutions—NO. 🚫
💡 The ideal practice starts with preparation.
🔹 By being a step ahead.
🔹 By using what’s known to extrapolate and discover what can be done.
“Ohh, I always felt underconfident about my analysis and requirements since I hadn’t heard them from the user.”
🔹If you’ve done your side of the work, replace that fear with curiosity.
🔹You’ve done your bit—now it’s time to listen.
🔹Now is the time for the real user to validate whether we’re with them or not! 🧠👂
💡 In the end, the user does dictate. But helping them reach there—quickly and systematically—is what makes PM jobs awesome. 🚀
“This is great! Thank you.” 😄