A team with a strong product leader who is visionary and empathizes with users will run circles around a loosely organized group of stakeholders/engineers duct taped together by process. The problem is that it is hard to scale.
Someone who grasps why simply adding a new button on the frontend might require a week of backend work because of prior decisions.
> The problem is that it is hard to scale.
This is true for everything involving human beings.
not only that but the destructive nature of it was also wonderful to society overall, our living standards skyrocketed to an unfathomable degree during said revolution.
talking about the ecological destruction -while an important aspect- is irrelevant to the argument of scale to meet people wants and needs.
Think about it this way, would you be talking about the ecological destruction in an 1800s meeting to scale up farming and husbandry efforts to meet the demands of that time?
If the answer is yes, then would you be willing to delay/postpone the efforts until there are better technologies that are more ecologically friendly to exist and then accept/allow these efforts?
If the answer is no, then it is , like i said, irrelevant.
I beg to differ. As far as I know we scale up things in order to benefit from economies of scale. And we do so because the 'technical system' underlying our civilization leads us to always want 'more'. J. Ellul, among others, wrote about this.
> i doubt solar panels would've been feasible as a scaling method for energy during that time, much less electric cars, or even less likely, farming strategies and equipment that are ecologically less 'problematic'.
Indeed.
Note: some of those ways (solar panel/electric cars/farming strategies/...) have flaws (bad side-effects), some of them catastrophic, we aren't aware of, but will discover (just as all fossil fuels, which enabled the Industrial Revolution, do have catastrophic side-effects.
> not only that but the destructive nature of it was also wonderful to society overall, our living standards skyrocketed to an unfathomable degree during said revolution.
Claiming that those effects were beneficial is acceptable. However it IMHO doesn't balance the bad side-effects (current climatic challenge). Saving (or enhancing the life) of some doesn't justify creating a major risk for others (later).
> talking about the ecological destruction -while an important aspect- is irrelevant to the argument of scale to meet people wants and needs.
The case may be about obtaining anything (even a population) 'big' without economies of scale (or, to put it bluntly, without a technical system), I doubt so, and our ability when it comes to detect bad future side-effects of selected solutions (IMHO this ability is near zero). That's the reason why I think that what works for humans (and maybe for each and every complex life form) is a society built upon small groups, and more generically that everything that (in our society) works for long and without any major blunder is done by and for such groups. In more than a way L. Kohr showed it.
> Think about it this way, would you be talking about the ecological destruction in an 1800s meeting to scale up farming and husbandry efforts to meet the demands of that time?
I would, indeed.
> If the answer is yes, then would you be willing to delay/postpone the efforts until there are better technologies that are more ecologically friendly to exist and then accept/allow these efforts?
At the time: no, however knowing what I know now I would plead for a very (VERY!) progressive (time and space) implementation (precautionary approach).
> If the answer is no, then it is , like i said, irrelevant.
I understand your point, mine sits on the "let's avoid committing the same error twice" principle.
You may start with the first but the second seems kind of inevitable after some years.
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.
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.
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