Product shouldn’t be left to product managers(candost.blog)
candost.blog
Product shouldn’t be left to product managers
https://candost.blog/mektup/mektup-32/
138 comments
I spent 10 years working as a software engineer on a product that I was originally a customer of.
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.
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.
It is weird to me to see people talking like this. Throughout my 10+ year career as an SE, all the way from junior level to senior-plus, customer- and product-mindset thinking has been seemingly mandatory. Like how would I even write the software if I didn't understand what they wanted? What would I even do/what should I even write?
We need to remember at all levels that it is people that use this stuff. Coincidentally, we are also people. So we should all be able to think as them.
It is weird to me to be separated from my stakeholders. I can't say I really like having a PM in between me and them, other than having them sit in meetings instead of me.
We need to remember at all levels that it is people that use this stuff. Coincidentally, we are also people. So we should all be able to think as them.
It is weird to me to be separated from my stakeholders. I can't say I really like having a PM in between me and them, other than having them sit in meetings instead of me.
> Like how would I even write the software if I didn't understand what they wanted? What would I even do/what should I even write?
Whatever the ticket says. I have done plenty of work that I couldn't tell you where it fit into the product or what button one would click to make it run as we otherwise had unit tests to verify it.
Whatever the ticket says. I have done plenty of work that I couldn't tell you where it fit into the product or what button one would click to make it run as we otherwise had unit tests to verify it.
That sounds disastrous. "Whatever the ticket says" is often ambiguous, poorly-written, or just plain wrong (in terms that the request is documented incorrectly and the requestor is not actually asking for what they want). Sometimes someone with technical inclinations gets too smart and thinks the solution is X when it is really Y.
In my personal experience, it is much easier to clear this up going to the requestor itself, rather than asking a PM to clear it up. I ask them high-level questions like, "so, what is it that you really want here?" to try and suss out what the actual deliverable is.
But I agree that if you have too many projects on your plate this is untenable. But then devs having too many projects on their plate is a pretty poor situation and is indicative of bad management.
In my personal experience, it is much easier to clear this up going to the requestor itself, rather than asking a PM to clear it up. I ask them high-level questions like, "so, what is it that you really want here?" to try and suss out what the actual deliverable is.
But I agree that if you have too many projects on your plate this is untenable. But then devs having too many projects on their plate is a pretty poor situation and is indicative of bad management.
It is only disastrous if the PM screws up. It is certainly more brittle though as there is a single point of failure. You also need devs willing to persist in a social endeavour in the face of uncertainty until they get something solid and many are not.
nope it's always disastrous. PMs don't know how to code.
It sounds incredibly demotivating. Is it?
Not at all. There are plenty of technical challenges that must be resolved within that. I can be fascinated by the plumbing without really understanding what the data is for.
A lot of it is also personality. I am odd. Very odd. At times Sheldon Cooper odd. Know the exact seat I want on a 787 vs an A220 odd. That makes my empathy for users awful. I will spend tons of money on pain points in my life that make everyone else think I am nuts. I will completely ignore areas of life that are top priorities for most people. I obsess when making decisions and willingly read reems of documents to figure out all the rules.
There are so many things that I do that normal people do not do. Because of that, I cannot create mass market products.I do not think anything like a typical user. I know my limits there.
A lot of it is also personality. I am odd. Very odd. At times Sheldon Cooper odd. Know the exact seat I want on a 787 vs an A220 odd. That makes my empathy for users awful. I will spend tons of money on pain points in my life that make everyone else think I am nuts. I will completely ignore areas of life that are top priorities for most people. I obsess when making decisions and willingly read reems of documents to figure out all the rules.
There are so many things that I do that normal people do not do. Because of that, I cannot create mass market products.I do not think anything like a typical user. I know my limits there.
Empathy/sympathy are important factors here. As a fellow weirdo I do not see my weirdness as an excuse for being unable to 'walk a mile in their shoes'. There are lots of people around us constantly transmitting their emotional status, I see no reason to not pay attention to that.
I have consistently found myself unable to do it well, so I outsource it. People may transmit, but I do not receive it with any meaningful accuracy.
That's fair! Thank you for the insight.
just because you're odd doesn't mean you can't empathize with others. that's a huge cop out.
Fundamentally any feature request is just an engineering problem. Sometimes they're interesting, sometimes they're not. If you trust whoever makes these issues on your board (or whatever it is you use), why would it be demotivating? You know you're building stuff folks want, because making sure that's the case is what the person making those issues is trying to do.
If you can't trust your coworkers, every workplace is demotivating.
If you can't trust your coworkers, every workplace is demotivating.
This is a fair argument. Thanks for engaging.
Why should it be demotivating trying do something perfectly as requested?
Many of us, including me, come from freelancing, and perhaps that trained many to answer most customer requests with "ok but what you really want is...", but in a company where there are people doing that as their job... Why bother?
Actually I would even go further and argue that too many passionate developers talking product management in every refinement meeting is a big inefficiency, and depending on the company size, sometimes even one is one too many.
Many of us, including me, come from freelancing, and perhaps that trained many to answer most customer requests with "ok but what you really want is...", but in a company where there are people doing that as their job... Why bother?
Actually I would even go further and argue that too many passionate developers talking product management in every refinement meeting is a big inefficiency, and depending on the company size, sometimes even one is one too many.
lol because developing products that users want/work well for users is 100x more important than writing code.
Protecting the environment and sustainability is also 100x more important than that. Do we ever draw a line where our responsibilities end or as developers do we have to gather knowledge and make the best decisions until we reach singularity or the heat death of the universe?
Delegating is okay, or you burn yourself out.
Delegating is okay, or you burn yourself out.
I save that passion for personal projects. After all, the work is buying someone else a nice house and the new electric Delorian.
Well, unless your product makes a real positive impact on people's quality of life or the environment. :) Maybe I'm just fortunate to have such an employer. (Of course my CEO also gets rich in the process, but that's not the only "mission".)
Because we are supporting too many products as it is and they are always asking for more?
I get snippets from users, but I support so many different types of users and roles, it would take probably 6 months of only training to have a rudimentary understanding of all of those roles and the products we support that they use.
And we implement SAFE "agile" and most of the time it seems like we are insulated from actual users. I got in hot water because I had the audacity to talk to a user because the client kept changing the flow after the inception meeting that ended up being the client solutionizing the project.
I get snippets from users, but I support so many different types of users and roles, it would take probably 6 months of only training to have a rudimentary understanding of all of those roles and the products we support that they use.
And we implement SAFE "agile" and most of the time it seems like we are insulated from actual users. I got in hot water because I had the audacity to talk to a user because the client kept changing the flow after the inception meeting that ended up being the client solutionizing the project.
What makes the "Product Manager" role tricky is every person and every organization has a wildly different sense of what they do.
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.
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.
Yeah. Our problem at $FAANG was that PMs were incentivized by the "footprint" they had on the product. Makes sense maybe when doing greenfield, or for a major revamp, but man did it fuck up existing long-term projects that were essentially in maintenance mode.
You'd see PMs join, change direction, narrowly grabbing a promo and leaving only to be repeated again by the next guy. Each time, the product became more complicated and much less focused.
Things like vision and strategy shouldn't factor into any performance review for at least 2 years, for long term projects. Until you know deeply (a) how everything works and (b) the cost of changing things, nobody should be allowed anywhere near those big buttons.
The only ones who knew that were the senior engineers who had been around forever. And they're not liked by management, because they tend to be nay-sayers, and they often like how things are. But if you asked management if they were willing to break existing customers the answer at the end of the day was always no. Yet they all wanted new and shiny things, in denial of the feasibility and especially cost.
You'd see PMs join, change direction, narrowly grabbing a promo and leaving only to be repeated again by the next guy. Each time, the product became more complicated and much less focused.
Things like vision and strategy shouldn't factor into any performance review for at least 2 years, for long term projects. Until you know deeply (a) how everything works and (b) the cost of changing things, nobody should be allowed anywhere near those big buttons.
The only ones who knew that were the senior engineers who had been around forever. And they're not liked by management, because they tend to be nay-sayers, and they often like how things are. But if you asked management if they were willing to break existing customers the answer at the end of the day was always no. Yet they all wanted new and shiny things, in denial of the feasibility and especially cost.
I've never understood why Development Manager and Product Designer are supposed to be the same job.
I've also never understood why product design so often seems to be sidetracked into pointless tinkering with minor changes - often unwelcome - while major issues remain unaddressed.
In reality PM seems to be a stepping stone to more senior management, so products inevitably suffer from tinkering and drift. No one really owns the product - or if they do, it's not for long.
They don't really care because they're heading elsewhere.
I've also never understood why product design so often seems to be sidetracked into pointless tinkering with minor changes - often unwelcome - while major issues remain unaddressed.
In reality PM seems to be a stepping stone to more senior management, so products inevitably suffer from tinkering and drift. No one really owns the product - or if they do, it's not for long.
They don't really care because they're heading elsewhere.
The perversity is that if they do care then they're less likely to be heading anywhere, since they won't be seen as a go-getter. The problem extends to the customers too: we all know that solid unexciting dependable quality is to be treasured, yet nothing but the pain of a dozen bad "upgrades" can conquer the lure of the shiny newness.
I've seen there are two distinctly different types of PMs for greenfield and existing products. Product Managers for greenfield and technical program managers for existing products. Their focus tends to be different. Product managers focus on making sure that the product solves the customer problem. Technical program managers focus on ensuring things like quality and supportability are built into the product. Sounds like this might help solve the problem at FAANG.
Isn't that Associate Producer role something like a Program Manager (PgM) / Technical Program Manager (TPM)? That's been my experience at Google.
Good TPM is that and worth their weight in gold... That's the role which should be more common across industry. Being a PM without a TPM sucks.
Eh, some software engineers are good at product. Some are even good at charming clients. You got to understand the people you work with and adjust the processes and roles to match that, not the other way around.
What if your users are developers or engineers? I haven't had a ton of luck with my specific niche and product management (niche domain; final product is a library developers code against) across multiple companies. I can imagine your statements can apply to some future market where we have plenty of engineers, but in the US, we have a shortage. It's hard to imagine how to use your advice when we cannot find enough engineers with the domain and technical skill combo. Let alone one to convert to product. What do we do for the rest of my career which will probably continue to have a shortage of engineers?
Our solution is to trust the experts, but certainly there must be something better than "whatever the current engineer thinks."
Our solution is to trust the experts, but certainly there must be something better than "whatever the current engineer thinks."
> What if your users are developers or engineers?
What if they’re kindergarten teachers, in medical sales, rocket scientists, or Amazon deliver drivers?
Part of the Product Manager’s job is to understand and get in the head of the user, if they can’t do it for your users they’re the wrong Product Manager. If they’re relying on the engineers they the wrong Product Manager.
What if they’re kindergarten teachers, in medical sales, rocket scientists, or Amazon deliver drivers?
Part of the Product Manager’s job is to understand and get in the head of the user, if they can’t do it for your users they’re the wrong Product Manager. If they’re relying on the engineers they the wrong Product Manager.
[deleted]
[deleted]
>____ are in those roles not because they cannot do other roles, but because someone needs to _______
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.
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.
Thanks for stating this so eloquently. Agreed that product is a joint responsibility but what most people miss is the division of labor. Talented dev managers think they will 'solve the problem' and the other types are just jealous. I sometimes joke that a product manager's job is most sought after now a days...everyone from devs to pmms want it . As a PM, this is the single most stressful part.
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.
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.
> There are only 40 hours in a productive work week (if you care about your health)
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.
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.
Exactly at an IC level (specially for an engineer), it's best to become an expert and specialize, that is how you can bring most value to the organization.
This! I‘ve seen so many teams and products spectacularly failing because someone thought that the lead developer should also be the product manager. For all the hate that software development frameworks like scrum get - the one thing it gets really right is that there are roles that should never be merged in a functional team.
> Two roles that do not fit into one person's brain are Product Manager and Software Engineer.
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.
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.
The best experiences I had were working on products I cared about deeply in a way a PM should AND there actually was a PM involved who did care about them. In fact everybody involved should.
However, in a project there is a bunch of stuff you need to do that's mainly specific to product management. Tracking the feedback, talking to users, coordination with other product teams, covering the nontechnical pieces, etc. Every stakeholder does their thing. The PM in most cases doesn't code, a legal or compliance stakeholder doesn't try to talk to users or come up with product feature roadmaps, the engineers don't create the artwork etc.
The shittiest experience is when you work on a product with a formal PM but you wonder what it even is they are doing, not engaging in shaping the details just signing off, not talking to stakeholders, etc. and you, the engineer, has to fill in. Buuut you also cannot just do whatever because the PM exists and needs to be consulted.
However, in a project there is a bunch of stuff you need to do that's mainly specific to product management. Tracking the feedback, talking to users, coordination with other product teams, covering the nontechnical pieces, etc. Every stakeholder does their thing. The PM in most cases doesn't code, a legal or compliance stakeholder doesn't try to talk to users or come up with product feature roadmaps, the engineers don't create the artwork etc.
The shittiest experience is when you work on a product with a formal PM but you wonder what it even is they are doing, not engaging in shaping the details just signing off, not talking to stakeholders, etc. and you, the engineer, has to fill in. Buuut you also cannot just do whatever because the PM exists and needs to be consulted.
I’ve had that product manager before. The real Shittiest PM isn’t the one who’s absent, it’s the one who does too much but not well. Constantly shifting priorities, unclear, yet rigid guidance, and unrealistic targets.
You could say this for almost any primarily supportive role. Individuals forget these roles bring nothing on their own and exist entirely to empower ICs. Conversely, that means they can disenfranchise ICs and be a net loss just as easily.
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".
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".
Part of this problem, IMO, is that we as a society have largely eliminated subordinate supporting roles, in favor of adding more organizational work to both the ICs and management tier. Which leads to needing more managers, which leads to beaurocratic bloat as the people who have the power to make decisions end up being in a position where increasing management overhead improves their standing.
It all went downhill once we decided ICs should not only take care of the bureaucracy, but also adapt to supporter roles rather than the other way around. I won't rail against the usefulness of soft skills, but requiring almost every IC to be a well-spoken social butterfly just seems lazy in the face of the ridiculous number of supporting roles.
Ideally it'd be more 50/50 (help-me-help-you kind of deal), but right now it feels incredibly one-sided at most places.
Ideally it'd be more 50/50 (help-me-help-you kind of deal), but right now it feels incredibly one-sided at most places.
Exactly. It's the difference between having a manager and having a secretary. When your support staff also has the power to fire you, it's inevitable that the technical staff have to adapt to the support.
I've seen and lived what you describe on occasion and it sucks. Managing the features does not mean deciding them, just like programming the features does not mean deciding them. Same for all disciplines. Establishing the process and responsibilities around which decisions are made is the hardest part of directing a project, and the default often ends up becoming "I direct thus I decide".
I have a PM who basically makes A/B choices as presented by tech leads, and leaves it to tech leads/devs to meet with users..
[deleted]
People that aren’t pulling their weight are annoying in any role.
>Although these topics are not related to coding at all, they make me a better engineer and engineering leader.
This is fine for shallow problems in the business space, but eventually you will get to harder problems and will need to collaborate with experts. Experts are experts because they spend many hours on those subjects. You are an expert at engineering because you spend many hours on that subject.
Don't let your recently acquired domain knowledge make you overconfident enough to not reach out to experts. Everyone thinks they know how something works until someone more knowledgeable comes along.
>instead of expecting someone (e.g., product managers) to tell you which product features to develop, you should be able to tell what are the most critical problems your users or product are facing and find the best solutions that fit into your product and engineering strategy.
Which is fine if the problems are obvious and there are easy wins to be had. Your solution's effectiveness is limited by your expertise in the domain.
This is a regular pattern I see, which is "developers pretending to be experts at everything because they're good at picking up knowledge and skills". There is a time component you can't skip when acquiring domain knowledge.
Additionally, while it's great to strive to be an expert in both engineering and the domain, you're naturally doing two jobs for the price of one. Many domain experts with a singular expertise might also make more than developers striving to be double-experts at the lesser price of a developer.
This is fine for shallow problems in the business space, but eventually you will get to harder problems and will need to collaborate with experts. Experts are experts because they spend many hours on those subjects. You are an expert at engineering because you spend many hours on that subject.
Don't let your recently acquired domain knowledge make you overconfident enough to not reach out to experts. Everyone thinks they know how something works until someone more knowledgeable comes along.
>instead of expecting someone (e.g., product managers) to tell you which product features to develop, you should be able to tell what are the most critical problems your users or product are facing and find the best solutions that fit into your product and engineering strategy.
Which is fine if the problems are obvious and there are easy wins to be had. Your solution's effectiveness is limited by your expertise in the domain.
This is a regular pattern I see, which is "developers pretending to be experts at everything because they're good at picking up knowledge and skills". There is a time component you can't skip when acquiring domain knowledge.
Additionally, while it's great to strive to be an expert in both engineering and the domain, you're naturally doing two jobs for the price of one. Many domain experts with a singular expertise might also make more than developers striving to be double-experts at the lesser price of a developer.
I’ve served many roles in tech. Engineer, lead, manager, director and now founder.
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.
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.
Fwiw, it's not really their fault. Management who put this in place suck.
> This is a regular pattern I see, which is "developers pretending to be experts at everything because they're good at picking up knowledge and skills". There is a time component you can't skip when acquiring domain knowledge.
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.
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.
Absolutely true - but at the end of the day some one has to be vested with making the final decision. That's what Product Managers are for, they're vested with making the final call. As you point out, good Product Managers won't be overbearing overlords just like good engineers aren't simple order takers.
Which decision?
How a feature UX should work based on the PM having a fair bit of expertise in the field? Maybe.
What task you work on next? Maybe not.
You see the problem with letting someone who's not an expert in the work decided the work goes both ways. The PM is in charge? Good luck getting patching on the backlog. Don't consult the PM? Good luck getting the functionality right.
My takeaway is the PMs often aren't the experts in writing, maintaining, or running a production system, thus they probably shouldn't actually run the backlog. But said production system is pretty useless without market fit, so you want to strongly align with whoever your version of a PM is.
How a feature UX should work based on the PM having a fair bit of expertise in the field? Maybe.
What task you work on next? Maybe not.
You see the problem with letting someone who's not an expert in the work decided the work goes both ways. The PM is in charge? Good luck getting patching on the backlog. Don't consult the PM? Good luck getting the functionality right.
My takeaway is the PMs often aren't the experts in writing, maintaining, or running a production system, thus they probably shouldn't actually run the backlog. But said production system is pretty useless without market fit, so you want to strongly align with whoever your version of a PM is.
If you can't get a fix into the backlog either the details of the bug aren't explained well enough or the fix isn't as important as you might think.
I can relate to my first job out of college. I had my first triage session and I was shocked by how many bugs we wouldn't fix. I wanted to fix them all - in fact I stood up and said, "how can we not fix these, these are real bugs!" I eventually learned that the job of SW isn't engineering purity. It is to apply available resources to maximize impact for the customer (and if this is at a for-profit company, to maximize profit). I think sometimes developers can get stuck on just writing the best code possible, and forget the actual reason there is someone giving them a paycheck.
I can relate to my first job out of college. I had my first triage session and I was shocked by how many bugs we wouldn't fix. I wanted to fix them all - in fact I stood up and said, "how can we not fix these, these are real bugs!" I eventually learned that the job of SW isn't engineering purity. It is to apply available resources to maximize impact for the customer (and if this is at a for-profit company, to maximize profit). I think sometimes developers can get stuck on just writing the best code possible, and forget the actual reason there is someone giving them a paycheck.
I'm not sure, there's something good from that fresh perspective: why do we have software that's that broken and why do we think this is normal?
We've given up on logical systems and we deal with so much complexity that we're dealing with kind-of-biological systems where reasoning about the system is not possible anymore.
We've given up on logical systems and we deal with so much complexity that we're dealing with kind-of-biological systems where reasoning about the system is not possible anymore.
The Product Manager owns the what?, they don't own the how? or how long?. They're getting feedback and directing the sales team, the marketing team, the engineering team, the UI team, the QA team and the support team. It should be easy for a competent engineering team to get patching on the backlog - after all, that's table stakes. Organizations struggling with the mundane is the very definition of dysfunctional.
But very common.
Which goes back to the point, maybe Product aren't master of the universe directing all the teams, but just another group of folks with relevant skills that should advise and advocate, but not direct the others groups, whom are the actual experts of their respective areas.
Which goes back to the point, maybe Product aren't master of the universe directing all the teams, but just another group of folks with relevant skills that should advise and advocate, but not direct the others groups, whom are the actual experts of their respective areas.
maybe Product aren't master of the universe directing all the teams, but just another group of folks with relevant skills that should advise and advocate - absolutely agree! However, there are many teams involved and sometimes they have conflicting priorities and/or proposed directions. Some one has to be responsible and make the call. That's the Product Owner's job. Maybe this needs to be said, you can be the perfect Product Owner but that doesn't mean someone isn't going to be butt hurt over a decision you made. It just comes with the territory of being a leader.
Sure, but again, why's my _leader_ the non-technical person?
Listen, I've been around the block and I understand it's quite common for the PM or other similar softer roles to be given leadership.
I've seen this to the point where they both recruit and promote the techs themselves.
What I'm saying is it doesn't have to be like this. If the PMs job is to find and articulate value, and the Engineers job is to produce said value, on a well performing team, it's a match made in heaven.
A poor PM with dominance over tech will happily torpedo the Engineers career with little emphathy whilst doing so, so why do we assume tech leadership should be in a different department?
My opinion is align the Engineer KPIs with value, which aligns them with strong PMs, but allow them the autonomy to say no when it makes sense to.
Just an opinion tho :)
Listen, I've been around the block and I understand it's quite common for the PM or other similar softer roles to be given leadership.
I've seen this to the point where they both recruit and promote the techs themselves.
What I'm saying is it doesn't have to be like this. If the PMs job is to find and articulate value, and the Engineers job is to produce said value, on a well performing team, it's a match made in heaven.
A poor PM with dominance over tech will happily torpedo the Engineers career with little emphathy whilst doing so, so why do we assume tech leadership should be in a different department?
My opinion is align the Engineer KPIs with value, which aligns them with strong PMs, but allow them the autonomy to say no when it makes sense to.
Just an opinion tho :)
> This is a regular pattern I see, which is "developers pretending to be experts at everything because they're good at picking up knowledge and skills". There is a time component you can't skip when acquiring domain knowledge.
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.
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.
Even in that situation, the PM should be striving for more domain knowledge than the devs. Devs shouldn't be expected to pick up that slack. If they are, they should be compensated for it.
The funny thing is, developers will always have a more precise and detailed domain knowledge. Because unlike the PM, who can analyze the problem in the abstract and approximate, the developer must produce working code.
However it is very difficult to have empathy with the user when you're trying to produce code. Also, you're generally judged on your ability to 'finish US' quickly. So generally you'll choose an approach 'that works'. Only to have the feedback 'great, but why did you not think about this?'
However it is very difficult to have empathy with the user when you're trying to produce code. Also, you're generally judged on your ability to 'finish US' quickly. So generally you'll choose an approach 'that works'. Only to have the feedback 'great, but why did you not think about this?'
> However it is very difficult to have empathy with the user when you're trying to produce code.
Not only that, but as a dev you can get into a position where what you decide to work on is based more on ease of development or “fits cleanly with what we have now”.
There should be a balance. The PM should push for the impossible and the engineers can tell the PM why that won’t work. Kind of… maybe not with that much hyperbole in my assertion.
Not only that, but as a dev you can get into a position where what you decide to work on is based more on ease of development or “fits cleanly with what we have now”.
There should be a balance. The PM should push for the impossible and the engineers can tell the PM why that won’t work. Kind of… maybe not with that much hyperbole in my assertion.
> the developer must produce working code.
Bingo, I can't (well won't) build a contradiction even if its part of the spec.
> Only to have the feedback 'great, but why did you not think about this?'
Even worse IMO: "Great, no problems!" every time. Ok, I'm not that good, is anyone even running this shit?
Bingo, I can't (well won't) build a contradiction even if its part of the spec.
> Only to have the feedback 'great, but why did you not think about this?'
Even worse IMO: "Great, no problems!" every time. Ok, I'm not that good, is anyone even running this shit?
The best products I've worked for took input (mainly) from three sources:
- Product Managers: a.k.a. the voice of the customer, what customer want and need
- Engineering: what's possible, rethinking the product from the tech POV, to create delightful experiences.
- Executives: Vision about what the company should be in the long term
All these crossed by a strong design team, to make sure we've a coherent UI, internationalization teams, accessibility, documentation, support, etc.
When all these align, it's a magical experience where you feel you're making something useful. Your product not just does what is requested, but it solves problems for customers they didn't know they had in the first place, because they had no way of framing it, competitors start playing catch-up, and you end up in the lead defining a market.
Typically you also end up having magnific engineering challenges with solutions that will make you proud of having built them.
As usual, always think about what's valuable and why, and push for that.
- Product Managers: a.k.a. the voice of the customer, what customer want and need
- Engineering: what's possible, rethinking the product from the tech POV, to create delightful experiences.
- Executives: Vision about what the company should be in the long term
All these crossed by a strong design team, to make sure we've a coherent UI, internationalization teams, accessibility, documentation, support, etc.
When all these align, it's a magical experience where you feel you're making something useful. Your product not just does what is requested, but it solves problems for customers they didn't know they had in the first place, because they had no way of framing it, competitors start playing catch-up, and you end up in the lead defining a market.
Typically you also end up having magnific engineering challenges with solutions that will make you proud of having built them.
As usual, always think about what's valuable and why, and push for that.
This, frankly, is the real definition of a unicorn software company.
I'm pretty sure it has nothing to do with a unicorn - a unicorn is on a fast growth trajectory, with a large and reasonably-likely upside. Not necessarily one that where PMs, execs, and eng can finish each others' sentences, they're so well attuned.
I’ll admit that I didn’t make it clear the sarcasm/joke. But I was playing on the fact that a unicorn is a mythical creature, just as mythical as this functioning proddev team.
I thought they meant unicorn, as in the unicorn love partner who has all the great qualities and doesn't exist, rather than the VC unicorn, a quick-to-a-billion company.
[deleted]
I agree. Also add customer support / customer success to that list of sources and marketing / SEO.
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.
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.
I'm sure I'm not the only one in the audience interested in more details about how the specific team you may be talking about was organized to come together, operated, and evolved. Great to hear about the key role of designers being recognized.
It would take a book to go over it.
In the early stages is all about hiring. Getting the right people, minimal structure and let them do what they're best at with a few key leaders with a strong vision.
As you grow, you need to build the leadership structure, true believers that let the help people grow. That's the main part, leaders main concern should be people. You need a structure that trusts and empowers employees. If you did the hiring in the first phase right, some of those will rise to lead (maybe as proper managers or as tech leads, architects, lead designers, etc.)
Usually, at first you build structure for product and engineering, and maybe place a few UX/Designers as cross functional roles, with little structure, to help all teams build coherent UI.
Eventually they grow into their own org and are involved in product driven features in the early stages. Doing mocks, running usability labs, etc.
With other functions, such as accessibility and i18n (even security) the same happens, as the org can accommodate them these structures start gaining size and their own internal structure.
As the team grows into the hundreds process appears, but is should always be more of a helper than a straightjacket.
In the early stages is all about hiring. Getting the right people, minimal structure and let them do what they're best at with a few key leaders with a strong vision.
As you grow, you need to build the leadership structure, true believers that let the help people grow. That's the main part, leaders main concern should be people. You need a structure that trusts and empowers employees. If you did the hiring in the first phase right, some of those will rise to lead (maybe as proper managers or as tech leads, architects, lead designers, etc.)
Usually, at first you build structure for product and engineering, and maybe place a few UX/Designers as cross functional roles, with little structure, to help all teams build coherent UI.
Eventually they grow into their own org and are involved in product driven features in the early stages. Doing mocks, running usability labs, etc.
With other functions, such as accessibility and i18n (even security) the same happens, as the org can accommodate them these structures start gaining size and their own internal structure.
As the team grows into the hundreds process appears, but is should always be more of a helper than a straightjacket.
> All these crossed by a strong design team, to make sure we've a coherent UI, internationalization teams, accessibility, documentation, support, etc.
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.
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.
No, I meant design team, i18n team, doc team, support team, security team, etc. Each with their respective roles.
Product Managers today are many times attempting to be shitty tech leads rather than actual product managers, which is a completely different job. If a product manager has more than a superficial opinion about what engineering is doing, then they are not a product manager (more than by title). They should feed the why and when to engineering, nothing more. When do the market opportunities exist and why? Collect and feed the data to engineering (as well as other stakeholders). They should not be the customer proxy, not lead engineering teams, nor be some go-to person for "final decisions" on design matters.
It sounds like you are dealing with a technical program manager. TPM does/should engage technically, and overlaps responsibilities with an engineering manager. Not every project requires a TPM so perhaps yours only requires an engineering manager/tech lead.
None of what you are saying makes any sense to me. This is another big problem in the software industry, that roles with the same name can vary wildly. A little bit like "agile" not ever quite looking the same and not ever quite working.
A program manager for me, any kind, relates to the function of leading and coordinating multiple interrelated projects, towards a common goal.
A program manager for me, any kind, relates to the function of leading and coordinating multiple interrelated projects, towards a common goal.
Yes, as I said not every project needs a TPM. So if your product manager is trying to take on a TPM role for a project contained within your team, they aren't really adding value.
I know the title is consistent with the article, but the undertone of the title (to me) implies "because they will mess it up" but really the context is because engineers hit a growth ceiling without a product mindset.
The title just verges in clickbait to me
The title just verges in clickbait to me
As someone who moved from Engineering to Product Management, I agree with this article for the most part. It's really important that Engineers grow their product sense and other product skills. Not just so you can communicate effectively within your org with other teams and with your PM, but because it helps you empathize for your customers.
The thing a lot of engineers (including myself at one point my career, perhaps) lack is empathy for their customer. Your job isn't to write code, your job is to solve problems for the customer. The value a company generates with it's software is by taking on customer problems and making it their problem to solve. Solving the problem is fundamentally the most important thing. But to understand the problem you need to understand the customer, and that requires empathy.
Anything you do in your career that improves your empathy towards your customers will make you a better engineer because you'll make better decisions at every turn in ways which grow the business and improve customer QoL. Maybe along the way you'll also learn the value of PMs and maybe decide you might rather be one... that's kind of what happened with me.
The thing a lot of engineers (including myself at one point my career, perhaps) lack is empathy for their customer. Your job isn't to write code, your job is to solve problems for the customer. The value a company generates with it's software is by taking on customer problems and making it their problem to solve. Solving the problem is fundamentally the most important thing. But to understand the problem you need to understand the customer, and that requires empathy.
Anything you do in your career that improves your empathy towards your customers will make you a better engineer because you'll make better decisions at every turn in ways which grow the business and improve customer QoL. Maybe along the way you'll also learn the value of PMs and maybe decide you might rather be one... that's kind of what happened with me.
As someone who is in the product realm, one thing that has frustrated me about engineers is how difficult it can be to get Engineers to see see where the puck is going, let alone to skate to it. Many seem to want to operate much like a computer - they take a literal input and give an exact output.
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.
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.
> 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.
Probably because engineers like that often won't want to work in environments where they're "assigned" "tasks". If you want people who take initiative and lead, you need to give them the space to do that! Otherwise, the rare successes you're seeing are from people who not only have the strengths you outlined but also have the patience, skills and mental energy to fight through a culture and process that structurally pushes them to be low-ownership task-takers.
Probably because engineers like that often won't want to work in environments where they're "assigned" "tasks". If you want people who take initiative and lead, you need to give them the space to do that! Otherwise, the rare successes you're seeing are from people who not only have the strengths you outlined but also have the patience, skills and mental energy to fight through a culture and process that structurally pushes them to be low-ownership task-takers.
As someone who employs both product managers and engineers, if you spoke about (let alone to) an engineer like this in my earshot, you’d be given a box to pack your things.
You’re not nearly as valuable as you think you are.
You’re not nearly as valuable as you think you are.
[deleted]
Similar to my sibling comment, let's rephrase this the other way around (a bit tongue in cheek) and let's see how you like it (and then you maybe rethink what you wrote).
As someone who is in the engineering realm, one thing that has frustrated me about Product people is how difficult it can be to get Product Owners to see where the puck is going, let alone to skate to it. Many seem to want to operate much like a stakeholder/customer proxy - they take a literal input and give an exact output.
It's so rare, and lovely, when you run into a Product Owner who can not only figure out how to parrot what stakeholders told them, but run through the next couple of steps and understand what their actual needs are vs. what they say they want, embed it in the company strategy and make time for polishing the product and keeping it up to date technically instead of just chasing the umpteenth UI overhaul fad they can present to get a promotion and be out of there.
As someone who is in the engineering realm, one thing that has frustrated me about Product people is how difficult it can be to get Product Owners to see where the puck is going, let alone to skate to it. Many seem to want to operate much like a stakeholder/customer proxy - they take a literal input and give an exact output.
It's so rare, and lovely, when you run into a Product Owner who can not only figure out how to parrot what stakeholders told them, but run through the next couple of steps and understand what their actual needs are vs. what they say they want, embed it in the company strategy and make time for polishing the product and keeping it up to date technically instead of just chasing the umpteenth UI overhaul fad they can present to get a promotion and be out of there.
It's possible he works with bad engineers. What he said is true of working with certain types of bad engineers, just like what you say is true of bad PMs. It is what it is. Working with people who aren't competent sucks in any domain, it's not exclusive to tech, engineering, product, design, whatever. It's everywhere.
Absolutely understood, no worries there. I think both my sibling and I were more concerned with his blanket statement approach and how the way they wrote it is quite offensive, especially if a good engineer reads it. I hope my 'returning the favor' could make them see that as I'm sure they are one of the good ones and wouldn't like to be described that way either. I have met both product people for which that description would fit perfectly though and ones that were awesome and actually knew their product well and could balance everyone's needs and coax the real needs out of stakeholders and users. And lots in between.
Yep, for sure.
Yeah, there's a lot of bad product folks out there. It's a valid criticism. I hope I'm not one of them.
I'm skeptical of the role of PMs – it often feels like a lossy communication layer between stakeholders, and engineering has to get involved in some level of detail to understand what has to be built anyway. I would rather encourage engineers to get involved and understand the domain and the project than rely on this role.
It's good to be skeptical, but I think the role is critical if done right. Someone described a good PM as "a conductor keeping the orchestra in sync". And even as you described - someone needs to be the layer to gather feedback from customers, make sure it's feasible to build, decide what to build vs. what not to build and when, make sure executives are happy, keep the designers on track and focused, 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 :)
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 :)
A good PM is an advocate for the customer, but the role also ends up having to balance needs from Engineering and company vision.
If you work with a great PM, it's fantastic. They can bring clarity to product in a way no other role can.
If you work with a great PM, it's fantastic. They can bring clarity to product in a way no other role can.
Main role of the PM is to prioritize: what get build/shipped first, what later, what not?
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.
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.
One of the most important role of PMs is to tell the team what not to implement. Or which feature to remove.
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.
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.
> engineering has to get involved in some level of detail to understand what has to be built anyway
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.
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.
> I would rather encourage engineers to get involved and understand the domain and the project than rely on this role.
What confidence do you have that an engineer would be less lossy in this role? It's a full-time thing when done right.
What confidence do you have that an engineer would be less lossy in this role? It's a full-time thing when done right.
PM is just an adult you need when the developers are...
Unfortunately I have found that a really good Product Manager is an extremely rare thing. However the best organizations and teams I have worked on have always had strong product management. There seems to be a general lack of education and training on how to be a product manager. Too often folks from other disciplines, such as Engineering transfer into the role with no training whatsoever and end up doing a terrible job with it.
I don’t think some thing can be trained. Product managers usually need to do the most varied things in any organization so they just need to be quick learners/able to “understand everything” while making good decisions and having good taste. Certs and degrees don’t really help that. In fact “Product Management Certificate” sounds like the biggest smell imagineable for working with a PM
To bridge off of this comment, has anyone found a particular Product Management resource or training that is an effective on-ramp to doing the job well?
Inspired: https://www.amazon.com/INSPIRED-Create-Tech-Products-Custome...
Empowered: https://www.amazon.com/gp/product/B08LPKRD5L/
Good Strategy/Bad Strategy: https://www.amazon.com/Good-Strategy-Bad-Richard-Rumelt/dp/1...
Empowered: https://www.amazon.com/gp/product/B08LPKRD5L/
Good Strategy/Bad Strategy: https://www.amazon.com/Good-Strategy-Bad-Richard-Rumelt/dp/1...
I’m a former engineer (was Principal at an SF company most of HN will have heard of), CTO (of startups nobody will know), and a former engineering manager and current product manager at a household name.
Engineers should develop product skills, but most of them are absolutely abysmal at it. But they should try.
One of the key things I run into is smart people thinking they are the smartest people in the room. Engineers tend to have this quality more than most. I can not overstate how toxic that can be when having a product meeting with a customer.
I think the article is broadly right, just remember: product management is much more about empathy than it is engineering, and it’s OK to leave that to somebody else in a commercial setting if you’re not prepared to be humble at every step.
Engineers should develop product skills, but most of them are absolutely abysmal at it. But they should try.
One of the key things I run into is smart people thinking they are the smartest people in the room. Engineers tend to have this quality more than most. I can not overstate how toxic that can be when having a product meeting with a customer.
I think the article is broadly right, just remember: product management is much more about empathy than it is engineering, and it’s OK to leave that to somebody else in a commercial setting if you’re not prepared to be humble at every step.
> Up until my mid-level engineering, I didn’t think about the product.
I think our career yardsticks are very different.
Engineering is all about designing within constraints. Someone who's not designing to meet business constraints isn't doing a real engineering job for the company.
Learning patterns and practices would be something you'd do in an apprenticeship if software worked like real engineering. Or if it worked like academics. Or like a trade. But you'd learn that while you also learned about how that all fit the larger context because that's part of working your way to journeyman (whatever that's called now).
So . . . I agree with the author, but I don't see a need to attack product folks. We so-called engineers should probably take our craft more seriously.
I think our career yardsticks are very different.
Engineering is all about designing within constraints. Someone who's not designing to meet business constraints isn't doing a real engineering job for the company.
Learning patterns and practices would be something you'd do in an apprenticeship if software worked like real engineering. Or if it worked like academics. Or like a trade. But you'd learn that while you also learned about how that all fit the larger context because that's part of working your way to journeyman (whatever that's called now).
So . . . I agree with the author, but I don't see a need to attack product folks. We so-called engineers should probably take our craft more seriously.
This article is a worthwhile read and I can’t recommend it enough to anyone who wants to hit senior/staff/principal engineer or above.
Technical skills are not enough. You’re not hired to write software; you’re hired to write software that solves problems. Once you realize this; you’ll develop skills that complement your technical skills and amplify your effectiveness and value.
Expecting to be given a requirements doc or spec and then delivering an interesting solution is rare. Building exceptional solutions requires you to intimately understand the problem space and how your software’s users will think, and solving the problems that they might not have even known about.
Anyway read the fine article.
Technical skills are not enough. You’re not hired to write software; you’re hired to write software that solves problems. Once you realize this; you’ll develop skills that complement your technical skills and amplify your effectiveness and value.
Expecting to be given a requirements doc or spec and then delivering an interesting solution is rare. Building exceptional solutions requires you to intimately understand the problem space and how your software’s users will think, and solving the problems that they might not have even known about.
Anyway read the fine article.
Wonder if someone can share their experience with product driven teams as in
https://www.thoughtworks.com/en-us/insights/blog/project-vs-...
One recurring issue i have seen on my team is that project managers are acting like architects and tech leads (like other comment mentioned here). Wondering if the same thing.
https://www.thoughtworks.com/en-us/insights/blog/project-vs-...
One recurring issue i have seen on my team is that project managers are acting like architects and tech leads (like other comment mentioned here). Wondering if the same thing.
Ideally, SWEs should have a product mindset. In practice, this can be difficult to achieve depending on the company.
In my experience at my own job, a lot of the business level stuff is not documented anywhere. This stuff can only be learned through meetings and informal communications with other teams and things change from day to day. It's really a full time job to keep track of all these changes and get trained.
In a best case, tons of business level knowledge would be documented and centralized somewhere. This would make it easier for devs to understand and contribute at levels other than Software Engineering.
I understand this overhead is not something many companies want to contribute to. It's much easier to just hire a PM and let them deal with it.
In my experience at my own job, a lot of the business level stuff is not documented anywhere. This stuff can only be learned through meetings and informal communications with other teams and things change from day to day. It's really a full time job to keep track of all these changes and get trained.
In a best case, tons of business level knowledge would be documented and centralized somewhere. This would make it easier for devs to understand and contribute at levels other than Software Engineering.
I understand this overhead is not something many companies want to contribute to. It's much easier to just hire a PM and let them deal with it.
Meh article, sure as a dev you'll be a better Dev if you learn about the product requirements like a PM does, you'll also be a better Dev if you learn how to deploy the product becoming a DevOps, if you become a language expert, a SCM expert, a build expert, an OS expert...
Is Product Manager the same thing as Product Owner (like in the Scrum framework) ?
PO and software engineer are roles demanding many things and I find it hard for the same person to do the two jobs.
I agree in part with the article on the fact that developers must have empathy and must think about the final user but I don't think it means that it's the developer role to gather all the domain knowledge, analyze the market to decide which feature has priority, etc.
It doesn't mean that developer can't confront the PO's vision, challenge a feature (in the same way than developer can suggest really good idea for UI or UX evening if it's not their expertise).
Everyone in this thread needs to read this: https://www.jpattonassociates.com/dual-track-development/
As a (young) PM - yes!
How I wish engineers in my little company expressed a little more curiosity about our users and how the things we make solve their actual problems. Would be a huge load off my mind.
However, I can’t imagine our engineers taking over my job entirely and being able to just do both. They’re just not the type of people who could handle talking to the marketing and sales people. Not to mention the clusterfuck that is our actual users and use cases.
How I wish engineers in my little company expressed a little more curiosity about our users and how the things we make solve their actual problems. Would be a huge load off my mind.
However, I can’t imagine our engineers taking over my job entirely and being able to just do both. They’re just not the type of people who could handle talking to the marketing and sales people. Not to mention the clusterfuck that is our actual users and use cases.
Some organizations, when confronted with a dysfunctionality problem, think "I know, let's have product managers." Now they have two problems.
[deleted]
I think people have lost sight, or perhaps never understood, the role of the product manager. The role of the product manager is to manage the product through the product lifecycle. Concept, R&D, launch, iteration/revision, maturity, decline and retirement. I’ve been fortunate enough to bring new winning products to market and to kill off a fair few. Both ends are rewarding.
I agree with the author, but it's also possible to take the other extreme where engineers think they don't need any input from product.
Im always happy when I bump into articles like this one.
In general I think it's ultimately irresponsible to centralize ideation on one stakeholder.
Wrote a piece with a similar opinion here: https://jonathankorn.substack.com/p/your-teams-relationship-...
In general I think it's ultimately irresponsible to centralize ideation on one stakeholder.
Wrote a piece with a similar opinion here: https://jonathankorn.substack.com/p/your-teams-relationship-...
Best product managers seem to have one foot still in the user community.
This is more common for internal applications, where you have a PM and likely one or more actual users involved in the project.
That means when there is a new requirement two days before go-live, there's usually a meaningful reason, not just that a VP had a flash of inspiration the night before.
This is more common for internal applications, where you have a PM and likely one or more actual users involved in the project.
That means when there is a new requirement two days before go-live, there's usually a meaningful reason, not just that a VP had a flash of inspiration the night before.
YUP
If at all possible, have the actual architects and coders talking directly to the end users.
Avoid having the product managers talking to the user managers. Avoid even more having executives talking to executives. (At least exclusively, of course one needs customer executive input to discover what they need, but that is really as other users, e.g., of the reports generated). Keeping the discussions high-level instead of coder-user is pretty much a guarantee of multiple rewirtes, add-ons, extensions, cost and schedule overruns, and generally poor results. Even when everyone is sincerely working hard to get a good result, merely the result of the 'telephone' game, and loss of key details which indicate real issues and latent structures/processes that need to be taken into account in the design...
It may seem frivolous, but it is a key to successful projects, whether as a consulting org or internal enterprise development.
If at all possible, have the actual architects and coders talking directly to the end users.
Avoid having the product managers talking to the user managers. Avoid even more having executives talking to executives. (At least exclusively, of course one needs customer executive input to discover what they need, but that is really as other users, e.g., of the reports generated). Keeping the discussions high-level instead of coder-user is pretty much a guarantee of multiple rewirtes, add-ons, extensions, cost and schedule overruns, and generally poor results. Even when everyone is sincerely working hard to get a good result, merely the result of the 'telephone' game, and loss of key details which indicate real issues and latent structures/processes that need to be taken into account in the design...
It may seem frivolous, but it is a key to successful projects, whether as a consulting org or internal enterprise development.
> It may seem frivolous, but it is a key to successful projects, whether as a consulting org or internal enterprise development.
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.
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.
True, I was talking mostly about custom software, but I've also turned that into products.
>> 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.
And this is exactly the task that should be done, NOT ONLY by the project manager. Perhaps, if the PM has a stunning level of deep knowledge of both the engineering capabilities and the product's domain, (s)he might be able to make a good stab at it. But getting actual engineers talking to actual intended users and integrating that knowledge will still make a better product. I'm sure there are some PMs that can pull it off, but...
How many times have you used a product and had to ask "how TF this this even pass first user testing"?. They'd already committed to what turns out to be a dumb design and it was too late to fix it.
>> 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.
And this is exactly the task that should be done, NOT ONLY by the project manager. Perhaps, if the PM has a stunning level of deep knowledge of both the engineering capabilities and the product's domain, (s)he might be able to make a good stab at it. But getting actual engineers talking to actual intended users and integrating that knowledge will still make a better product. I'm sure there are some PMs that can pull it off, but...
How many times have you used a product and had to ask "how TF this this even pass first user testing"?. They'd already committed to what turns out to be a dumb design and it was too late to fix it.
If you are looking for a template to start practicing Product Thinking: https://www.youtube.com/watch?v=oQQroSjxc74
This argument is silly. Imagine product managers writing software on top of the software engineers job. It will be caos. Roles were made to avoid that, so everyone can focus on the right role, task and purpose.
The part that Product groups sometimes miss if they dont have process/mechanisms in place for it, is feedback from field groups (sales, TAMs, PS, VARs, et al) who bring direct, 'real world' feedback...
well, yeah. everyone helps ideate on the product.
you could write the same post and replace all the engineering terms with sales stuff or science stuff.
for example, in biotech, it's not just about tech.
counter argument: product managers that aren't technical are just product marketers
counter argument: product managers that aren't technical are just product marketers
[deleted]
Very HN article. The only job that matter in an organization is developers, product managers are useless, marketing is when you don't have a product, sales people are liars, Support people prevent developers to know the problems and so on.
It's cool sometime to have developers with a product mindset, because they understand better the value they are bringing and can help brainstorming. But first if you had only product-mindset people everyone would want to ship different features and nothing would be shipped. And also the more time developers spend understanding customers the less time they spend coding.
I should probably write a satirical article arguing that "Coding should not be left to developers as product managers should code things much closer from their plan"
It's cool sometime to have developers with a product mindset, because they understand better the value they are bringing and can help brainstorming. But first if you had only product-mindset people everyone would want to ship different features and nothing would be shipped. And also the more time developers spend understanding customers the less time they spend coding.
I should probably write a satirical article arguing that "Coding should not be left to developers as product managers should code things much closer from their plan"
I don't think the article is saying what you're describing at all, or at least, if it is then I missed it.
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.
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.
Well here is the conclusion of the post
> Simply put, instead of expecting someone (e.g., product managers) to tell you which product features to develop, you should be able to tell what are the most critical problems your users or product are facing and find the best solutions that fit into your product and engineering strategy.
> Simply put, instead of expecting someone (e.g., product managers) to tell you which product features to develop, you should be able to tell what are the most critical problems your users or product are facing and find the best solutions that fit into your product and engineering strategy.
Sure, that seems pretty reasonable to me. Features themselves are broadly a software concern - software developers are in the unique position of being able to say what their code is capable of, and so it makes sense for them to be proposing features as solutions to the problems identified by other parts of the business. That's not to say that the development team should never accept feature suggestions from other places - when a user is very clear that they need a particular button, or the business team clear that they need a particular feature to compete in the market, then sure, that also makes sense. But I think the danger in software teams is less often that they only develop what they want, and more often that they only develop what they've been told to develop, and don't connect the dots.
As an example, I worked on internal software for a manufacturing company, and they wanted various alerts to stop manufacturing in certain events. Meanwhile there was a communication tool being developed so that the manufacturing side of the business could talk more easily directly to sales. It was only from the development side that we were able to see how connected these two components actually were, and we ended up proposing a system where the alerts - which were almost always created by the sales/service team - would be built in to the messaging system. This made the whole thing much simpler for us to develop, but also simpler for the manufacturing and sales teams to use - rather than scattering features across the whole app, they lived in one place and worked more consistently.
As I understood it, the point of the article is to say that developers should be trying to understand the world outside of their specific domain so that they can make those sorts of connections. Not because they're going to more right than anyone else, but because a team member that understands what's going on in the rest of the team will work better with the rest of the team.
As an example, I worked on internal software for a manufacturing company, and they wanted various alerts to stop manufacturing in certain events. Meanwhile there was a communication tool being developed so that the manufacturing side of the business could talk more easily directly to sales. It was only from the development side that we were able to see how connected these two components actually were, and we ended up proposing a system where the alerts - which were almost always created by the sales/service team - would be built in to the messaging system. This made the whole thing much simpler for us to develop, but also simpler for the manufacturing and sales teams to use - rather than scattering features across the whole app, they lived in one place and worked more consistently.
As I understood it, the point of the article is to say that developers should be trying to understand the world outside of their specific domain so that they can make those sorts of connections. Not because they're going to more right than anyone else, but because a team member that understands what's going on in the rest of the team will work better with the rest of the team.
I don't care if you view that line of thinking as something worse satirizing. Companies who treat developers as kings and get out of their ways produce amazing products, content, and experiences. Valve is my favorite example of this. More companies should strive to be like them.
I don’t think treating devs as kings is necessary or sufficient for great products. But treating developers well does help. Micromanaged developers will produce great KPIs (close an unfixed bug to stay on target for # JIRA tickets whose status got changed) but not a great product.
I agree with your sentiment about the pros/cons of developers having product mindset.
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.
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.
You're not seeing the bigger picture. Within developers, you have the 10x developers. But within that, there is the 100x developer... all of a company's success can be attributed to a 500kg neckbeard in the basement powered by a caffeine-adderall intravenous drip (for playing video games, all the actual work is outsourced to that one guy in Afghanistan => https://www.theonion.com/more-american-workers-outsourcing-o...)
Every board meeting now probably whittles down to complaints about the CEO's erratic behavior and then a review of earnings.
The world has gone into survival mode and that creates the worst kinds of people and products... Many of these companies running on profit auto pilot will fail, and that may be the best thing to happen because they really stopped doing the good they were created for in bids to attract and codify investors.
They'll hopefully be replaced by better companies that bring back innovation. We really haven't been innovating game-changing IT for years now in my opinion, I think that disruption will only happen when these legacy companies get accountable product owners that know what they are doing and when they stop looking primarily and only at the wrong (ROI) cues for product development.
The world has gone into survival mode and that creates the worst kinds of people and products... Many of these companies running on profit auto pilot will fail, and that may be the best thing to happen because they really stopped doing the good they were created for in bids to attract and codify investors.
They'll hopefully be replaced by better companies that bring back innovation. We really haven't been innovating game-changing IT for years now in my opinion, I think that disruption will only happen when these legacy companies get accountable product owners that know what they are doing and when they stop looking primarily and only at the wrong (ROI) cues for product development.
There should be a good amount of crossover, but having "specialists" who "own" aspects of a software project has been found, over and over again, to be the most effective way of managing a software team.
Two roles that do not fit into one person's brain are Product Manager and Software Engineer. Should a Software Engineer be knowledgeable about what the Product Manager is doing? Yes. Should the Product Manager be knowledgeable about what the Software Engineer is doing? Yes. Should those roles be merged? Absolutely not.
Product ownership should be left to the Product Managers. Product vision, purpose, and strategy should be available to everyone, and everyone should have a say, but to think that Software Engineers should also do Product Management is ignoring how much work both jobs entail.
I write all of this having actually read the article, and knowing the article doesn't actually say anything I'm disagreeing with here, but I feel it's important enough to say these things anyway.
Software Engineers are in those roles not because they cannot do other roles, but because someone needs to write the software, and writing software is a hard enough job that it's more or less the only thing a Software Engineer should need to focus on. I think people forget that sometimes.