5 ms·

> A team with a strong product leader I think the problem begins before the 'leader.' The product itself dictates all the downstream consequences, including w

> A team with a strong product leader I think the problem begins before the 'leader.' The product itself dictates all the downstream consequences, including whether 'requirements' are a problem. Assuming no fatal management dysfunction, when you're working on a product that has substantial value, enough that the customer is eager to pay for what you're capable of delivering, requirements are straightforward. When you're working on things of low value and the customer won't pay unless they get an ever more improbable gymnastics routine and every tier of stake holder is lying to the other then you starting hearing about 'requirements' problems. The 'requirements' problem severity is a function of where you are on on the continuum between these two products.

mason55 5y ago
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 building a real product there’s frequently not even an existing customer and certainly none to “give you requirements”. You need to understand problems to solve and turn those into requirements for a product and if you can do that then you’re not working at a customer giving requirements to a vendor.
- 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
deleted 5y ago
[deleted]
bcrosby95 5y ago
Just because someone can pay for a requirement doesn't mean that requirement adds value to a product. If I think the cost for a requirement is higher than its value - which may potentially even be negative - I'm going to present my case for stripping it out.

mason55 5y ago

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 building a real product there’s frequently not even an existing customer and certainly none to “give you requirements”. You need to understand problems to solve and turn those into requirements for a product and if you can do that then you’re not working at a customer giving requirements to a vendor.

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

deleted 5y ago

[deleted]

bcrosby95 5y ago

Just because someone can pay for a requirement doesn't mean that requirement adds value to a product. If I think the cost for a requirement is higher than its value - which may potentially even be negative - I'm going to present my case for stripping it out.