Product shouldn’t be left to product managers

Our solution is to trust the experts, but certainly there must be something better than "whatever the current engineer thinks."

You argue that there's not enough room in a person's brain for Software Engineering and Product Management, but "Product Management" often includes planning, strategy, coordination, vision, culture, anything vaguely leadership, and general "adulting". To call all of that mushed together a "discipline" makes no sense.

Skills like coordination and vision are just as orthogonal from each-other as software engineering.

As a result the best PMs are often those who know what control to give up to make the role / team function better.

I've even been on teams where engineers seem hesitant to organize fun events because it may be perceived as stepping on a PM's turf, which is absurd!

I think teams and PMs would benefit from splitting up the role. I'd love to see the creation of roles like "Associate Producer" (as borrowed from the film industry) that have a primary task of keeping things running smoothly without a strong focus on creative or technical leadership.

I found it really weird that so many engineers and product managers in the company never really used the product the company produced at all.

I don't think that engineers should really be product managers, as an introvert I certainly didn't have the patience to sit in all the meetings that the PMs took every week, which is why I leaned on real actual PMs to do that. However, senior engineers ought to develop at least some Product Management Brain and spend a bit of time literally just using the product like a user and not as a developer.

I don't think software development should be the only thing developers do, at the strict exclusion of all else. They need the ability to be deep in some code and go "wait, is this complicated garbage actually what customers really want?" and throw a mental exception and go have a chat with the PM and determine if the requirements have gotten wildly off course. The mentality of "PMs determine the requirements, I just write the code" is a recipe for a really poor product.

Ideally the author would have held his PM team on point to deeply involve them in the product process.

It is indeed a product manager's job to rally the team around an idea ir features. They must actively seek dev input on what features to build or how to solve a customer problem. But when devs, especially dev managers think they need not be told what features to build, all beta are off.

I'd argue that the ability to perceive a situation from multiple perspectives is a learned skill, and it's particularly valuable when the two perspectives you mention as mutually exclusive can be leveraged by a single person.

Honestly, this applies to a whole lot of jobs and can be reversed for SWE too. I am a business analyst and have a few stories of working with SWE who would belittle my input to them about anything involving code because I did not code on the daily. More often then not, we would talk in a circle - I would get frustrated and comply with their suggestion, some random issue would come up, then it would be their idea to do the thing I said we should do in the first place. And this wasnt with one-off arrogant SWE that are hard to work with. Just normal people trying to be polite. but I built my initial specs as the bare minimum necessary to fit my need, and because I could not identify off the top of my head exactly what issue would arise from changing those specs (even though I could be sure there would be some issue) - they ignored my specs and did it their own way.

I lean on the SWE as the coding expert overall and would listen to their input.. but sometimes I think SWE forget that they are doing things other people do not want to do which is not necessarily things other people are not capable of doing or understanding. And sometimes a non-SWE can see what is wrong with some structure of the code despite not being able to code the solution themself.

There are 50 if you care about career advancement. There are 40 if you care about job security. There are 30 if you care about your mental health. There are 20 if you frequent hackernews and reddit.

They aren't useless, but one could argue the industry needs a reality check on how many of these supportive roles need to exist (in terms of quantity) and how many of these individuals are contributing anything. There are plenty of bad stories ranging from "benevolent but capable" to "clearly power tripping and a drain".

I wrote about this years ago: https://www.mooreds.com/wordpress/archives/134

Both things can be true: it's good to have some product mindset and you should also defer to the experts. In fact, they build on each other, otherwise how can you communicate with the experts? You have to have some common, shared language to do so. They might learn engineering, but it's more likely a dev will learn some of the domain.

Maybe that's true, but almost all the Product managers I've worked with in multiple companies were not experienced in the the domain we were working in either. They were mostly generic "product people" from random other domains. So it wasn't a stretch to say the engineers who had worked there knew more about the domain than the product folks did.

My experience is that when a product manager has true expertise, that product manager is respected easily by the whole team.

Likewise, when a product manager without specific expertise proves adept at prioritizing and gains a reputation for quality work, they are easily respected by the whole team.

But in many cases the product manager is a Stanford MBA with a couple former roles at other tech companies and has never accomplished anything very impressive. And these hires are corrosive for a product org. They get in and hire more just like themselves. The problem is not the Stanford mba it’s that all they have is a Stanford mba and confidence in their own skills. It’s not enough to demand the respect of engineers who have sometimes worked years in the domain.

Really if you are working for the company in any capacity your inout should be taken into consulting.

