8 ms·

> At the end of it, they were sketching a completely different architecture without my "PMing". Because they finally understood who was actually using our produ

> At the end of it, they were sketching a completely different architecture without my "PMing". Because they finally understood who was actually using our product. I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/actionable at turning customer needs into working solutions.”

coffeebeqn 1y ago
This story is so close to Office Space I just can’t be sure if this is real life anymore https://youtu.be/m4OvQIGDg4I?si=0wLjJArlXXql33vS https://youtu.be/m4OvQIGDg4I?si=0wLjJArlXXql33vS
HPsquared 1y ago
Many such cases of employees adding negative value.
sc68cal 1y ago
-10x employees DO exist!
barbazoo 1y ago
Agree, also the whole thing reads kinda fake in the first place.
vkou 1y ago
This is the first thing that struck me. Why does the OP still have a job if a line engineer can do it better? Promote the guy to CTO, and fire the useless chumps who were collecting a paycheck spinning their wheels.
- antonymoose 1y ago
  Because he has people skills, damnit! He clearly adds value, he has his secretary take down requirements from the customer and then he personally walks them down the hall to the engineers. Not sure why you’re not getting this? /s
  - LargeWu 1y ago
    I know you're kidding, but the TPM I work with is basically a stenographer. If we ask him "why" on a requirement, 60% chance the answer is "I don't know, but the customer wants it"
maerF0x0 1y ago
You're assuming they have Product Managers at all. Or that they're not massively oversubscribed.
- margalabargala 1y ago
  The person who wrote the original post self-described as acting as a product manager.
bnug 1y ago
That could be the case, but I work in a mechanical engineering group as the only person on the team who can write code or automate things with it. We're in a large corporation with a sizeable IT support group that builds a decent chunk of the software in-house, and our team views much of it as terrible. So, I've rewritten applications or supplemented the "terrible" but irreplaceable software with tools to make our jobs much easier. I don't think that I'm better than our in-house IT folks at software development but that my perspective as an actual end-user gives me a much better idea of how to meet our own needs. I'm also highly motivated to make it effective, since I'll be using it. So, the title initially resonated with me and didn't see this comment coming. That said, I'm sure your point is valid in many cases as I'm not familiar with formal software development / project management.
- sharpy 1y ago
  100% agree with this take. I work in observability space. We use our own product to monitor our services, and being a daily user of the product helps us make it better. Our customers also agree. We get opportunity to talk to our customers doing product demos at conferences, etc, and all the feedback I have gotten is that they love the product! But wish it was cheaper.
  - hobs 1y ago
    How to say datadog with more words.
    - sunrunner 1y ago
      That might explain why the UI seems to change every other week
- hvb2 1y ago
  There's 2 ways you can get to working software 1. Professional software engineers that can listen to learn about the problem space and are willing to come to understand that. This takes humility. 2. The people experiencing the problem. They might not write perfect code and it might not be maintainable long term. But their understanding of the problem and pain points is so good that they can solve just that and not write 90% of the code the professionals wrote... I've seen this over and over again and can only tip my hat to the people that fixed their own problem. Just like for a dev, that means going into an unfamiliar domain and teaching yourself
