4 ms·

Depends what you’re trying to build. Sure, if you’re just doing consulting work then go get requirements from a customer and deliver on them. If you’re buildi

• bluGill 5y ago
  Even when you get requirements beware that the customer doesn't know what they want. So you get asked to make a faster horse instead of invent the car.
• mdaniel 5y ago
  > You need to understand problems to solve and turn those into requirements for a product One subtly for me is that what you said is 100% true of the parts of the organization which interact with customers, or even design partners who want to become customers. But since not every member of engineering is in that role, the requirements which come back from those meetings still need to be "MVP accurate" and (IMHO) need to specify just as much what it *won't* do as what it needs to do For example, "customer wants to query for names" is a shitty requirement. Of course they do, we all want search engines for everything, but that's not how software works. Do they want it case sensitive, case insensitive, the ability to indicate by using special search syntax (like "quoted"), do they want "starts with" or "contains" searches, wildcard characters? Getting to MVP means not building the wrong or extraneous things just as much as building the right things, and only a handful of people bear responsibility for distinguishing between those sets