> 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.”
general1726 46 minutes 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.
sillywabbit 18 minutes ago [-]
God forbid an engineer should have an opinion on UI/UX.
ijidak 13 minutes ago [-]
But is it an informed opinion?
Every human has an opinion on practically everything. But has that human put in the effort to justify pushing that specific opinion?
In this case, is the opinionated engineer humble enough to realize that using software in their day to day life does not equal using software in our customer's context?
sillywabbit 8 minutes ago [-]
If I use the product, I'd expect that feedback to get the same weight as any other customer. And not be dismissed because it came from a 'technical' person.
hvb2 38 minutes 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 22 minutes 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.
wordofx 8 minutes ago [-]
PMs don’t help make good software.
bnug 2 hours 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 2 hours 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 1 hours ago [-]
How to say datadog with more words.
hvb2 33 minutes 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
VladVladikoff 1 hours 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 59 minutes 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 53 minutes 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.
ranger_danger 10 minutes ago [-]
> don’t seem to ever make it back to our engineering team
Does support have a procedure for this or is it ever part of any training or meetings? Otherwise I hesitate not to call it a management issue, no offense.
perrygeo 1 hours 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.
deepsun 1 hours 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.
ryandrake 1 hours 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.
tossandthrow 2 hours 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.
HPsquared 2 hours ago [-]
Many such cases of employees adding negative value.
mlinhares 27 minutes 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.
Agree, also the whole thing reads kinda fake in the first place.
crazygringo 17 minutes 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.
sc68cal 2 hours ago [-]
-10x employees DO exist!
BurningFrog 59 minutes ago [-]
Perhaps, but being told something very often cannot possibly replace experiencing it yourself.
vkou 2 hours 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 1 hours 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
PaulRobinson 2 hours 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 1 hours 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.
NamTaf 15 minutes ago [-]
> 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 call this the load-bearing 'just' - as in, 'oh, why don't you just...'
If I catch myself saying or writing that word, I kick myself and think about why I'm doing it. Usually I stop and reapproach my input.
maerF0x0 2 hours ago [-]
You're assuming they have Product Managers at all. Or that they're not massively oversubscribed.
margalabargala 2 hours ago [-]
The person who wrote the original post self-described as acting as a product manager.
mv4 36 minutes ago [-]
It's one thing to be told (by a PM). It's another thing to believe.
gedy 1 hours 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.
zamadatix 8 minutes 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.
deepsun 1 hours 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 20 minutes 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
youngtaff 2 hours 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
tekla 2 hours ago [-]
Good. All Engineers should deal with the clients directly.
dkiebd 2 hours 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?
m463 2 hours ago [-]
All the negative responses.
I have been at countless places where the engineers are out of sync with the product.
And it might be something silly like their coworker added something they didn't know about and the UI is now confusing. Could even be the website started proclaiming something that didn't align well with the product.
Another factor is that the [product -> PM -> bug system -> engineer -> fix -> QA -> product] loop is heavy. It takes a long time and major things get fixed but minor friction doesn't.
having [product <-> engineer] can be amazing.
Engineers might have never encountered the full experience, or may merely be out of sync with how it works today vs last year.
PaulKeeble 1 hours ago [-]
There are myriad of ways to get this wrong and I have seen them all happen:
- force all the communications with the users through Project Managers or Product Owners. Sometimes they are great and sometimes they are terrible.
- The customers refuse to talk to the developers and so they are forced to interpret the users managers requirements without any further input.
- The developers just want to write code and refuse to meet the customer forcing all communication through their product manager or bug tracker.
- I have seen a couple of times where commercial software platforms were used the technology can get in the way, they are limited in the types of modifications and customisations that can be applied and this can make some workflows really awful.
There is always a disconnect somewhere, someone blocking a conversation happening and it can be the customer, a middle man or the developers causing it, often its all three to get a really dysfunctional system or the solution has been chosen before any developers or users really got into the details and its the wrong choice.
There are a lot of ways to make systems that aren't very good for the users.
GabeIsko 1 hours ago [-]
I have been on the other side of this where engineers end up just being a technical support team, and are competed over to directly support accounts, and then there ends up being a plethora of hot fixes and custom solutions per customer. There is a ton of technical debt, because non of this stuff is tested properly and there are regressions all over the place. The whole thing goes under after a competitor, with their properly invested engineering resources makes a better and fully featured product than you.
To me, this screams a real failure of product management. They can't communicate the needs of their customer to their engineers or push back against them? Having engineers take sales calls is not going to scale when you have an actually mature base of customers.
If this product manager really wants Engineers to take sales calls, the Engineers need to earn part of the commission on the accounts. That is the only fair way to do this. I would never take a sales call without part of my compensation being commissions based.
Johnny555 34 minutes ago [-]
My former company used to have engineers sit on sales calls regularly too.
While it was interesting to see what companies wanted and how they were sold our product, it wasn't extremely illuminating.
The features that customers wanted were already on our roadmap, we had one feature that customers found confusing and hard to use, but it was written that way to meet the needs of our largest customer.
Engineering wanted to streamline it but then it wouldn't have met that customer's needs. Eventually we wrote a "lite" version of the feature that was easier to use and turned that on for everyone but the big customer. (but that didn't come about because of engineers sitting on sales calls, we all knew it was hard to use but couldn't change it until it was on our product roadmap.
semitones 3 hours ago [-]
This is an excellent strategy for smaller startups, where every individual contributor needs to have an understanding of the customer's needs, in order to develop an understanding of what kind of product must be built. I have much more success in projects where I deeply understand the product requirements (because I am involved in defining them), than those where the product requirements are "handed" to me and I just have to implement something that satisfies them.
ranger_danger 2 hours ago [-]
Are you saying that you follow directions better because you wrote them... or that you are just ending up with a better UX because of your involvement?
dghlsakjg 2 hours ago [-]
Human communication is incredibly lossy (sometimes intentionally), plus humans will try to fill in gaps with assumed information. The more people you cut out between the message sender and the receiver, the more likely the message is to still be intact.
The kindergarten game of telephone is the perfect demonstration. You only end up with distorted messages if you have many players between the sender and the receiver. If you play telephone with 2 people, you end up with a boring game where any mistakes in communication are immediately resolved.
davorak 2 hours ago [-]
The telephone game is the analogy I use too when explaining the value of having engineers in the custom calls.
Other than mistakes in communication, engineers often know what the hard trade offs are when designing a new feature while sales and PMs do not. They can ask the questions to find out if a customer is on one side of a trade off or the other. Or if a feature is 10x as expensive to implement because the customer needs/wants the benefits on both sides. Finding that out at the start can save a full development cycle of time/effort at times.
dghlsakjg 2 hours ago [-]
> engineers often know what the hard trade offs are when designing a new feature while sales and PMs do not.
I frequently run into the issue of PMs spending more time discussing and trying to slot a feature into the roadmap than it would take to just implement it. Most recently it was with trying to scope out how long it would take to ingest encrypted files. I wrote the feature and had a pull request up before the end of the meeting where they were trying to figure out if we could implement it this quarter or next.
The inverse is when a feature is assumed to be technically easy to implement (just change that setting), and you have to gently explain why that will take a week.
Having people who are technically competent in the meeting often allows a short circuit to getting tot the solution along a pathway that a PM didn't know esited ro was possible through no fault of their own.
jmuguy 16 minutes ago [-]
> The rewrite took 2 weeks. We removed 60% of features. Added a simple progress bar. Built Slack integration for questions. Created "done-for-you" workflows.
> Our support tickets dropped 70%.
If this isn't fake something is extremely wrong with this picture.
Glyptodon 29 minutes ago [-]
IMO this stuff happens frequently because the layers between engineers and users (IE product, project management, executive leadership) are crap and blaming the engineers for it.
Not that engineers can't be problematic. But product people who aren't technical enough and badly manage trade offs they don't understand or invent out of thin air outnumber engineers who are pigheaded know it alls more obsessed with technical minutae than product success.
Another one I see in the same ballpark is hiring a bunch of outsourced coders and then wondering why velocity and quality goes down. (Because you're multiplying the mythical man month effect by the skill difference between a day laborer from Home Depot and someone with significant skills/domain knowledge like a welder or electrician.)
mikewarot 34 minutes ago [-]
When I was just getting started in programming, the best education I got came from the operations manager at a fossil fuel generating station. Russ Reynolds had a quite pragmatic view of computers as tools. Once I had written the system they wanted, he brought someone in from the plant and carefully explained that he was testing the system I built, and not them. He said "anything that goes wrong is his fault" pointing at me. He also told me to just be quiet and watch.
User looks at system, doesn't know what to do... I say oh, just press F1 for help (it was back in the MS-DOS era), Russ says.. "how is he supposed to know that?"
I was then enlightened.
aefalcon83 42 minutes ago [-]
Once upon a time I was doing some custom enhancement for what was probably our largest customer. The CEO and CTO both gave me different descriptions of what the customer wanted. Neither made any sense. I was out of the loop for this whole discussion, but I did get a forward of an email chain at some point that included the customer, so I ended up emailing him directly with stories for those two descriptions plus a third. The customer replied he needed the 3rd story, the one I came up with. This took at least two months to implement, so that was a lot of waste avoided.
The amount of information that gets lost in hand-offs can be incredible. People directly involved in developing the product really need to be more involved with the customers, but I personally have had only bad experiences with organizations enabling this. Those responding here that they get to in some manner, I'm jealous.
elzbardico 1 hours ago [-]
Well. Then you should fire your project owners, product manager and marketing folks, as two things emerge clearly:
1 - Those people were not able either to capture what the customers really wanted, or to translate this into requirements for the developers, or both things at the same time.
2 - Due to the fact that their minds are trained to see things systematically, maybe you should remove all those layers between customers and developers.
swader999 33 minutes ago [-]
My best projects have been where I code side by side with the actual users or subject matter experts. Built a small business loan approval app for a bank, sat right beside the underwriters. Airport billing system, worked one door down from accounting. They came to standup everyday, you take breaks with them, gradually they feel like they own the product.
corysama 12 minutes ago [-]
Ideally, folks would practice mob programming that includes rotating customers into the room in addition to a designer and a product manager. But, so many engineers have had bad experiences with pair programming that they allergically jump to making strawman arguments against even considering mob programming.
Ex: It doesn't require you to be forced into doing it 24/7 for everything. You can still do the vast majority of your work alone in your cave.
pseudocomposer 2 hours ago [-]
At my company, as developers, we rotate taking support tickets and working directly with customers on the issues our (very capable) support team can’t handle. We and our customers are both very happy with the results.
snarf21 1 hours ago [-]
Yeah, this drives value for almost all roles. No need for a separate focus group when you can ask the people who are already using and/or paying for your product.
marssaxman 1 hours ago [-]
I used to love having a job where I had regular interaction with customers. It really made a difference in my ability to improve the features we had, and to design new systems which would be more likely to succeed. I miss that, and I wish more companies found a way to put engineers in contact with actual users: but if you tried to make me do even one sales call, at all, ever, for any reason, that would instantly terminate my interest in working for you.
analog31 2 hours ago [-]
This is a recurring theme in quality control. Let the workers investigate and solve the problem themselves.
notatoad 2 hours ago [-]
we've done this before, either with sales or support calls for the product. customer interaction is good, and can lead to good things. but it also leads to things that are heavily focused on the needs of one customer or one point in time.
most of the stuff i've built as a direct result of customer interaction has been later deleted, as it becomes a maintenance burden with limited utility even for the customers who initially needed it. software should actually be planned, not written in response to somebody's gripes.
> Sounds like you have no product managers or your PMs suck. The platform must also be dead simple if it can be rewritten in two weeks.
And the OP's response:
> 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.
...which then gets called out as pretty much in direct conflict with what came before.
wredcoll 1 hours ago [-]
I don't know if this scales, but I ask for this at every company I work for and none of them agree. It frustrates.
justtinker 2 hours ago [-]
Out come the "this is dumb because .." messages in the redit responses.
I have experiences dozens of projects where the developer had the wrong view of the end use needs for a myriad of reasons (everything after the because). It doesn't matter why in this case just that they found their solution.
The TL;DR message should be make sure the real needs get serviced.
jacquesm 13 minutes ago [-]
Someone apply this to the Microsoft 'teams' team please.
ilc 1 hours ago [-]
As an engineer, there's only one reason I don't want to be on customer calls:
Once a customer knows the person who actually builds the product, they will short cut:
- Customer Service
- Product Management
- Any other sane defenses you put in to protect a developer's time.
And just contact me directly.
Then what do I do to get them off of me without losing a customer?
... That is why engineers don't get on support calls.
If I could be "Anon E. Mouse" for the engagement, that'd be fine. But fact is, that's not what happens.
jacquesm 8 minutes ago [-]
Yes, god forbid that an engineer would be contacted directly to solve a problem they have. The thought alone.
convolvatron 15 minutes ago [-]
personally I think the customers and I both get some value out of our interactions. but I normally don't sit on customer calls. why? because half of the time I screw up the sales aspect by saying
- the salesperson told you what? no, we don't do anything like that
- oh, yeah, this is easy, you don't really need our product, just use X
- yeah, we have vague plans to do that, but no real schedule. its gonna be a major lift
- once we finish coding and testing that, its gonna be great!
IOT_Apprentice 2 hours ago [-]
Have every engineer to install their product at a customer site, this should be able be done remotely and use the product to load key data and update. Have your engineers take support calls.
SpicyLemonZest 2 hours ago [-]
Am I not supposed to notice the transition from "he promised me 5 calls and I guaranteed he'd never have to do it again" to "Every engineer takes 5 sales calls per quarter"? This kind of casual dishonesty makes me question the entire story. I've encountered a lot of people who think they're building a better product when they're really building N customized installs that will never again reconverge.
ranger_danger 2 hours ago [-]
Thankfully the comments agree that OP was the problem all along.
theshrike79 2 hours ago [-]
Dogfooding works
pavel_lishin 2 hours ago [-]
I don't think this is an example of that. This is just engineers being able to talk directly to customers, which is great in most cases. I absolutely loved my jobs where I could directly talk to the users of our products, especially when they came to me with bugs or problems.
Unfortunately, that's not always possible. I wonder if that's why I always liked building tools for "internal" clients, other users within the org - it was trivial to just Slack someone or ask if I could walk over to their desk.
richwater 2 hours ago [-]
All this says to me is that they have no technical product/program management in place to actually do what is described.
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.”
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.
Every human has an opinion on practically everything. But has that human put in the effort to justify pushing that specific opinion?
In this case, is the opinionated engineer humble enough to realize that using software in their day to day life does not equal using software in our customer's context?
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.
- 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.
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
Does support have a procedure for this or is it ever part of any training or meetings? Otherwise I hesitate not to call it a management issue, no offense.
This PM eventually found the way to push their engs, as described in the article. So I think PM achieved the goal pretty good.
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.
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.
Promote the guy to CTO, and fire the useless chumps who were collecting a paycheck spinning their wheels.
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
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.
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.
I call this the load-bearing 'just' - as in, 'oh, why don't you just...'
If I catch myself saying or writing that word, I kick myself and think about why I'm doing it. Usually I stop and reapproach my input.
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.
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.
I have been at countless places where the engineers are out of sync with the product.
And it might be something silly like their coworker added something they didn't know about and the UI is now confusing. Could even be the website started proclaiming something that didn't align well with the product.
Another factor is that the [product -> PM -> bug system -> engineer -> fix -> QA -> product] loop is heavy. It takes a long time and major things get fixed but minor friction doesn't.
having [product <-> engineer] can be amazing.
Engineers might have never encountered the full experience, or may merely be out of sync with how it works today vs last year.
- force all the communications with the users through Project Managers or Product Owners. Sometimes they are great and sometimes they are terrible.
- The customers refuse to talk to the developers and so they are forced to interpret the users managers requirements without any further input.
- The developers just want to write code and refuse to meet the customer forcing all communication through their product manager or bug tracker.
- I have seen a couple of times where commercial software platforms were used the technology can get in the way, they are limited in the types of modifications and customisations that can be applied and this can make some workflows really awful.
There is always a disconnect somewhere, someone blocking a conversation happening and it can be the customer, a middle man or the developers causing it, often its all three to get a really dysfunctional system or the solution has been chosen before any developers or users really got into the details and its the wrong choice.
There are a lot of ways to make systems that aren't very good for the users.
To me, this screams a real failure of product management. They can't communicate the needs of their customer to their engineers or push back against them? Having engineers take sales calls is not going to scale when you have an actually mature base of customers.
If this product manager really wants Engineers to take sales calls, the Engineers need to earn part of the commission on the accounts. That is the only fair way to do this. I would never take a sales call without part of my compensation being commissions based.
While it was interesting to see what companies wanted and how they were sold our product, it wasn't extremely illuminating.
The features that customers wanted were already on our roadmap, we had one feature that customers found confusing and hard to use, but it was written that way to meet the needs of our largest customer.
Engineering wanted to streamline it but then it wouldn't have met that customer's needs. Eventually we wrote a "lite" version of the feature that was easier to use and turned that on for everyone but the big customer. (but that didn't come about because of engineers sitting on sales calls, we all knew it was hard to use but couldn't change it until it was on our product roadmap.
The kindergarten game of telephone is the perfect demonstration. You only end up with distorted messages if you have many players between the sender and the receiver. If you play telephone with 2 people, you end up with a boring game where any mistakes in communication are immediately resolved.
Other than mistakes in communication, engineers often know what the hard trade offs are when designing a new feature while sales and PMs do not. They can ask the questions to find out if a customer is on one side of a trade off or the other. Or if a feature is 10x as expensive to implement because the customer needs/wants the benefits on both sides. Finding that out at the start can save a full development cycle of time/effort at times.
I frequently run into the issue of PMs spending more time discussing and trying to slot a feature into the roadmap than it would take to just implement it. Most recently it was with trying to scope out how long it would take to ingest encrypted files. I wrote the feature and had a pull request up before the end of the meeting where they were trying to figure out if we could implement it this quarter or next.
The inverse is when a feature is assumed to be technically easy to implement (just change that setting), and you have to gently explain why that will take a week.
Having people who are technically competent in the meeting often allows a short circuit to getting tot the solution along a pathway that a PM didn't know esited ro was possible through no fault of their own.
> Our support tickets dropped 70%.
If this isn't fake something is extremely wrong with this picture.
Not that engineers can't be problematic. But product people who aren't technical enough and badly manage trade offs they don't understand or invent out of thin air outnumber engineers who are pigheaded know it alls more obsessed with technical minutae than product success.
Another one I see in the same ballpark is hiring a bunch of outsourced coders and then wondering why velocity and quality goes down. (Because you're multiplying the mythical man month effect by the skill difference between a day laborer from Home Depot and someone with significant skills/domain knowledge like a welder or electrician.)
User looks at system, doesn't know what to do... I say oh, just press F1 for help (it was back in the MS-DOS era), Russ says.. "how is he supposed to know that?"
I was then enlightened.
The amount of information that gets lost in hand-offs can be incredible. People directly involved in developing the product really need to be more involved with the customers, but I personally have had only bad experiences with organizations enabling this. Those responding here that they get to in some manner, I'm jealous.
1 - Those people were not able either to capture what the customers really wanted, or to translate this into requirements for the developers, or both things at the same time.
2 - Due to the fact that their minds are trained to see things systematically, maybe you should remove all those layers between customers and developers.
Ex: It doesn't require you to be forced into doing it 24/7 for everything. You can still do the vast majority of your work alone in your cave.
most of the stuff i've built as a direct result of customer interaction has been later deleted, as it becomes a maintenance burden with limited utility even for the customers who initially needed it. software should actually be planned, not written in response to somebody's gripes.
https://old.reddit.com/r/Entrepreneur/comments/1mw5yfg/force...
> Sounds like you have no product managers or your PMs suck. The platform must also be dead simple if it can be rewritten in two weeks.
And the OP's response:
> 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.
...which then gets called out as pretty much in direct conflict with what came before.
The TL;DR message should be make sure the real needs get serviced.
Once a customer knows the person who actually builds the product, they will short cut:
- Customer Service
- Product Management
- Any other sane defenses you put in to protect a developer's time.
And just contact me directly.
Then what do I do to get them off of me without losing a customer?
... That is why engineers don't get on support calls.
If I could be "Anon E. Mouse" for the engagement, that'd be fine. But fact is, that's not what happens.
Unfortunately, that's not always possible. I wonder if that's why I always liked building tools for "internal" clients, other users within the org - it was trivial to just Slack someone or ask if I could walk over to their desk.