dkiebd 1y ago
Well--well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?
tekla 1y ago
Good. All Engineers should deal with the clients directly.
PaulRobinson 1y ago
Most engineers turn up at meetings with product managers with two major problems: 1. They assume they know more than everyone else. Got a guy who has had a problem for 5 years and tried 20 different solutions? The engineers will spend 10 minutes thinking about it, come up with a solution (that won't work, but they insist it will) and dismiss the problem as "trivial", and think the guy is an idiot. I've done it myself (which I'm embarrassed to admit), and I've seen it at every level from junior to Staff/Principal in companies large and small. The lack of modesty in software engineering teams is perhaps my #1 peeve with the industry. As a result, they often end up designing terrible solutions. 2. Once they understand a problem and a solution, they are frequently awful at thinking through the solution from the user perspective unless they themselves have experienced the problem. This isn't unusual, it's hard to build detailed empathy for how something should work unless you try it yourself. It can be very challenging to get buy-in for a UX or a UI from engineers without it, so sometimes it's useful to get them sat in the chair trying to do the work themselves. I'm a TPM (former engineer and engineering manager), who has to regularly wear the "product manager" hat. I can not understate how hard it is to get engineers to read a scope document, understand it, accept that the thing needs to be built, that it needs to be built a certain way from a functional perspective, and while they have free reign on architecture and how it's built, it is not their job to rip each detail to shreds assuming the users, PMs and everyone else involved up to that point isn't a completely brainless moron. This solution is relatively elegant. He got them to talk to users about the software they built and made them realise they were focusing on the wrong details. That's good. It doesn't mean the engineers can become product managers though. You still need the PM to own the product long-term, and to deal with the customer relationships as the thing gets built. I will also guarantee that those engineers proposed changes the PM had to push back on because of constraints outside of the engineering team's heads (legal, compliance, needed by customer X, and so on). Edit: read down into the thread, and this company doesn't have product managers. So he's just hoping engineers can figure it out. Fair enough, the only way to develop that muscle though is to get them in front of customers regularly.
- 9rx 1y ago
  > I can not understate how hard it is to get engineers to read a scope document, ... Ironically, it is hard because it doesn't consider the user. Scope documents likely seem reasonable for the author living in their own little bubble, dismissing it as something "trivial", but if they actually had to use it like those on the receiving end they would soon realize how horrid and ill-conceived it is. Much like was learned in the original link, once you stop with the bad practices, things become much easier.
youngtaff 1y ago
Even in orgs with product managers, engineers can have a really bad habit of wanting to rewrite stuff, or designing things the way they want them to work instead of focusing on customer needs and problems
tossandthrow 1y ago
On the contrary, this pm did provide engineering a valuable lesson, they likely need to repeat every year or so - call it user training, it's a bit like sec training.
perrygeo 1y ago
Yep, notice there was no mention at all about why the original software was so ill-designed in the first place. Not even a curiosity as to why. Your conclusion is more valid, though I wouldn't necessarily place the blame on the PM. Agile/Scrum rituals, where blame is diffused and developers are forced to sprint quickly through poorly-designed tickets, yields poorly-designed software. Who could have guessed? Feels like a systematic problem with the "modern" bloated software organization.
- ryandrake 1y ago
  The root cause I think is that nobody really cares. They're not paid extra to care, either. The PMs are putting checkboxes together and writing reports for their managers without really asking how what they are designing is going to actually be used, the engineers are turning each checkbox into code without wondering if what they are doing makes sense, and the project managers are making sure the train is running on time without regard for where the train is actually going. At the end of the day, the company's stonk goes up, everyone gets paid, and goes home to the family they care about and to do hobbies they actually care about. If any of these characters in the play goes above and beyond to do something wonderful, they aren't getting paid more, the stonks aren't going up higher, and the effort is usually just wasted. I'm not saying this is bad, either, it's just part of why products are so bad.
- deepsun 1y ago
  Part of the task is to push engineers to understand the customer problems and work that way. Sometimes it's hard, when engineers are stubborn (I'm guilty of that too). This PM eventually found the way to push their engs, as described in the article. So I think PM achieved the goal pretty good.
- rstuart4133 1y ago
  > Yep, notice there was no mention at all about why the original software was so ill-designed in the first place. All software is ill designed in the first place. Even software I write to solve my own problems will usually do a poor job of solving that problem on the first iteration. There is a reason old engineers say: "Plan to throw the first one away. You will anyway."
gedy 1y ago
I wonder if LLMs might be replacing these type of PM jobs where they gather up feedback (usually it's mostly in text form anyways), and translate and summarize so engineers can cut out some noise and confusion from PMs.
- deepsun 1y ago
  Ok, LLM translated and summarized. Then what? Someone needs to look at it and push important points. Sometimes it's hard to push engineers, until they visit some calls and push themselves.
  - gedy 1y ago
    Sure, I know there's companies like that, but just as often in my experience engineers are spoon fed tickets without broader context. In many cases are also treated like an interruption if you want to discuss to root issues etc with PMs
- zamadatix 1y ago
  I'd say it's about as likely as LLMs actually replacing the engineers in implementing the code in the next couple of years. I think it's more likely LLMs end up being like every other tech advancement: a way to increase the total amount of stuff being done, but not actually lower the need for people to use them. Or maybe the next thing after LLMs arrives in 2026 and it's actually better than everyone at everything and can feed itself in a loop, but I doubt it.
VladVladikoff 1y ago
I run a small tech startup, about 2M ARR. And at times we’ve been short staffed on support and I’ve sat in for support for a day or two. And every time I do this I discover loads of issues customers are complaining about that don’t seem to ever make it back to our engineering team. Perhaps it’s just our support reps, or the nature of support, but they seem to love to “solve” problems themselves rather than reporting it to engineering for a more permanent fix.
- mschild 1y ago
  I think a mix of both is best. If support can quickly solve a customer issue they should. But they also should make note of it and pass it along.
  - Eddy_Viscosity2 1y ago
    If it was the case the customer support simply knows an undocumented work-around that they can solve the problem and provide that to the customer. I mean that works, but a better solution is for that problem to get back to engineering and be fixed once and for all.
    - hinkley 1y ago
      But after the next release the number of calls per hour the customer support team can answer will drop. Which means no raises for the support people.
      - mschild 1y ago
        Then incentives and (I hate this word) KPIs aren't aligned. That's arguably a somewhat separate problem though.
    - mschild 1y ago
      Yes, fully agree. Like I said: solving a customers problem is top priority but regardless of the solution it should be documented and shared. At minimum it can give pm and engineers insights into common issues and potential improvements.
BurningFrog 1y ago
Perhaps, but being told something very often cannot possibly replace experiencing it yourself.
general1726 1y ago
Or engineers are little bit full of themselves and know better how user should experience the product. If user is "holding the product wrong" it is a problem of a user and not a problem of stupid design, created by a person who knows in which order these buttons should be pressed. People around Desktop Linux could write a complete book about dismissing user's complaints. The moment you have stubborn engineer who knows better than PM and user, it is really difficult to get anywhere. However if you will put such engineer into line of fire from a users that's suddenly not engineer's friendly PM trying to tell the engineer that this is wrong, these are frustrated people who would like to skin engineer alive as a punishment for using his "awesome" creations! That induces fear, but absolutely also crushes his ego, because somebody is berating product of engineer's genius like it would be a retarded hamster. From my perspective, it is not about showing that PM is an idiot, it is about humbling your engineers. Their ego will grow again and this exercise will need to be repeated.
- wordofx 1y ago
  PMs don’t help make good software.
  - hinkley 1y ago
    Don't try to tell them that.
- hvb2 1y ago
  Assuming your PM is for product manager not project manager. I would think the engineers usually get their kick out of making things fast or easy to maintain. If you have a product manager and the customers hate the product, how is that the engineers fault? I've built a couple useless features that I wouldn't want to use and couldn't explain how to use. But if you have a product person, they get to design is BECAUSE they're in the line of fire. That's a comfortable position to be in as an engineer, except that you sometimes have to build things more than once.
  - zamadatix 1y ago
    There are two separate problems, and they aren't mutually exclusive, but this post seems to be specifically about the latter case (if one believes the story, of course): - The PM(s) are bad at listening to customers or turning customer feedback into a focused set of requirements. - The engineer(s) are bad at following the requirements or going back to the PM(s) when the requirements aren't clear. In the first the PM(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product. In the second, the engineer(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product. In either case, it results in the product not fitting the customer needs. I think there are better ways to solve either gap than just having the engineers join sales calls to hope it works out, but I suppose any approach is better than letting the problem sit.
mv4 1y ago
It's one thing to be told (by a PM). It's another thing to believe.
mlinhares 1y ago
That has been my experience in multiple occasions, the moment i can sit with a customer and clearly discuss what their needs are and see them operating the tools, it makes the real user experience and workflow issues much easier to fix. Glad I'm at a place where i can talk directly to people instead of having to go through layers of indirection. I takes away from my engineering time but now i'm always building the right thing, so it is much more productive.
crazygringo 1y ago
Sadly, I've seen a significant number of engineers who simply don't trust what PM's say about what the customers need. They think PM's don't provide value, so they ignore what PM's say. It's only when they hear from customers directly that they go... oh, so these needs are real? I thought it was just PM bullshit. In a healthy workplace this doesn't happen. But sometimes engineers need to talk to customers to trust that the stuff their PM has been telling them is actually true. And then the relationship becomes more collaborative and trusting.
- deleted 1y ago
  [deleted]
hughredline 1y ago
> DevOps engineer is more capable/actionable at turning customer needs into working solutions That’s been my experience all my tears in industry.
- neogodless 1y ago
  I, too, have had many, many tears in this industry.
  - hughredline 1y ago
    ;P An errant autocorrect a little too correct to correct.
supportengineer 1y ago
This should be common knowledge
roadside_picnic 1y ago
Yea, my first thought was "this is how software used to be written before PMs got their hands in everything". I find if you sit engineers down with whoever is doing the operational work, you very frequently find you don't need PMs and everyone is much happier. PMs can be incredible, but my experience is that they tend to be both very territorial and know surprisingly little about either the engineering or the customer side of things.
- estimator7292 1y ago
  Every engineer I've met who isn't a total dick will watch a user handle their product, cringe a lot and then go find ways to change the design to be more layperson-compatible. When I design a UI, it's clearly a programmer's UI. But I try very hard to make things as clear as possible and I'm usually wrong. When I see people struggling to use a tool I made, it means I have failed at design and need to fix it. It's my belief that if you grab a random person off the street and they can't figure out what your product is or how to do even the basics, you have failed to design your product. In 100% of cases, a user should be able to walk up and figure out the basics after a few minutes of poking. If a user needs to check documentation before they can accomplish any task, your design is bad and you should feel bad. If a user needs to inspect every tooltip every time, ten million years dungeon.
cratermoon 1y ago
The chances of user->pm->engineer communication introducing ambiguities or inaccuracies approaches 100%. That's simply human nature and the nature of communication. There's a reason why agile programming has stressed "on site user": the programmers need to hear what the users are saying directly, and the users need rapid feedback on what the programmer thinks vs what the user meant.
roncesvalles 1y ago
Most SWEs are almost certainly better at PMing than the average "career" PM. They just don't want to do it.
franktankbank 1y ago
Yes, fire the PMs should be a meme.
deleted 1y ago
[deleted]
BobbyTables2 1y ago
I’ve worked at companies where the PMs couldn’t talk to customers…
toss1 1y ago
Don't blame it on the PMs (except to the extent they are separating the engineers from the customers). The closer you can get the engineers to the users, the better your product will be, and this goes all the way to the backend and architecture. This is true no matter how skilled and well-intentioned are the PMs or sales reps. I've seen one single layer between the builders and users to help modulate high and constant user demand can help. Beyond that, even two layers can strangle a project. One project my company was doing for IBM was moving along nicely with the developers talking to the actual users every few weeks as progress was made & delivered. I moved off the project, then IBM inserted a manager to "consolidate the communications" (take all the users' input and boil it down), and a manager at my company (not the engineers) talked to him. The project became one of those endless slogs of feature creep, yet no great success — ultimately deployed for some years, but not the resounding improvements in workflow efficiency they hoped and saw in the beginning. Absolutely EVERYONE on both teams was competent and really wanted the project to be a great success. But adding the intervening layers, while it seemed more efficient, had only the opposite effect. Seriously, it ALL happens where the rubber meets the road. Get your developers as close to the end-users' keyboards and screens as possible. Talking directly to the users is great. Even better if you can arrange to have them BE a user for a day or two.
codyb 1y ago
Engineers being completely out of touch with the macro picture of the end user experience is the norm, and it's bad. Engineers work micro features which are sliced out of micro picture epics with maybe a vague Northstar. Sitting engineers with users is a key thing I'm driving at my work since we're on internal tooling. Pretty much to a tee every participant comes out and goes "Wow... I had no idea that's how people were using our product" Building user empathy results in greater connections within our organization, puts names to faces in our support channels, and results in more well rounded engineers who develop software with both technical and end user experience concerns in mind. I mean, there's a reason most software interfaces are still shit, and often physical products too. It's cause we take tons of input from people who haven't extensively thought about user experience a day in their lives
mathattack 1y ago
My experience is every layer between the communicator and the recipient adds noise. It's like the game of telephone we played as kids. Some PMs are terrible and are 100% noise. Even the best are only 50% signal. Give an engineer a clear understanding of the end need, and you have a tremendous gain in efficiency. I think there is a 10X benefit here that's similar to the 10X benefit from stronger engineering skills. You still need PMs, though it's a different job that passing papers back and forth.
TheDudeMan 1y ago
Yes, many PMs suck. And many engineers suck. And communication is always lossy. Having many/all engineers take some calls helps to mitigate those.
calmbonsai 1y ago
Yup. In other words, they have shit PMs.
yen223 1y ago
The first rule of Hacker News comments is it's never the engineer's fault
- lmm 1y ago
  It can be the engineer's fault if it's an engineering mistake. But bad process is the fault of the people who control the process and bad product management is the fault of the people who control the product management.
  - sfn42 1y ago
    As a developer I work closely with my managers and designers etc to ensure that our project goes smoothly and that we create a good product. I don't necessarily decide what we build but I have a lot of ways to influence what we build and how. We talk about stuff, we plan stuff, I chip in and people listen. Whenever I see devs complaining about how terrible their project management is I think to myself that the dev is probably at least partially responsible. Maybe I'm just lucky to have good colleagues, but when I talk about software engineering topics people listen and take it seriously. I think that's a big part of our job as developers, we know the tech and we guide our managers just as they guide us. We're a team, we work together.
    - lmm 1y ago
      In my experience the kind of project management that doesn't value engineering input on technical matters tends to be exactly the kind of project management that doesn't value engineering input on process changes.
      - sfn42 1y ago
        If I started a new job and it became clear to me that my superiors just wanted me to shut up and do what I'm told, I would be looking for a new job immediately.
        1y ago
marc_abonce 1y ago
Yes, even OP admits it in a comment down the thread: > Commenter: Sounds like you have no product managers [...] > OP: haha we don't :) we pride ourselves in not hiring any product folks until after we raised our series A. this helped us stay super lean, move fast, and build exactly what our customers want. our platform is definitely not dead simple. but in the early early days, we did rebuild our product 3 times and the 3rd rewrite scaled us to where we are now
deleted 1y ago
[deleted]
dragonwriter 1y ago
It's too bad we didn't have a major movement in software engineering a couple decades back that recognized that playing telephone through a chain of intermediaries (analysts, PMs, etc.) between customers and engineering was an anti-pattern, and articulated as a major principle that engineering should work directly and regularly with the community that the software is being built for.
hilux 1y ago
The new "product led" trend seems to be that PMs are much more on the implementation side than on the customer-facing business side. E.g. I know this guy leading sold-out Product Management workshops in Silicon Valley, who understands nothing at all about actually taking any product to market, about competition, marketing, etc. ... never mind satisfying actual customers.
Tor3 1y ago
"I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/actionable at turning customer needs into working solutions.” I disagree - there are real limits on how PMs and others can describe how customers feel about products. At my workplace I've always argued for rotating engineers through customer support now and then. As someone who did customer support AND development at the same time, I noticed the wall between developers working in isolation and others who also worked customers. You can work from specifications alone, and they may well be perfect specifications validated by customers, but if you're not actually seeing what they do you can't really understand. Working with customers now and then simply translates to better products and also less maintenance issues, which is _better_ for said developer.
kstenerud 1y ago
I read it as: Most people are bad at empathy because they've never practiced it, and so forcing them into the shoes of another is a good way to give them a kickstart into the realm.
throw310822 1y ago
> the issue was that our PMs are doing a terrible job communicating between customer and engineering That makes it look like it's the PMs' fault. Yet I bet you wouldn't want a car designed by engineers who never drove one and never directly spoke with someone who did, either. It's that simple.

coffeebeqn 1y ago

This story is so close to Office Space I just can’t be sure if this is real life anymore https://youtu.be/m4OvQIGDg4I?si=0wLjJArlXXql33vS https://youtu.be/m4OvQIGDg4I?si=0wLjJArlXXql33vS

HPsquared 1y ago

Many such cases of employees adding negative value.

sc68cal 1y ago

-10x employees DO exist!

barbazoo 1y ago

Agree, also the whole thing reads kinda fake in the first place.

vkou 1y ago

This is the first thing that struck me. Why does the OP still have a job if a line engineer can do it better? Promote the guy to CTO, and fire the useless chumps who were collecting a paycheck spinning their wheels.

antonymoose 1y ago
Because he has people skills, damnit! He clearly adds value, he has his secretary take down requirements from the customer and then he personally walks them down the hall to the engineers. Not sure why you’re not getting this? /s
- LargeWu 1y ago
  I know you're kidding, but the TPM I work with is basically a stenographer. If we ask him "why" on a requirement, 60% chance the answer is "I don't know, but the customer wants it"

maerF0x0 1y ago

You're assuming they have Product Managers at all. Or that they're not massively oversubscribed.

margalabargala 1y ago
The person who wrote the original post self-described as acting as a product manager.

bnug 1y ago

That could be the case, but I work in a mechanical engineering group as the only person on the team who can write code or automate things with it. We're in a large corporation with a sizeable IT support group that builds a decent chunk of the software in-house, and our team views much of it as terrible. So, I've rewritten applications or supplemented the "terrible" but irreplaceable software with tools to make our jobs much easier. I don't think that I'm better than our in-house IT folks at software development but that my perspective as an actual end-user gives me a much better idea of how to meet our own needs. I'm also highly motivated to make it effective, since I'll be using it. So, the title initially resonated with me and didn't see this comment coming. That said, I'm sure your point is valid in many cases as I'm not familiar with formal software development / project management.

sharpy 1y ago
100% agree with this take. I work in observability space. We use our own product to monitor our services, and being a daily user of the product helps us make it better. Our customers also agree. We get opportunity to talk to our customers doing product demos at conferences, etc, and all the feedback I have gotten is that they love the product! But wish it was cheaper.
- hobs 1y ago
  How to say datadog with more words.
  - sunrunner 1y ago
    That might explain why the UI seems to change every other week
hvb2 1y ago
There's 2 ways you can get to working software 1. Professional software engineers that can listen to learn about the problem space and are willing to come to understand that. This takes humility. 2. The people experiencing the problem. They might not write perfect code and it might not be maintainable long term. But their understanding of the problem and pain points is so good that they can solve just that and not write 90% of the code the professionals wrote... I've seen this over and over again and can only tip my hat to the people that fixed their own problem. Just like for a dev, that means going into an unfamiliar domain and teaching yourself

dkiebd 1y ago

Well--well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?

tekla 1y ago

Good. All Engineers should deal with the clients directly.

PaulRobinson 1y ago

Most engineers turn up at meetings with product managers with two major problems: 1. They assume they know more than everyone else. Got a guy who has had a problem for 5 years and tried 20 different solutions? The engineers will spend 10 minutes thinking about it, come up with a solution (that won't work, but they insist it will) and dismiss the problem as "trivial", and think the guy is an idiot. I've done it myself (which I'm embarrassed to admit), and I've seen it at every level from junior to Staff/Principal in companies large and small. The lack of modesty in software engineering teams is perhaps my #1 peeve with the industry. As a result, they often end up designing terrible solutions. 2. Once they understand a problem and a solution, they are frequently awful at thinking through the solution from the user perspective unless they themselves have experienced the problem. This isn't unusual, it's hard to build detailed empathy for how something should work unless you try it yourself. It can be very challenging to get buy-in for a UX or a UI from engineers without it, so sometimes it's useful to get them sat in the chair trying to do the work themselves. I'm a TPM (former engineer and engineering manager), who has to regularly wear the "product manager" hat. I can not understate how hard it is to get engineers to read a scope document, understand it, accept that the thing needs to be built, that it needs to be built a certain way from a functional perspective, and while they have free reign on architecture and how it's built, it is not their job to rip each detail to shreds assuming the users, PMs and everyone else involved up to that point isn't a completely brainless moron. This solution is relatively elegant. He got them to talk to users about the software they built and made them realise they were focusing on the wrong details. That's good. It doesn't mean the engineers can become product managers though. You still need the PM to own the product long-term, and to deal with the customer relationships as the thing gets built. I will also guarantee that those engineers proposed changes the PM had to push back on because of constraints outside of the engineering team's heads (legal, compliance, needed by customer X, and so on). Edit: read down into the thread, and this company doesn't have product managers. So he's just hoping engineers can figure it out. Fair enough, the only way to develop that muscle though is to get them in front of customers regularly.

9rx 1y ago
> I can not understate how hard it is to get engineers to read a scope document, ... Ironically, it is hard because it doesn't consider the user. Scope documents likely seem reasonable for the author living in their own little bubble, dismissing it as something "trivial", but if they actually had to use it like those on the receiving end they would soon realize how horrid and ill-conceived it is. Much like was learned in the original link, once you stop with the bad practices, things become much easier.

youngtaff 1y ago

Even in orgs with product managers, engineers can have a really bad habit of wanting to rewrite stuff, or designing things the way they want them to work instead of focusing on customer needs and problems

tossandthrow 1y ago

On the contrary, this pm did provide engineering a valuable lesson, they likely need to repeat every year or so - call it user training, it's a bit like sec training.

perrygeo 1y ago

Yep, notice there was no mention at all about why the original software was so ill-designed in the first place. Not even a curiosity as to why. Your conclusion is more valid, though I wouldn't necessarily place the blame on the PM. Agile/Scrum rituals, where blame is diffused and developers are forced to sprint quickly through poorly-designed tickets, yields poorly-designed software. Who could have guessed? Feels like a systematic problem with the "modern" bloated software organization.

ryandrake 1y ago
The root cause I think is that nobody really cares. They're not paid extra to care, either. The PMs are putting checkboxes together and writing reports for their managers without really asking how what they are designing is going to actually be used, the engineers are turning each checkbox into code without wondering if what they are doing makes sense, and the project managers are making sure the train is running on time without regard for where the train is actually going. At the end of the day, the company's stonk goes up, everyone gets paid, and goes home to the family they care about and to do hobbies they actually care about. If any of these characters in the play goes above and beyond to do something wonderful, they aren't getting paid more, the stonks aren't going up higher, and the effort is usually just wasted. I'm not saying this is bad, either, it's just part of why products are so bad.
deepsun 1y ago
Part of the task is to push engineers to understand the customer problems and work that way. Sometimes it's hard, when engineers are stubborn (I'm guilty of that too). This PM eventually found the way to push their engs, as described in the article. So I think PM achieved the goal pretty good.
rstuart4133 1y ago
> Yep, notice there was no mention at all about why the original software was so ill-designed in the first place. All software is ill designed in the first place. Even software I write to solve my own problems will usually do a poor job of solving that problem on the first iteration. There is a reason old engineers say: "Plan to throw the first one away. You will anyway."

gedy 1y ago

I wonder if LLMs might be replacing these type of PM jobs where they gather up feedback (usually it's mostly in text form anyways), and translate and summarize so engineers can cut out some noise and confusion from PMs.

deepsun 1y ago
Ok, LLM translated and summarized. Then what? Someone needs to look at it and push important points. Sometimes it's hard to push engineers, until they visit some calls and push themselves.
- gedy 1y ago
  Sure, I know there's companies like that, but just as often in my experience engineers are spoon fed tickets without broader context. In many cases are also treated like an interruption if you want to discuss to root issues etc with PMs
zamadatix 1y ago
I'd say it's about as likely as LLMs actually replacing the engineers in implementing the code in the next couple of years. I think it's more likely LLMs end up being like every other tech advancement: a way to increase the total amount of stuff being done, but not actually lower the need for people to use them. Or maybe the next thing after LLMs arrives in 2026 and it's actually better than everyone at everything and can feed itself in a loop, but I doubt it.

VladVladikoff 1y ago

I run a small tech startup, about 2M ARR. And at times we’ve been short staffed on support and I’ve sat in for support for a day or two. And every time I do this I discover loads of issues customers are complaining about that don’t seem to ever make it back to our engineering team. Perhaps it’s just our support reps, or the nature of support, but they seem to love to “solve” problems themselves rather than reporting it to engineering for a more permanent fix.

mschild 1y ago
I think a mix of both is best. If support can quickly solve a customer issue they should. But they also should make note of it and pass it along.
- Eddy_Viscosity2 1y ago
  If it was the case the customer support simply knows an undocumented work-around that they can solve the problem and provide that to the customer. I mean that works, but a better solution is for that problem to get back to engineering and be fixed once and for all.
  - hinkley 1y ago
    But after the next release the number of calls per hour the customer support team can answer will drop. Which means no raises for the support people.
    - mschild 1y ago
      Then incentives and (I hate this word) KPIs aren't aligned. That's arguably a somewhat separate problem though.
  - mschild 1y ago
    Yes, fully agree. Like I said: solving a customers problem is top priority but regardless of the solution it should be documented and shared. At minimum it can give pm and engineers insights into common issues and potential improvements.

BurningFrog 1y ago

Perhaps, but being told something very often cannot possibly replace experiencing it yourself.

general1726 1y ago

Or engineers are little bit full of themselves and know better how user should experience the product. If user is "holding the product wrong" it is a problem of a user and not a problem of stupid design, created by a person who knows in which order these buttons should be pressed. People around Desktop Linux could write a complete book about dismissing user's complaints. The moment you have stubborn engineer who knows better than PM and user, it is really difficult to get anywhere. However if you will put such engineer into line of fire from a users that's suddenly not engineer's friendly PM trying to tell the engineer that this is wrong, these are frustrated people who would like to skin engineer alive as a punishment for using his "awesome" creations! That induces fear, but absolutely also crushes his ego, because somebody is berating product of engineer's genius like it would be a retarded hamster. From my perspective, it is not about showing that PM is an idiot, it is about humbling your engineers. Their ego will grow again and this exercise will need to be repeated.

wordofx 1y ago
PMs don’t help make good software.
- hinkley 1y ago
  Don't try to tell them that.
hvb2 1y ago
Assuming your PM is for product manager not project manager. I would think the engineers usually get their kick out of making things fast or easy to maintain. If you have a product manager and the customers hate the product, how is that the engineers fault? I've built a couple useless features that I wouldn't want to use and couldn't explain how to use. But if you have a product person, they get to design is BECAUSE they're in the line of fire. That's a comfortable position to be in as an engineer, except that you sometimes have to build things more than once.
- zamadatix 1y ago
  There are two separate problems, and they aren't mutually exclusive, but this post seems to be specifically about the latter case (if one believes the story, of course): - The PM(s) are bad at listening to customers or turning customer feedback into a focused set of requirements. - The engineer(s) are bad at following the requirements or going back to the PM(s) when the requirements aren't clear. In the first the PM(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product. In the second, the engineer(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product. In either case, it results in the product not fitting the customer needs. I think there are better ways to solve either gap than just having the engineers join sales calls to hope it works out, but I suppose any approach is better than letting the problem sit.

mv4 1y ago

It's one thing to be told (by a PM). It's another thing to believe.

mlinhares 1y ago

That has been my experience in multiple occasions, the moment i can sit with a customer and clearly discuss what their needs are and see them operating the tools, it makes the real user experience and workflow issues much easier to fix. Glad I'm at a place where i can talk directly to people instead of having to go through layers of indirection. I takes away from my engineering time but now i'm always building the right thing, so it is much more productive.

crazygringo 1y ago

Sadly, I've seen a significant number of engineers who simply don't trust what PM's say about what the customers need. They think PM's don't provide value, so they ignore what PM's say. It's only when they hear from customers directly that they go... oh, so these needs are real? I thought it was just PM bullshit. In a healthy workplace this doesn't happen. But sometimes engineers need to talk to customers to trust that the stuff their PM has been telling them is actually true. And then the relationship becomes more collaborative and trusting.

deleted 1y ago
[deleted]

hughredline 1y ago

> DevOps engineer is more capable/actionable at turning customer needs into working solutions That’s been my experience all my tears in industry.

neogodless 1y ago
I, too, have had many, many tears in this industry.
- hughredline 1y ago
  ;P An errant autocorrect a little too correct to correct.

supportengineer 1y ago

This should be common knowledge

roadside_picnic 1y ago

Yea, my first thought was "this is how software used to be written before PMs got their hands in everything". I find if you sit engineers down with whoever is doing the operational work, you very frequently find you don't need PMs and everyone is much happier. PMs can be incredible, but my experience is that they tend to be both very territorial and know surprisingly little about either the engineering or the customer side of things.

estimator7292 1y ago
Every engineer I've met who isn't a total dick will watch a user handle their product, cringe a lot and then go find ways to change the design to be more layperson-compatible. When I design a UI, it's clearly a programmer's UI. But I try very hard to make things as clear as possible and I'm usually wrong. When I see people struggling to use a tool I made, it means I have failed at design and need to fix it. It's my belief that if you grab a random person off the street and they can't figure out what your product is or how to do even the basics, you have failed to design your product. In 100% of cases, a user should be able to walk up and figure out the basics after a few minutes of poking. If a user needs to check documentation before they can accomplish any task, your design is bad and you should feel bad. If a user needs to inspect every tooltip every time, ten million years dungeon.

cratermoon 1y ago

The chances of user->pm->engineer communication introducing ambiguities or inaccuracies approaches 100%. That's simply human nature and the nature of communication. There's a reason why agile programming has stressed "on site user": the programmers need to hear what the users are saying directly, and the users need rapid feedback on what the programmer thinks vs what the user meant.

roncesvalles 1y ago

Most SWEs are almost certainly better at PMing than the average "career" PM. They just don't want to do it.

franktankbank 1y ago

Yes, fire the PMs should be a meme.

deleted 1y ago

[deleted]

BobbyTables2 1y ago

I’ve worked at companies where the PMs couldn’t talk to customers…

toss1 1y ago

Don't blame it on the PMs (except to the extent they are separating the engineers from the customers). The closer you can get the engineers to the users, the better your product will be, and this goes all the way to the backend and architecture. This is true no matter how skilled and well-intentioned are the PMs or sales reps. I've seen one single layer between the builders and users to help modulate high and constant user demand can help. Beyond that, even two layers can strangle a project. One project my company was doing for IBM was moving along nicely with the developers talking to the actual users every few weeks as progress was made & delivered. I moved off the project, then IBM inserted a manager to "consolidate the communications" (take all the users' input and boil it down), and a manager at my company (not the engineers) talked to him. The project became one of those endless slogs of feature creep, yet no great success — ultimately deployed for some years, but not the resounding improvements in workflow efficiency they hoped and saw in the beginning. Absolutely EVERYONE on both teams was competent and really wanted the project to be a great success. But adding the intervening layers, while it seemed more efficient, had only the opposite effect. Seriously, it ALL happens where the rubber meets the road. Get your developers as close to the end-users' keyboards and screens as possible. Talking directly to the users is great. Even better if you can arrange to have them BE a user for a day or two.

codyb 1y ago

Engineers being completely out of touch with the macro picture of the end user experience is the norm, and it's bad. Engineers work micro features which are sliced out of micro picture epics with maybe a vague Northstar. Sitting engineers with users is a key thing I'm driving at my work since we're on internal tooling. Pretty much to a tee every participant comes out and goes "Wow... I had no idea that's how people were using our product" Building user empathy results in greater connections within our organization, puts names to faces in our support channels, and results in more well rounded engineers who develop software with both technical and end user experience concerns in mind. I mean, there's a reason most software interfaces are still shit, and often physical products too. It's cause we take tons of input from people who haven't extensively thought about user experience a day in their lives

mathattack 1y ago

My experience is every layer between the communicator and the recipient adds noise. It's like the game of telephone we played as kids. Some PMs are terrible and are 100% noise. Even the best are only 50% signal. Give an engineer a clear understanding of the end need, and you have a tremendous gain in efficiency. I think there is a 10X benefit here that's similar to the 10X benefit from stronger engineering skills. You still need PMs, though it's a different job that passing papers back and forth.

TheDudeMan 1y ago

Yes, many PMs suck. And many engineers suck. And communication is always lossy. Having many/all engineers take some calls helps to mitigate those.

calmbonsai 1y ago

Yup. In other words, they have shit PMs.

yen223 1y ago

The first rule of Hacker News comments is it's never the engineer's fault

lmm 1y ago
It can be the engineer's fault if it's an engineering mistake. But bad process is the fault of the people who control the process and bad product management is the fault of the people who control the product management.
- sfn42 1y ago
  As a developer I work closely with my managers and designers etc to ensure that our project goes smoothly and that we create a good product. I don't necessarily decide what we build but I have a lot of ways to influence what we build and how. We talk about stuff, we plan stuff, I chip in and people listen. Whenever I see devs complaining about how terrible their project management is I think to myself that the dev is probably at least partially responsible. Maybe I'm just lucky to have good colleagues, but when I talk about software engineering topics people listen and take it seriously. I think that's a big part of our job as developers, we know the tech and we guide our managers just as they guide us. We're a team, we work together.
  - lmm 1y ago
    In my experience the kind of project management that doesn't value engineering input on technical matters tends to be exactly the kind of project management that doesn't value engineering input on process changes.
    - sfn42 1y ago
      If I started a new job and it became clear to me that my superiors just wanted me to shut up and do what I'm told, I would be looking for a new job immediately.
      - 1y ago

marc_abonce 1y ago

Yes, even OP admits it in a comment down the thread: > Commenter: Sounds like you have no product managers [...] > OP: haha we don't :) we pride ourselves in not hiring any product folks until after we raised our series A. this helped us stay super lean, move fast, and build exactly what our customers want. our platform is definitely not dead simple. but in the early early days, we did rebuild our product 3 times and the 3rd rewrite scaled us to where we are now

deleted 1y ago

[deleted]

dragonwriter 1y ago

It's too bad we didn't have a major movement in software engineering a couple decades back that recognized that playing telephone through a chain of intermediaries (analysts, PMs, etc.) between customers and engineering was an anti-pattern, and articulated as a major principle that engineering should work directly and regularly with the community that the software is being built for.

hilux 1y ago

The new "product led" trend seems to be that PMs are much more on the implementation side than on the customer-facing business side. E.g. I know this guy leading sold-out Product Management workshops in Silicon Valley, who understands nothing at all about actually taking any product to market, about competition, marketing, etc. ... never mind satisfying actual customers.

Tor3 1y ago

"I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/actionable at turning customer needs into working solutions.” I disagree - there are real limits on how PMs and others can describe how customers feel about products. At my workplace I've always argued for rotating engineers through customer support now and then. As someone who did customer support AND development at the same time, I noticed the wall between developers working in isolation and others who also worked customers. You can work from specifications alone, and they may well be perfect specifications validated by customers, but if you're not actually seeing what they do you can't really understand. Working with customers now and then simply translates to better products and also less maintenance issues, which is _better_ for said developer.

kstenerud 1y ago

I read it as: Most people are bad at empathy because they've never practiced it, and so forcing them into the shoes of another is a good way to give them a kickstart into the realm.

throw310822 1y ago

> the issue was that our PMs are doing a terrible job communicating between customer and engineering That makes it look like it's the PMs' fault. Yet I bet you wouldn't want a car designed by engineers who never drove one and never directly spoke with someone who did, either. It's that simple.