3 ms·

Reading this feels like fast-forwarding over someone's career as they mature in their understanding of problem-solving for others. Good intuition with rapid pr

Reading this feels like fast-forwarding over someone's career as they mature in their understanding of problem-solving for others. Good intuition with rapid prototyping, as it encompasses the necessary steps of understanding the problem, finding the appropriate solution and presenting it to the stakeholders, all in a relatively low-cost package.

phkahler 5y ago
>> problem-solving for others. This. I like to say that customers don't have requirements, they have problems they need solved (I hate the buzzword "solutions"). They're non-technical so they don't know what is possible or reasonable. It is up to the PM or lead to propose ways to solve those problems. Another issue is that (this appeared on HN recently) you can't tell people anything, so it's often necessary to show them something before they can really get on board with it. At that point things start to change and people will claim the requirements are changing, when in fact they are just starting to get fleshed-out. There is a second layer of requirements which are essentially a design. Not design by a designer but an internal software design. The customer doesn't care about this level of requirement but people tend to confuse the two. Some developers ask for too much detail and some customers try to micromanage. It's the PMs job to manage this boundary.