However it is up to executives to have a strategy, which should also take into account all those sources.

Did you mean to pull all that under "design"? I've never seen a design org that wrote technical documentation or provided support for instance.

It's so rare, and lovely, when you run into an engineer who can not only figure out how to do the task they're being assigned, but run through the next couple of steps in the future taking the team strengths, company strategy, and product shortcomings into account.

If you work with a great PM, it's fantastic. They can bring clarity to product in a way no other role can.

I worked with a couple of good PMs which were good at that: and product and profits really improved. The worse PMs are the one which just say: customer x wants y - we need to implement y. Without thinking of market landscape, future, training costs, etc.

If that layer is lossy, then you simply have a bad PM (which doesn't mean there should be NO pm, it just means you need a better one.)

Do you as an engineer want to be doing design reviews and giving feedback on page layout and usability? Do you want to be on 20 customer calls talking about the business, showing demos, and getting feedback? Do you want to present to the board what your next few releases are going to look like? Do you want to maintain a product strategy so that you have a source of truth to answer "should we build this?"

You may say "yes" for some of those some of the time, and that's great and important. But if you're saying "yes" to all of that all of the time, then congrats, you're not actually a full-time engineer, you're a PM who knows how to code :)

Of course, that's a big part of the role for a senior engineer.

But if you're building a real product, and not just a collection of random one-off features that customers ask for explicitly, then there's a whole set of work that needs to be done to enable good decision-making. It starts with defining who your customers are and what are the problems you're trying to solve for them. It goes all the way through gathering feedback from customers in a meaningful way.

> I would rather encourage engineers to get involved and understand the domain and the project than rely on this role.

The fact that you use the word "project" is interesting.

If someone comes to you and says "here's a project I need you to build for me" (could be custom development for an external customer, could be an internal stakeholder who gets to dictate custom development) then the role of product manager doesn't make sense.

If, instead, you're building something based on a need that you believe the market isn't meeting, then the role of product manager makes a lot more sense. The product manager IS the stakeholder in this case. They are the one identifying unmet needs in the market, possible customers, business problems to solve, etc. For a team trying to build something new that is expected to be sold to lots of customers, just the part of defining the market is hugely valuable, because it gives the team a starting point to evaluate any solutions they come up with.

What confidence do you have that an engineer would be less lossy in this role? It's a full-time thing when done right.

To do this a PM has to balance and understand the needs of the customers, the potential customers, the direction of the company, the direction of the market, the capabilities of the competition.

The engineering details are better left to the software engineers, architects, key users and UXers.

Sorry, but neither of those things usually require a product manager because neither of them involve building a product.

The role of product manager is basically THE key difference between building custom software and building a product.

When you're building custom software, you have a specific user who is paying you to solve a specific problem for them. The only measure of success is whether you solve their problem (within time/money budget). For these kinds of things, you're right, it's absolutely critical that the person with the problem and the person solving the problem work closely together.

When you're really building a new product, you won't even have any users and you won't have anyone paying you who's defining success for you. Someone on your team needs to figure out who are the customers you're trying to target, what problems are we trying to solve for them, how can we solve those problems in a way that's generic enough for us to sell it to multiple customers, etc. That's all legwork that a (good) product manager should be doing because, again, no one is proactively defining it for the team.

I don't know that this a HN-specific thing, but I think roles very easily become tribes, and everyone thinks their tribe is superior. E.g. I know architects who think product and engineers serve architecture, I know engineers who think they know better than product and give the "yeah-yeah" to architects, I know product managers who hate architecture and engineers because they don't see the progress they want.

I often see this as a struggle for power, normally in situations where there isn't good psychological safety/team focus/communication, which leads to a scramble for authority.

As I understand it, the article is basically just claiming that to become an outstanding engineer, you can't just code what you're told to code, you need to understand why any particular feature is needed. Obviously that doesn't replace user research, project management, business leadership and strategy, or anything like that - no developer will also be an expert in all of those things, and a good business, like any team, has differentiated roles. But a strong developer understands what's going on in other places - they understand the overall business strategy, even if they wouldn't be able to come up with a strategy on their own; they understand how users are interacting with their product, even if they aren't doing the user research themselves, and so on.

I've worked with a number of developers for whom this sort of thing was a complete mystery - they could program very well, but if they were told one day to build one thing, and the next day to build the opposite, they'd just go away and do that, and never question why their instructions made no sense. Whereas a more senior developer would want to understand why they're getting contradictory instructions, and try and explore whether there's a non-contradictory solution.