This has been my experience, along with most great product leaders I’ve known have been “promoted” from developers/engineering as opposed to from the business end. Most devs/engineers I know also don’t want to take on this responsibility because they would rather be developing rather than overseeing product development.

I find that it is enough to have an engineering background.

Someone who grasps why simply adding a new button on the frontend might require a week of backend work because of prior decisions.

I would love this role and have had the chance to act in it. I'm quite adept at it but I do not want to be thrown into a business or domain that I don't know. It's like asking me to invest in a company or industry that I'm not an expert at. I need to be a a dev that just crushes stories for a while so that I can observe and learn about the business. I can sense the fear and imposter syndrome in people who have never been a dev and who don't really know the business. They are dead weight, and nobody wants to be dead weight.

Exactly, and in 3 decades of activity I didn't encounter a single counter-example.

> The problem is that it is hard to scale.

This is true for everything involving human beings.

Tons of human things have been scaled. Agriculture, retail, manufacturing, soildering, …

I'm not so sure that agriculture has successfully scaled across the human axis. We've successfully scaled agriculture only by removing much of the human element. Even very large farms, in terms of production, employ relatively few people. At that small scale of human involvement there still is often a lot of struggle with the people.

Those are effects of the Industrial Revolution, which led to the current climatic challenge. What a success!

He typed smugly on his smartphone before hitting Send with a flourish

As opposed to the humble hermits who reject modern technology and will still suffer from the climate change shitshow?

I don't pretend to be strong enough to live autonomously.

Climate change doesn't invalidate the progress made with the industrial revolution. This is not a productive message, just trying to stir the pot.

Thats irrelevant.

How, why?

The goal here is to scale things to what is needed and in a way that is feasible, 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'.

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.

> The goal here is to scale things to what is needed and in a way that is feasible

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.

Another problem is that once that leader and initial team leave for another job, they can be extremely hard to replace.

You may start with the first but the second seems kind of inevitable after some years.

> 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.

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.

> 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

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.

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.