When product requirements are vague, ask questions instead of guessing. The speaker describes probing for the real problem, understanding the end-user, and involving designers and researchers to refine the vision together. This collaborative approach builds better products and stronger teams.
Chapters
I love this one. When the requirements are unclear, I ask about them. I ask what problem we're trying to solve. A lot of the times when I get requirements, I, I look at them as guidelines. I don't look at them as something I have to do because I might have questions that might change the requirements. Sometimes the requirements come from just somebody's idea that hasn't been fully thought through. So certain times I ask, what are we trying to do here? What are we doing? A lot of it comes through to some kind of discussion. Or I try to dive into what the mindset of the— like the purpose of this feature really is, what problem it's trying to solve by someone saying, "I had an idea to do this." So a lot of it comes from discussion. It comes from, you know, kind of critically thinking and trying to empathize with the user, how a user would interact with this proposed solution that that's unclear. And, um, to be honest, a lot of the time this builds team chemistry. Like, the discussion there when you're asking these questions and prying, and as long as you're trying to align on building a successful product, it builds team chemistry. It creates a better culture for working together in the future, and you start building the standards of what the definition should look like in the future. And Sometimes you don't, you don't, you know, it's, it's groomed as it goes. So the level of, uh, the level of fidelity of the, um, requirements changes because I might, you know, I've had one where we just came in, hey, here's the idea, here's the problem, and let's work from there. You're, as a designer, going to help create that solution. You're going to be part of the solution process. You're not necessarily just going to take the orders of what I'm telling you to build as a product manager, right? I actually like it that way personally, because I'm— I can— I have experiences too. I want to put— pull everybody's experiences, try to understand what the user is familiar with. I want research's input, you know. I want to know what, what we all think and are, you know, trying to, trying to get at the end of this. And I think a lot of that happens through discussion and collaboration compared to just requirements on what— how it's supposed to function.
