Ask HN: How do I navigate horror of requirement gathering in product management?
5 comments
That is just how being a PM goes. You need to take all those inputs and synthesize a vision that meets as many needs as possible, without delegating control to the stakeholders.
The most important thing to learn is how to say "No", and that saying "No" should be the default answer.
You add features when multiple stakeholders agree they are needed, not when one new guy shows up in a meeting. You listen deeply to them all and understand why they are asking for things, and devise a solutions that solves their underlying problem - do not just take their requests at face value and implement them. Then you get to surprise them in UAT, when instead of them telling you that you failed to solve their problems, they tell you: "Wow, not what we asked for, but this is even better than what we had thought of."
It is your job to be the expert in what the customers and stakeholders need, so take all those pain points and embrace them as opportunities to learn more deeply what the correct product to build actually is.
It is also your job to set the priority, so there is no situation where everything is priority #1. People can tell you their own opinions on what is most important to them, but the actual priority is set by you.
The most important thing to learn is how to say "No", and that saying "No" should be the default answer.
You add features when multiple stakeholders agree they are needed, not when one new guy shows up in a meeting. You listen deeply to them all and understand why they are asking for things, and devise a solutions that solves their underlying problem - do not just take their requests at face value and implement them. Then you get to surprise them in UAT, when instead of them telling you that you failed to solve their problems, they tell you: "Wow, not what we asked for, but this is even better than what we had thought of."
It is your job to be the expert in what the customers and stakeholders need, so take all those pain points and embrace them as opportunities to learn more deeply what the correct product to build actually is.
It is also your job to set the priority, so there is no situation where everything is priority #1. People can tell you their own opinions on what is most important to them, but the actual priority is set by you.
You learn that this is life as a product manager. It's just the job description :(
The answer to everything is contracts. As far as requirements gathering:
1. Bill the clients for every requirements meeting. Time is money.
2. It’s up to the client to know what they want and up to you to build it. Time spent fantasizing out loud isn’t productive. Build a prototype, and bill them for the time. If it’s not what they want they can either build their own prototype or refine their guidance. Either way it’s time they are paying for just the same.
As for scope creep you can handle that one of two ways:
1. Add a change annex to the current contract. This means you will complete the PWS of the base contract first and then bolt the change on at the end as a refactor.
2. Amend the current contract to include additional features. Don’t do this.
In the end it’s all about the product work statement. You should think about goal completion only in terms: business objectives (data/money), visual/vanity, regulatory conformance, and extras.
1. Bill the clients for every requirements meeting. Time is money.
2. It’s up to the client to know what they want and up to you to build it. Time spent fantasizing out loud isn’t productive. Build a prototype, and bill them for the time. If it’s not what they want they can either build their own prototype or refine their guidance. Either way it’s time they are paying for just the same.
As for scope creep you can handle that one of two ways:
1. Add a change annex to the current contract. This means you will complete the PWS of the base contract first and then bolt the change on at the end as a refactor.
2. Amend the current contract to include additional features. Don’t do this.
In the end it’s all about the product work statement. You should think about goal completion only in terms: business objectives (data/money), visual/vanity, regulatory conformance, and extras.
“If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project.”—Karl Wiegers, Ten Cosmic Truths About Software Requirements
Every word Karl writes is gold. That man knows more about Requirements Engineering than anyone and has made a career of helping Requirements Engineers become better.
Every word Karl writes is gold. That man knows more about Requirements Engineering than anyone and has made a career of helping Requirements Engineers become better.
Our manager comes every 3-4 months, and assigns a ticket. Literally the only TEXT in the whole damn ticket was `Auto discovery in host and k8s`.
Auto discovery of fucking what?!!!
He writes in the message "IMP: we have a month so lets try to push to stage/BETA in 2-3 week and test it for a week and make it live before end of month."
Auto discovery of fucking what?!!!
He writes in the message "IMP: we have a month so lets try to push to stage/BETA in 2-3 week and test it for a week and make it live before end of month."
1. When everything becomes priority number 1 2. When the stakeholder goes back on the discussed requirements 3. Requirements change after every single meeting 4. During UAT a new stakeholder appears out of nowhere and says "This is not what we wanted" 5.You rely on SME for inputs who actually doesn't have a clue 6. Two clients from same team give you opposite requirements 7. Scope creep is the new fashion 8. THE BIGGEST OF ALL - The client doesn't know what they want
How do you navigate the horrors of the requirement gathering process to make yourself a better product manager?