I am an engineer by trade, but I would argue product is more important than engineering. WHAT you work on is ultimately more important than HOW it is achieved from my experience. Yes, bad engineering will ruin a product, but it is all moot if you are not working on the right thing. So many companies I have worked with are working on the wrong thing. Another way to put it is, a company with a great product that has bad engineering will outperform a company that has great engineering but a bad product. Product/market fit rules all. Once I understood this I was able to work with the product team better.
Yeah I mean I work at a place that thankfully has no "product" team. That was a valuable thing at a certain place but it's been replicated needlessly and most product managers are glorified project managers with no power or responsibility.
^ and this attitude is _exactly_ why so many companies can't get anything done and why I explicitly pointed out that software developers tend to be smarter than your product people.
So lets be very clear on what I was saying.
software developers can do the job of product, product cannot do the job of software developers
It kills me how many people seem to think the doers are the least important part of it. Gamedev gets this right with the insistence that the idea guy is worthless.
I work as a software architect and I see this all the time.
It's not a job, it's a role, one that senior developers take on all the time.
It gets turned into a job and the result is business people constantly bitching about why everything is slow and what DOES get done is never what they wanted.
The reason you found it so hard is because you weren't doing the implementation, which is why software developers should be taking on that role.
At that point you're a glorified translator hoping that both sides are understanding each other perfectly. And what's worse is they both speak English!
Translating between who? I don't think we share the same experiences with companies, roles etc, so we might be talking past each other. Product is a pretty ill-defined role.
between business needs and how it gets implemented.
Companies that do this took 3 roles and smashed them into 1.
- marketing fit
- business analyst (aka domain experts)
- technical implementation
The reason you see people talking about how hard it is for product is because product gets to interface with the business and has an understanding of the problems and the proposed solutions. They try to tell technical to implement with no real understanding of both, due the reality of the phone game it's never implemented as they want, and they get frustrated.
The solution is to stop trying to make technical the tech equivalent of ditch diggers.
Yes, if you want a ditch dug it's relatively easy to communicate that to someone. Software aint ditches.
So while product couldn't begin to start implementing themselves, technical can absolutely be having those conversations with business.
I can see what you are saying if one is the environment you describe.
I've never worked somewhere where eng was treated like ditch diggers. But I've also never worked anywhere where this "business analyst" actually existed. If you build products for many customers there is no such person, because different customers need slightly different things and you have to pick a position v competitors.
Maybe try changing environments? Not everywhere works as you describe.
Most people who have done real engineering and real product jobs will tell you PM is a harder job to do well.
There is more pressure, less control, more uncertainty, more people to keep happy, more ambiguity. And the number of context switches is high. One has to be highly organized too. Crazy difficult to do well. Very easy to do poorly.
It is a lot easier to be a bad PM than an engineer, I'll grant you that. And most PMs aren't great.
What you mean is it's extremely difficult not to produce shit software with a setup like this, even though paradoxically the theory is that this should produce higher quality software.
The reason for this is something called tacit knowledge. The only way for a developer to be successful is if they have the same level of understanding that product does. Since they don't, product needs to be the one implementing. Since neither happens, you get shit software.
The solution is either product starts implementing or software developers stop being treated as line workers.
product used to be three roles that worked together. software dev, business analyst, and marketing. And depending on the size of the company, business analyst and marketing often means working directly with business because that's who collaborates between those two.
There is no value-add in product, the theory has proven out to be untrue.
Give it another 10-20 years and we'll be reading articles about how the "smart" companies are doing away with product and giving it back to the other roles and asking them to do something crazy like talk to each other.
"working with business" suggests we must be talking about different situations.
I'm talking about a company building software products they sell, eg an enterprise software product like salesforce, google cloud, aws, splunk etc. Not internal software or software built for a specific client.
It's all the same, someone has a need and you give them a solution.
That need is either driven by business wanting to improve the software or by technical wanting to improve the software. product doesn't belong in there.
product will never identify that a technical change will enable new things, for example. The ones who can do that aren't allowed in the conversation.
We are talking about quite different environments.
Trying to simultaneously satisfy many customers in a market where there are multiple options, different ways to slice and dice the customer segments, different dimensions on which to optimize a product, different ways to reach customers, different systems to integrate with, it's just a whole different ballgame to building a specific solution for a specific customer.
And at somewhere like google for example, most of the PMs are former engineers and can see technical changes enabling new things. On top of that, at somewhere like Google engineers do meet with customers, frequently. There isn't some dividing line like you describe because all the business units are run by PMs or engineers. They are "business" in your terms.
It is what it is. Your observations and suggestions may well be true and sensible in the environment you are operating in.
Yep, you can structure the roles however you like. I'd guess every plausible combination has been tried.
In my world engineers are first class citizens who have real input to the product decisions and meet customers, the PMs are usually technically capable, the PM job is too big to be done part time and hence isn't. It is what it is, and doesn't seem to be close to how things work in your world. But in my world, the product job is more complex than "someone has a need and you give them a solution". For internal development or consulting, that's probably right.
Regardless, the job is still extremely difficult to do well. Anyone who tells you otherwise hasn't really done the job, at least not outside of the simpler world of consulting/internal software where it's best described as "requirements engineering".
