> because C level was requesting "X feature". But when you sit down down with C level, and understand what they want to achieve with X feature, many times it is possible to sit down with tech and figure a way to get what was wanted without the feature, generally by adapting some other request or feature.

In the best functioning development organizations I have experienced or seen, nobody should be asking for "X feature", they should be explaining what their actual needs are, what they need to get out of the software and why. And how important it is to them, or even what their "budget" for it is.

And a technical designer (who could be a developer who has some design skills perhaps by experience, or a designer who understands the tech) _designs a solution_.

This requires someone(s) on the "development" side who can do needs/requirements analysis leading design (ie, "UX"). And it requires the stakeholders to trust that the capacity is there, and that it will turn all right if they don't try to micromanage the feature -- not just "all right", it'll be SO MUCH BETTER.

This works so well when the organization staffs itself to make it possible and the people in charge allow it to happen, that it seems kind of insane that so few organizations do so.

You just described product managers.

They solicit needs from customers, support conversations, etc. and translate those into future development. They combine those needs into major product directions and balance them with an internal compass for where the companyw wants the product to be (i.e., what jobs they want to solve for which users.)

They are technical people with an eye for how something should be built, working closely with designers (visual, UX, etc.)

Excellent companies figure out how to deploy these types of thinkers -- with appropriate mandate -- throughout the organization.

Though you know, sometimes organizations fall into this issue in other areas.

I once worked with a company that had that attitude toward accounting/compliance - so much more work and all because the primary holders were not in agreement, so they kicked the corporate structure can down the road.

Same goes for CS, etc.

I guess the only solution is a holistic approach, but even then sometimes someone will have to bear the brunt of being the area where people will 'will handle it', at some point a CEO will decide that is what is needed and it will be needed, even in a perfect organization.

I am pretty sure that my Product Manager has no technical experience at all. And I assume that it's not mandatory for them.

If they are supposed to be technical, then we hired wrongly.

Technical enough to understand, but probably not technical enough to build (but maybe was at some point). That's where they need to live. Their job is to align the devs and the roadmap with the business needs, prioritize what bugs to fix, and decide which enhancements are worthwhile. They also need to know when the team is bullshitting them and when a tech design is too complex or simple.

I can imagine a non-technical person could end up in this role and succeed, but someone with a technical background and some business acumen will have a much higher probability of success.

Well, because stating needs and not implementations disempowers managers and means they're left with no feeling of grip. It makes it hard to imagine what you'll actually get and whether it'll be useful, which is scary. Plus, what people need is often so vague that literally anyone could have come up with it and it's embarrassingly obvious. If a manager goes to his tech team and says, "I need to make our business more efficient. Think of something!" then this may be the best way to get results because often the programmers understand the business as well as or better than the managers and they understand the codebase, but who would respect a manager who said that? It'd be Dilbert cartoons all over.

This is one reason why tech firms win. Their senior management are made of [former] engineers who are much more aligned with the workers around what implementations make sense.

That's why it's an actual skill to translate needs to implementation. It's not one most managers have either, is why when the managers just give you implementation it does not work.

The skill includes working with the stakeholders to develop actionable needs (not just "make our business more efficient"; the obvious place to go from there is, okay, what do we know about where the greatest bottlenecks/inefficiencies are now, if we don't know enough what can we do to learn?).

Also you don't just take needs and come back with a finished feature, you iterate with feedback from the stakeholders. The first iteration might just be a textual description of the feature, to make sure it makes sense to the manager/stakeholder.

It's a skill, and it involves building trust.

But translating needs to features that will succesfully meet those needs is not a skill most managers/stakeholders have either, is exactly why it doesn't work to just get detailed micro-managed implementation directions from managers/stakeholders. (Or customers!).