Gathering and validating user needs before writing product requirements

How do you collect user requirements as a product manager? Walk through where requirements come from, the methods you use to gather them, and how you turn what you learn into requirements a team can build from. ```hint Separate the request from the need Requests usually arrive as ready-made solutions. Think about how you get from a request to the problem behind it, and what evidence besides conversations would confirm that the problem is real and widespread. ``` ### Clarifying Questions - Is this for a new product with no users yet, or an existing product with usage data, support tickets and a sales pipeline to draw on? - Who counts as the user: the end customer, the business that buys the product, or the developer who integrates it? For a business-facing payments product these are often different people. - Should the answer also cover how requirements are written down and validated, or only how they are gathered? ### What a Strong Answer Covers - A map of users and stakeholders and where their needs surface: research, product data, support, sales, partners and regulation - Methods matched to the question being asked, with safeguards against leading questions and unrepresentative samples - Turning raw requests into underlying problems and testable requirements with acceptance criteria - Validating and prioritizing before committing, and closing the loop with the people who gave input - A concrete example that shows the process in action ### Follow-up Questions - Your largest customer insists on a feature no other customer has asked for. How do you handle it? - What do you do when interviews and usage data point in opposite directions? - How does your approach change when a requirement comes from a regulator or a payment scheme rather than from users?