> 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.”
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.
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.
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.
Lots of product managers have never studied product development. You'll find philosophers, designers, physicists, even musicians in the role. Many have great people skills, but little understanding of customer service, building products, or scaling a business. And funnily enough, those are all real careers and degrees.
The result, which you often see in companies with 300+ employees, is that engineers have far more experience building products than their PMs, what engineers usually lack is knowledge of the customer and their pain points, and a roadmap that leads to successful outcomes. In other words: a real product manager.
It's not enough for PMs to throw around cliches like "I represent the customer" or "the product has to be built around customer needs" if they don't understand how to actually build and ship software.
Last year I dug into this and found it's not unusual. Many software companies hire smart people as CPO, Product Director, or Head of Product because they have leadership skills, people skills, and some knowledge of the industry. But most have little to no background in business, marketing, economics, or product development. Some companies go even further and promote an engineer with project management experience to Head of Product. And, of course, people in those roles tend to hire others who look like them, with similar experience. One day their CEO realiseS their product isn't selling, customers aren't happy, or engineers are left to figure out what to build.
To put it in perspective, imagine a company making a lawyer their Engineering Manager and asking them to build an engineering team. What are the chances they'd do better than a computer scientist or an actual engineer? Pretty slim. Sure, there are exceptions, but what usually happens is their engineers aren't motivated and complain about the lack of coaching, vision, purpose, and the poor quality of their tools, processes, code, and work environment.
Bottom line: companies need to audit product leadership roles as a priority and figure out who's really in charge of the product. Run an internal survey to check whether your CPO, Director, Head of Product, and Product Managers have studied business or have actual expertise in it. If not, you're in trouble.
I support every single word of this comment. Good product managers are unicorn masters of discovery and delivery who are so rare that they climb up quickly in corporate hierarchy to strategic positions leaving holes in product operations. I have seen products running A/B tests without understanding how they work, designing UI sketches without any knowledge of UX, pushing features to roadmap based on a feedback of a single user etc. Maybe it makes more sense to abandon this role instead of fixing it and split the required skills between UX designers, business analysts, marketers, engineering and project managers etc.
I think the role of Product Manager should be renamed Customer Manager to avoid confusion and conflicts of interest. Some companies like Airbnb tried switching to Program Manager, but that only adds to the confusion.
Right now, the Product Manager is seen as the CEO's delegate, making sure the product follows business strategy, while the Engineering Manager is the CTO's delegate, making sure the product follows technical strategy. One represents business the other represents technology. But IMO since both are building the product together, the title Product Manager creates competition instead of collaboration.
The software needs the customer just as much as the customer needs the software. That's why I think the roles of Engineering Manager and Customer Manager make more sense, working together to build the best product possible. The product isn't managed by one side, it's managed by both.
However, the real problem isn't the role title, it's the qualifications of the person in the role. Companies don't hire lawyers as Engineering Managers, so why do they hire musicians as Product Managers?
That sounds weird. Product managers do not represent customers interests, they represent business value which is not always in making all customers happy. E.g. conversion optimization brings no added value to customers, so it’s not a great name choice. If the role defined as it us now, „product manager“ is the most appropriate name.
It does sound a bit weird, I have to admit. Customer Experience Manager sounds better or just CX Manager.
For me, the title Product Manager sets the wrong expectation, it makes it sound like they own the product, which clashes with other roles. In reality, they don't own the product, they own alignment: customer needs, business goals, and engineering feasibility.
I've heard many YC founders say that the CEO (or CPO) is the only one who truly owns the product, and I agree. The PM should never own it, they are interpreters who take the CEO's vision, combine it with customer insight, and help the team make the right trade-offs.
The best PMs are like mini-CEOs, and many of them go on to become CPOs. But there's a lot of confusion in the software industry about what the role of a PM should be. For example, I see companies putting too much emphasis on usage metrics, while very few focus on the far more important skill of asking the right questions. PMs look at dashboards to make informed decisions, but most of them aren't even asking the right questions. And they don't know if the questions they're asking are the right ones, because they have no real knowledge of product development, just a bit of experience which is limiting. That's what happens when engineers, designers, or musicians end up in PM roles, reacting to data or using it to validate their own or someone else's assumptions.
The real problem, I believe, starts with companies hiring anyone with people skills as a PM. They don't understand their role and responsibilities, it's common to hear PM say "I own the product." But that's not really true. According to successful founders and CEOs, they are the only ones who truly own the product, and that's an important point for leadership to establish. PMs thinking they own the product creates power struggles with leadership, engineering and design, while a title like "Customer Experience Manager" makes it clear the role is about representing the customer's needs, aligning them with the CEO's vision, and making the right trade-offs.
Business people with knowledge and experience always put the customer at the centre and focus on aligning customer value with business value. In other words, if you're the CEO of Uber and your PM isn't driving a taxi once a week, then, IMO, you hired the wrong person.
> Last year I dug into this and found it's not unusual. Many software companies hire smart people as CPO, Product Director, or Head of Product because they have leadership skills, people skills, and some knowledge of the industry. But most have little to no background in business, marketing, economics, or product development. Some companies go even further and promote an engineer with project management experience to Head of Product.
I was right with you until the last sentence of this. As an engineer-turned-PM who is still very much technical, I can count on one hand the number of technically competent PMs I've known in my life, and have plenty of fingers left over. Having experience developing products can easily be a liability, because while delivering software is important, you're mostly expected to be an advocate for the business, which means that you live in the world of corporate politics and can't be perceived as too in the tank for the tech staff.
What I see is the exact opposite of what you've described: the PM that gets ahead is invariably someone with a background in business or marketing, and the technical background is deemed almost irrelevant. If you spend too much time focusing on technical issues, someone swoops in with the theater of "data-driven decisions" and "rapid iteration" -- you can justify virtually anything by cherry-picking statistics, and it's always possible to criticize the development speed of a team when you don't involve yourself in the details -- the role quickly becomes about spinning a compelling story to upper management.
Basically, a huge percentage of PMs understand little more than the first few chapters of The Lean Startup.
I think the comment you're replying to agrees with you - it makes more sense with the last two quoted sentences swapped. I could be wrong but this interpretation seems consistent with the rest of the comment.
"Many software companies hire smart people as CPO, Product Director, or Head of Product because they have leadership skills, people skills, and some knowledge of the industry. Some companies go even further and promote an engineer with project management experience to Head of Product. But most have little to no background in business, marketing, economics, or product development."
I was saying that many companies already make a mistake by putting unqualified people in senior product roles, and some go even further by making the bigger mistake of promoting an engineer with only project management experience straight to Head of Product.
>> Many have great people skills, but little understanding of customer service, building products, or scaling a business. And funnily enough, those are all real careers and degrees.
Where would people skills rank then in your hierarchy for product managers?
People skills matter for product managers, but they come after customer and product experience, business and product strategy, and execution and delivery. Otherwise you just end up with a nice PM who doesn't know how to move the product forward.
> I would think the engineers usually get their kick out of making things fast or easy to maintain
Is your company hiring? Because I've spent 30 years being this engineer and nearly everyone looks at me like I've got horns growing out of my head.
That's not where most engineers find their job satisfaction, more's the pity. And they think they know better than users. There's a reason UX has been around for at least four decades longer than DX. Developers think both are made up.
If a user holds an ice cream cone upside-down and their ice cream falls to the floor, do you blame the user for not holding their ice cream cone upright or the creator of the ice cream cone for a stupid design that allows the ice cream to so easily fall out of the ice cream holding device and onto the floor?
I find far more often that bad UX is the result of someone trying to use a tool for something it wasn't designed for. They might even clob several different tools together in an unholy abomination to get it to do what they actually want instead of having a tool built to do precisely what they want (and once that tool has been built - people will inevitably misuse it to do things other than what it was designed for and then complain about its poor UX for doing those things).
> If a user holds an ice cream cone upside-down and their ice cream falls to the floor, do you blame the user for not holding their ice cream cone upright or the creator of the ice cream cone for a stupid design that allows the ice cream to so easily fall out of the ice cream holding device and onto the floor?
Playing along with this analogy, what I think we see a lot of in product development is the customer going to the PM and saying they need the cone to have a cover. The PM and the customer iterate over the specifics of the cover. PM goes to the engineer and tells them the cone needs a cover that meets x, y, and z requirements. Engineer, knowing how you're supposed to use the ice cream cone, objects. PM, knowing what the customer needs, insists.
> Engineer, knowing how you're supposed to use the ice cream cone, objects. PM, knowing what the customer needs, insists.
That’s the kicker. They know what the customer _wants_ not what they _need_
The number of times a Jr engineer has asked me “how do I accomplish task X in technology Y, it’s really important!”
I always, always ask “what problem are you trying to solve. Not once in over 15 YoE has the solution been to use X.
A good PM doesn’t say “this is what the customer needs” because most of the time the fucking customer doesn’t actually understand what they need.
The engineer knows that holding the ice cream cone upside down means they’re trying to use the product in a way it was never intended, so they push back.
A good PM would ask “why do you want to hold the ice cream cone upside down, customer?”
“Oh well we don’t actually want to hold it upside down, we just get frustrated that sometimes when we put too much ice cream on/in the cone it falls out. So if you can make the cone hold the ice cream while upside down, the problem is solved!”
“Oh, so what you actually need is a bigger cone that can hold more ice cream?”
“Oh, yeah that would work too”
meme about Spider-Man facepalming, where Spider-Man is the engineer
My point is that by letting the customer define the solution rather than explain the problem, nobody knows they're even trying to hold it upside down. The why of it all is lost in some PM / Engineer power struggle that usually results in ice cream cones having covers (and a happy customer).
> I find far more often that bad UX is the result of someone trying to use a tool for something it wasn't designed for.
Isn't that the point? In the story the engineers weren't designing a tool well-suited for the customers, but for whatever abstract scenarios they had in their head. In the open source world it's more reasonable and common to design a tool not predicated on the predominant models and workflows. And every once in a awhile those experiments result in something very valuable that helps to break predominant paradigms. But in the commercial space solving customer's immediate problems in a manner that is intuitive for them is paramount.
> In the story the engineers weren't designing a tool well-suited for the customers, but for whatever abstract scenarios they had in their head.
A joke exists about how developers will never be displaced by AI because that would require clients and/or project managers to accurately describe what they want the AI to build. On one hand that is extremely egotistical of developers. On the other it is also factual.
To my understanding of the story the developers had designed what was being communicated to them by someone who described what customers asked for and not what the customers actually wanted or needed. Nothing to do with what the engineers thought customers wanted and everything to do with what project managers had expressed to the engineers about what customers wanted. Speaking with the customers directly gave them a better idea of what was actually being asked for. So they built that instead.
My takeaway from the story is to fire the project manager. Not to make devs call clients.
Product and project managers can have similar issues of perspective as engineers, chasing trends in the industry or losing the forest for the trees (feature checklists, etc). But, yeah, having devs talk directly to customers can be problematic. If you give a customer a direct line to an engineer, sometimes they can monopolize the engineer's time (they feel they can leverage an "inside" contact) or skew their priorities. Having engineers work closely with tech support is a good middle ground, such as by fostering 1:1 relationships with support or even fielding tech support tickets themselves (tech support tickets have more finality than, e.g. sales support issues). That way they can get a broader perspective on pain points and potential new directions. It can really help refine a product beyond what can be achieved by lobbing feature and bug tickets over a fence or through formal group meetings (which often can be either too structured or too chaotic).
I have long believed that the biggest issue here is that engineers and power users generally have a much higher “pain threshold” when it comes to poor or complex UI/UX. They are not always the best people to judge how or if less experienced users will tolerate or adapt to those patterns. It’s fine to have opinions but they must be prepared for them to be challenged. Even better if they can invite others to challenge them, which is essentially what talking to your users achieves.
> engineers and power users generally have a much higher “pain threshold” when it comes to poor or complex UI/UX
I don't think that's entirely accurate. We tolerate steep learning curves if the result is an increase to our power. That's why we are power users.
Vim, for example. Some of us put effort into learning it because it's a powerful and efficient editing language that will enable us to easily accomplish hard things.
Caring about the system itself and being willing to put effort into it are what separates power users from normal users. We don't do this because of masochism, we do it because we want to increase our power.
Normal users want the system to just do what they want without any thinking or effort at all, as though it was a highly specialized tool for their exact task rather than a powerful programmable general purpose computer.
Personally I don't care at all about how "less experienced users will tolerate or adapt". This unceasing focus on the wants and needs of normal users frequently hinders us. Developers typically reduce the complexity and feature set of a piece of software in order to turn it into something a normal user can deal with. We want more power, not less.
Normal users don't really matter unless they are directly paying our salary. We should all favor ourselves unless we're getting paid to focus on someone else.
The two biggest causes of major UI problems I see are:
1) Exactly what you wrote: power users don’t even realize they clicked through five things in ten seconds any one of which would have derailed a weaker user, because they’re so used to bad UI that it’s almost invisible to them.
2) Zero care given to what’s most natural for the platform, for cost of development & maintenance, or what’s easiest for the user, when (bad) designers and (bad) “product folks” get involved and are way too into the wrong kinds of “consistency”, especially brand and cross-platform consistency (yo, I’m not sure it’s worth spending extra money fucking up contrast and platform norms on your inputs so your fucking radio buttons are “on brand” or whatever, like, I’m deeply skeptical of the actual business value of that kind of thing, though I can see the PowerPoint presentation value… and that’s why it happens)
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?
Ultimately, you need to decide who your target user is. Do you want to cater to the lowest common denominator, or do you want to want to make something power users can customize to fit their workflow?
Neither answer is necessarily wrong, you just need to make a choice.
This fallacy is at the heart of the failure of modern software.
Making things work for the median user is almost entirely about defaults and intuitiveness. If everybody is sending messages all the time, there should be a conspicuous button for sending messages.
Making things work for power users is about allowing those defaults to be changed. It's fine if this is five deep in a menu somewhere. It's fine if there is an option for "advanced mode" that opens up a bunch of menus that are otherwise hidden. It's fine if this requires you to write your own filter rules etc., as long as that's available. What's not fine is to make the limited interface the only interface.
Simple things should be easy and complex things should be possible.
> Simple things should be easy and complex things should be possible.
I love this.
Building on this thought: When you are starting to build something, you have very limited resources. Focus only on making simple things easy and forget everything else. Once you have product market fit expand into making complex things possible. This applies to 90% of all products.
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.
The issue is that software engineers most often strike a balance between passive aggressive and overly opinionated... Its a shit mix if you ask me- very frustrating personality to work with.
Isn't that the same as UI/UX people being generally clueless about how to build applications for the very platform for which they are designing? Designers and product managers constantly have to be guided about the logical and the structural constraints of their target platforms, to be given workarounds, to be taught how to logically divide their reusable components so that they can build their dream design system which, by the way, always fights the platform's native design system.
It's totally fine to have an opinion on UI/UX if it is informed by cognitive psychology and other relevant HCI subfields, in the same way that it's OK for UI/UX to push for designs so long as they are also informed by business and engineering.
> People around Desktop Linux could write a complete book about dismissing user's complaints.
On Linux we enjoy flexible systems that empower us to change the things we don't like all by ourselves without any need to involve any "project managers" at all.
And it's completely fine if Linux systems are built around the needs of programmers and power users. It's not like normal users are paying us. Linux users should focus exclusively on themselves and their own needs.
While PMs have their own share of quirks to work around with and your comment doesn't say they have no faults at all, I wholeheartedly agree with you here. I've worked as a developer, QA, systems operator, and a bunch of other positions. Holy cow, we are all full of ourselves (PMs included), but the disdain of a lot of developers towards the end user (sometimes PMs fault) is incredible. A bunch of nerds ignoring common people use cases and abilities. And it keeps happening and most still don't recognize what's happening.
I've worked as a Manager so I've had to deal (and collaborate) with this kind of misunderstanding, but it truly gets tiring when developers complain about users trying dumb things (for developers) over and over again, yet they themselves have learned nothing from previous encounters with this phenomenon and complain instead about stupid users (or PM, or company, or whatever).
I kind of think this is correct but not for the reason you think. To most engineers, users are the annoying thing on the other end of a ticket. They “don’t know how to use the product properly”.
I’ve also had great success dropping engineers directly in front of customers. I think it’s just because it humanizes the person behind the ticket
I think you're right. Similar to the article's title, a useful thing is dogfooding. But where this can go wrong is because conversation is engineer to engineer (not exclusively) is that the takeaway can be "Oh, I was holding it wrong" instead of "this was not as intuitive as I thought, how can I fix that?" I know there's backend vs frontend arguments[0] but I think backend needs to be conscious about front end. When we write backend it is easy to just focus on making things work but we're a few steps back from typical (or targeted) use cases.
Classic problem with us eningeering types, right? When you're in the weeds it is easy to see the differences. Humans are always biased to forget how difficult it was to learn something, judging on level of current (subjective) difficulty. For me a big change in framing came through Linux. I'd convince my friends to use it and then as the years went by I saw how much easier it became to do so. Now, for the most part it is much easier for an average person to use. There difference isn't "holding it wrong" so much as "it's hard to hold" (or "it's hard/unintuitive to hold correctly"). Even just with the more recent rise of TUIs. Even us terminally terminal types are loving the new TUIs and ultimately that is a frontend thing. It's just frontend for backenders, allowing us to stay in the environments we are efficient in, maintain our power and flexibility, but also get some aesthetics (which has functional utility! I bet you use syntax highlighting, and not just because it is pretty).
There's a strategy to writing backends that I think helps both backend and frontend: write flexible code. It draws from the unix philosophy, where functions (or small programs) should be containerized or focused. Then the complexity happens by putting the things together (there's a hierarchy to this). Helps write backend code so it is easier to maintain, reduces repetition, allows for quicker feature development, and ultimately makes it far easier to read. It's a little more work up front, but it sure pays dividends. It helps front end people because ultimately they are towards the... *front end* of that hierarchy. Makes it easier for them to pull pieces together, wrap things, and communicate with backend types.
Honestly, I think the biggest roadblock to this strategy is the constant push for rushing. Why is there always time to do things twice but never enough time to do things right? It all depends if we're running a sprint or a marathon. A sprint is all about speed, but a marathon requires a lot of strategizing. A marathon requires some sprinting, but you can't sprint the entire thing. We like to drop sayings like "don't let perfection be the enemy of good" but truth is it's not about perfection, it is about different ideas of what is "good enough." Which, is ultimately an issue of communication.
[0] I'll still argue backend is more important ;) because that's the foundation. Your building can't stand, let alone be pretty, if it doesn't have a solid foundation and skeleton. All that is invisible though. Maybe that's why these arguments occur.
> Honestly, I think the biggest roadblock to this strategy is the constant push for rushing.
ironically, giving more time upfront can make things faster because people now have time to make a proper implementation, so you have less rework/qa cycles...
I don't think it is ironic, but makes perfect sense. It's about the marathon strategy.
I think another important part of "running a marathon" is having excess time. It is hard to predict disaster, but you can prepare for it. You don't want the exact number of lifeboats so that each passenger on the ship has a seat on a lifeboat. You need excess because in a disaster it is likely a lifeboat will fail. The lucky thing with time is that if you finish ahead of schedule you can just go onto the next thing. It's always better to finish ahead of schedule than behind. But if you always predict to be on schedule you're more likely to fall behind because there's more ways to fall behind than get ahead.
> It is hard to predict disaster, but you can prepare for it.
yes, you need slack to deal with inevitable surprises and delays that will occur so that you can actually make it 'in time'
> But if you always predict to be on schedule you're more likely to fall behind because there's more ways to fall behind than get ahead.
this is counterintuitive for a lot of people and especially for managers under pressure from above
running without slack means every bump in the road adds a delay which makes the manager's troubles even worse when they have to report the inevitable delay (which leads to a negative spiral of rush-and-delay)
> running without slack means every bump in the road
I think you ran into maybe a good analogy here (spitballing). To go fast on a bumpy road you need slack, in your shocks. You have to absorb those bumps. But if you have no shocks you just rattle apart.
Sure, a rally car isn't as fast as nascar, but which environment are you in? Super smooth road with only left turns and is built to allow you to go as fast as possible? Or literally anything else.
> You have to absorb those bumps. But if you have no shocks you just rattle apart.
yes, and the real issue is, there are no smooth roads (ime anyways)
> Super smooth road with only left turns and is built to allow you to go as fast as possible?
whats interesting is, from a high-level perspective, riding with shocks (slack) can feel more like nascar than rally even if the day-to-day has bumps.
and of course, aside from slack, there are other things that help get to "nascar" such as good specs, good/easy architecture, low-interruption/async communication, and good management, but even then its just reducing the likelihood of bumps...
This story of whittling down the product to meet the needs of the user as grepped from several sales calls assumes that a small sample is statistically representative (and it’s not) and assumes simplification always makes for a better product (and it doesn’t).
When I ask 15 users for their input, only 3 will speak up, and their needs and views don’t fully overlap.
Photoshop is a great example of a product that was extremely complicated and difficult to use but dominated the market for many years.
Microsoft has continually made updates to its products over the years, making it basically do the same thing but with unnecessary and frustrating changes, and people keep buying it.
Yes, UX is important, and A/B or similar evolutionary testing is important. Yes, devs tend to overcomplicate things. But, there’s no magic simplification bullet.
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.
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.
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
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.
Person3: "it's always something I have to work around"
Person4: "I work for <company> as a customer support outreach social media community engagement executive. Can you go and jump through hoops and open a support case?"
Not raising it internally, not getting anything changed or fixed; suggesting the customer do more work to tell the company about the problem. A person who works for the company and is paid to read social media and has read the complaints, is not only apparently ignoring them but annoying the customers as well.
Alternate Person4: "<sigh> I work for <company> as a technical employee and we've been begging to get this fixed for years. As a workaround you can <xyz>. Email me directly if you need more help, and if we get a patch to fix ever, I'll let you know".
You can never rely on support reps to escalate UX issues to product teams for a couple reasons.
First, from their perspective if they are able to solve an issue by following their script, even if it took 20 convoluted steps, everything is working normally. People are used to occasionally dealing with workarounds so it's not a big deal in their mind.
Second, it's not in their interest to report UX issues. They are measured by the number of tickets they close, so the issue that gets a lot of inbound support and they know an easy workaround for is nicely boosting their numbers. Eventually these things get fixed by product and they move on to doing the same thing with other tickets.
Perverse incentives. They are judged by how long the call takes, and every time they escalate a common problem that the devs could fix, now their numbers will go down and they'll get punished for their good work.
Dell at one point pulled the plug on outsourcing their tech support. They spotted this moral hazard partway through the process and decided it was better to keep it in house.
On the opposite side of moral hazard, early in my career I worked for a large web security company in tech support. We were not permitted to escalate to engineering at all. Often this meant the only solution was to apply our own, unofficial code changes!
At my last job I worked in professional services, and after reporting multiple issues over and over and over through the normal process I finally wormed my way into a friendship with engineering and product leadership. A conversation with someone they trust was THE ONLY WAY to get them to take seriously a Jira report from the field saying "this is annoying/broken at every customer. Yes there is a workaround, but can we get it fixed?"
Product at every company I've worked for only ever cared about prioritizing shiny new features or bugs that have people screaming at them.
speaking as someone who clawed their way up out of the support mud...
sometimes it's a lack of accessible escalation procedure (no, a bug report is not the same thing as "this feature sucks to use and needs to be revisited), and sometimes it's just the unfortunate fact that those support reps most capable of clearly explaining these issues (or better yet, understanding the underlying mechanisms that cause the issues) get promoted out of front-line support roles (hi)... or move on because they're not satisfied with remaining in support (hi).
obviously there are a ton of exceptions to this rule but i've personally covered just about all those bases throughout my career. i would have loved to have seen engineers get involved with the burden of support, but maybe that's just because i came out of dysfunctional shops... not that they're not all dysfunctional in one way or another.
I think this is pretty much it: everyone capable of doing quality support has the skills to double or triple their salary by doing something more interesting (usually dev or sysops).
The way I've typically solved this is by keeping an eye on the support inbox myself. It takes just a few minutes every day and I've caught some pretty low-hanging fruit with this that really does make the product better. Sometimes it's as simple as just adding a permalink somewhere.
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.
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.
> 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.
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.
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.
> 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."
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.
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.
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.
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"
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.
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.
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.
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.
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.
"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.
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.
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
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
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.
> 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.
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.
> 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.
> 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.
For my scope documents I spend hours questioning users and validating each step and asking “why don’t you just…?”, and try and boil that down.
Doesn’t matter if you drive VS Code every day though, because that means You Know Better (tm), and to hell with the discovery process.
I actually wouldn’t have a problem with pulling engineers into those discovery exercises directly, except when I have, they’ve just refused to engage. Come out without asking many questions and seemingly haven’t listened to a thing.
It’s like engineers just think it’s all beneath them, (and I accept I was a bit like that when I was engineering), so forcing them to do the calls isn’t an awful idea.
> I actually wouldn’t have a problem with pulling engineers into those discovery exercises directly, except when I have, they’ve just refused to engage.
I know not everything comes across in a short HN comment, but that truly sounds like a "Why don't you just...?" solution. What does the user of your work actually need?
> It’s like engineers just think it’s all beneath them
Well, are they wrong? You seem to recognize — and I wholeheartedly agree — that when an engineer throws a "I just did..." solution in front a customer and the customer finds it to beneath them to use, it is the engineer who has failed. The customer is completely justified in pushing back on something that isn't right. They shouldn't have to accept slop just because that's what you delivered. But it seems you aren't willing to hold yourself to the same standard?
> The engineers will spend 10 minutes thinking about it, come up with a solution
This is fine if coupled with a dose of humility. Coming up with obvious solutions then researching why they don't work (or asking an expert) is a good way to understand the domain.
> (that won't work, but they insist it will) and dismiss the problem as "trivial", and think the guy is an idiot
This is obviously bad, but engineers often have imperfect people skills. I like to think they're aiming for the first but accidentally end up doing the second.
> it is not their job to rip each detail to shreds
It is an engineer's job to ask questions during planning when they're confused. This feels like it might be bad people skills again, because "ask questions" and "rip each detail to shreds" are in the same direction.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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?
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.
> I have been at countless places where the engineers are out of sync with the product.
Me too, but surprisingly it happens more often at places with the most Product Managers.
My worst experience was at a company that tried to enforce a specific ratio of Product Managers and "Product Designers" to engineers. If you added up the designers, product, project, and program people the total was higher than the number of engineers.
It only made everything worse. Fighting your way through the Product Management bureaucracy while trying to avoid having one of the PMs view your input as a threat was a job in itself.
Great Product Managers are invaluable additions to a company. The modern version of Product Management has attracted a lot of people who thrive on bureaucracy and process. The proliferation of Product Management influencers has made it much worse.
100%, my current team could benefit from a strong technical PM, but the risk of negative impact from a poor PM - and the 10:1 ratio you see of bad-to-good PMs in the wild - has me pushing back against hiring one. The risk isn't worth the reward.
you're not wrong, but i don't think forcing engineers to take sales calls is the right move either. there's lots of soft skills involved in running a successful call that engineers aren't trained or even interviewed on.
(i'm definining "sales calls" as the initial discovery call before a demo or proof of concept is agreed upon. i would be okay with having engineers _ride along_ for complex presales demos, but even then, product should really be serving that role.)
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.
Yeah I think having engineers understand product is important as I think it's the harder to get right than the basic engineering. Most of the products I've worked on have failed for product reasons so just from a logical standpoint it makes sense to focus on making sure that's a strength for a team.
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.
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.
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?
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.
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.
> 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.
> 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.
Reddit has become an outlet for creative writing. This might have been inspired by some real life events, or it might have been pure fiction. Either way the end result is dripping with the typical Reddit creative writing elements, with a dash of LinkedIn style business storytelling.
They say they have a certain job, work for a certain company, or know how to do a certain task; and they get the terminology completely wrong, or make up stuff that is obvious to someone who actually knows, but sounds good to people who don't know.
There's just something about the specifics that seems really odd to me. "60% of features"... really? Sixty percent, specifically? Like I think this story is maybe based on some series of events at a SaaS and I agree with you in principle but it seems like the author ran it through a Linkedin thought leader LLM.
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.
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.
> Because they finally understood who was actually using our product.
Yes!!!
> The biggest problem with most engineers is actually over-engineering.
Err, wait, go back to step 1. Over-engineering is sometimes a byproduct of not understanding the customer use cases. That lack of understanding is the biggest problem.
So, I’m an “engineer” —- my most common frustration with other engineers is their lack of interest in understanding of the actual product being sold. In my experience, sometimes the reason is job-fit issues, sometimes it’s ego, but usually it’s a combination of culture and incentive.
I worked at a place that made a robo-calling sales crm and they thought it would be great if during an offsite they had everyone use it to cold call places and run through some script they'd prepared. They didn't seem to understand nor care about what sort of anxiety that could cause not-sales-people. That's when I decided to start looking for another job.
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.
"does anyone use this?" is a running joke where I work because we always say yes to a feature request, most of them get used briefly by one customer, then we have to maintain/test forever just in case
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.
Sales engineers should be the spirit animals of PMs/SDEs.
They often are having to integrate the company's software with the whole stack of the customer.
They experience the pain of real world setup/optimization/bugs more than anyone else in the company.
They generally are savvy to the challenges of actual software engineering and what is realistic to get done in a given time frame.
They are usually technically articulate enough to frame the challenges in an understandable way for SDEs.
They are driven to improve the customer experience because it also makes their lives better, vs the sales guy looking for ways to just close a sale for commission.
They are very aware of what the competition is coming into bake offs with as far as features and support.
They can let you know what bugs and missing features are costing the company the most money and customer sat.
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.)
I've seen something like this before. A monitoring team said that front-line engineers should be opening tickets for every alert that came in. There were upwards of 10,000 unique alerts per hour. Critical issues had been missed due to all the noise. The directors and VPs got an earful enough times that they forced the monitoring team to open tickets for all the alerts and troubleshoot them. The next day the system was down to about a dozen unique alerts per hour after excluding informational alerts and the remainder were eventually closed out. It was the first time the boards had all been green for real this time vs. painting them green for the media and the Gartner Group.
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.
Every screen after that had "Press F1 for help" on it either on the top or bottom line of text
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.
What you're describing is customer success, which is almost always post-sales. Engineers working with customers post-sales is a great idea. *Pre*-sales is where it gets tricky.
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.
> 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.
We make a B2B application, and I jump at the opportunity to join in on a support call with a customer or otherwise see how our customers use our product.
I knew nothing about the sector when I started, but I've grown a fairly decent understanding of the challenges and pain points. However every customer does things a bit differently, and so it's useful to experience it first hand.
That our dev team has such good understanding of the domain and our customers has been instrumental to the company's rise to a dominant position, I think. You just make better decisions, from small to large, when you're more in-tune with how the application will be used.
I always say the engineers and designer should actually use the product (including cleaning!), then we will have better products. It’s true for household items. It’s certainly true for software products.
OK, but do the actual sales people like to use the workflow that an engineer likes?
Just because as an engineer I might try to be the end user, in order to design a UX to solve a problem, doesn't mean that the people who aren't engineers who will ultimately be using the UX for sales will actually like the workflow an engineer likes.
If anything I have found from experience that what an engineer finds intuitive and fluid is not the same thing that most non-engineers find intuitive or fluid.
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.
Very risky strategy with engineers that don't have good "customer presence" depending on the kind of sales calls they "ran." This is something I would expect product managers to do. I would say that this is more of a product management failure than anything else. Unless it's a super small early-stage startup, in which case all bets are off and I'd expect everyone to kind of do everything.
I don't think you can build a unified platform using anecdotes. That's why product research and product market fit is a thing. Not product customer fit. Unless you're willing to understand how to address your market segment's painpoints, you're just going to have a platform like jira that does nothing great but everyone somehow limps along with it.
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.
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.
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.
I managed a tech team back in the late 90's and we were building a product used in a semi-industrial process. Every software dev joining the team spent their first week on the factory floor actually doing the job. Then when they started looking at the code they had some context.
I can’t comment on whether the PMs are doing their job, but I’ve been building on my own for almost a year now. Working directly with the end user is what motivates me and it’s very eye opening. A lot of engineering thought can miss without guidance. Some experience is always worthwhile.
It doesn’t really look like the solution was simply forcing engineers to join sales calls.
The real issue seems to have been a breakdown in communication between engineers and those relaying customer needs.
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.
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.
And from experience, customer requests will not only be pushy and aggressive, but often at odds with company policy and directions. If they have a direct way to contact, one may end up not being able to do one's job due to the interruptions.
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!
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.
difficult to do unless you're building tooling/personal productivity stuff. i don't know how a company would dogfood a point-of-sale platform, for example.
> 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.”
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.
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.
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.
Lots of product managers have never studied product development. You'll find philosophers, designers, physicists, even musicians in the role. Many have great people skills, but little understanding of customer service, building products, or scaling a business. And funnily enough, those are all real careers and degrees.
The result, which you often see in companies with 300+ employees, is that engineers have far more experience building products than their PMs, what engineers usually lack is knowledge of the customer and their pain points, and a roadmap that leads to successful outcomes. In other words: a real product manager.
It's not enough for PMs to throw around cliches like "I represent the customer" or "the product has to be built around customer needs" if they don't understand how to actually build and ship software.
Last year I dug into this and found it's not unusual. Many software companies hire smart people as CPO, Product Director, or Head of Product because they have leadership skills, people skills, and some knowledge of the industry. But most have little to no background in business, marketing, economics, or product development. Some companies go even further and promote an engineer with project management experience to Head of Product. And, of course, people in those roles tend to hire others who look like them, with similar experience. One day their CEO realiseS their product isn't selling, customers aren't happy, or engineers are left to figure out what to build.
To put it in perspective, imagine a company making a lawyer their Engineering Manager and asking them to build an engineering team. What are the chances they'd do better than a computer scientist or an actual engineer? Pretty slim. Sure, there are exceptions, but what usually happens is their engineers aren't motivated and complain about the lack of coaching, vision, purpose, and the poor quality of their tools, processes, code, and work environment.
Bottom line: companies need to audit product leadership roles as a priority and figure out who's really in charge of the product. Run an internal survey to check whether your CPO, Director, Head of Product, and Product Managers have studied business or have actual expertise in it. If not, you're in trouble.
I support every single word of this comment. Good product managers are unicorn masters of discovery and delivery who are so rare that they climb up quickly in corporate hierarchy to strategic positions leaving holes in product operations. I have seen products running A/B tests without understanding how they work, designing UI sketches without any knowledge of UX, pushing features to roadmap based on a feedback of a single user etc. Maybe it makes more sense to abandon this role instead of fixing it and split the required skills between UX designers, business analysts, marketers, engineering and project managers etc.
I think the role of Product Manager should be renamed Customer Manager to avoid confusion and conflicts of interest. Some companies like Airbnb tried switching to Program Manager, but that only adds to the confusion.
Right now, the Product Manager is seen as the CEO's delegate, making sure the product follows business strategy, while the Engineering Manager is the CTO's delegate, making sure the product follows technical strategy. One represents business the other represents technology. But IMO since both are building the product together, the title Product Manager creates competition instead of collaboration.
The software needs the customer just as much as the customer needs the software. That's why I think the roles of Engineering Manager and Customer Manager make more sense, working together to build the best product possible. The product isn't managed by one side, it's managed by both.
However, the real problem isn't the role title, it's the qualifications of the person in the role. Companies don't hire lawyers as Engineering Managers, so why do they hire musicians as Product Managers?
>Business strategy
>Customer Manager
That sounds weird. Product managers do not represent customers interests, they represent business value which is not always in making all customers happy. E.g. conversion optimization brings no added value to customers, so it’s not a great name choice. If the role defined as it us now, „product manager“ is the most appropriate name.
It does sound a bit weird, I have to admit. Customer Experience Manager sounds better or just CX Manager.
For me, the title Product Manager sets the wrong expectation, it makes it sound like they own the product, which clashes with other roles. In reality, they don't own the product, they own alignment: customer needs, business goals, and engineering feasibility.
I've heard many YC founders say that the CEO (or CPO) is the only one who truly owns the product, and I agree. The PM should never own it, they are interpreters who take the CEO's vision, combine it with customer insight, and help the team make the right trade-offs.
I have worked with so so many ineffective product managers. The good ones are indeed unicorns.
Even when you have good ones, they can't scale up to all of the things that I'd want them to own, meaning that engineering fills a lot of gaps.
This ends up being uncomfortable and necessary. I'm still learning how to make it work.
The best PMs are like mini-CEOs, and many of them go on to become CPOs. But there's a lot of confusion in the software industry about what the role of a PM should be. For example, I see companies putting too much emphasis on usage metrics, while very few focus on the far more important skill of asking the right questions. PMs look at dashboards to make informed decisions, but most of them aren't even asking the right questions. And they don't know if the questions they're asking are the right ones, because they have no real knowledge of product development, just a bit of experience which is limiting. That's what happens when engineers, designers, or musicians end up in PM roles, reacting to data or using it to validate their own or someone else's assumptions.
The real problem, I believe, starts with companies hiring anyone with people skills as a PM. They don't understand their role and responsibilities, it's common to hear PM say "I own the product." But that's not really true. According to successful founders and CEOs, they are the only ones who truly own the product, and that's an important point for leadership to establish. PMs thinking they own the product creates power struggles with leadership, engineering and design, while a title like "Customer Experience Manager" makes it clear the role is about representing the customer's needs, aligning them with the CEO's vision, and making the right trade-offs.
Business people with knowledge and experience always put the customer at the centre and focus on aligning customer value with business value. In other words, if you're the CEO of Uber and your PM isn't driving a taxi once a week, then, IMO, you hired the wrong person.
> Last year I dug into this and found it's not unusual. Many software companies hire smart people as CPO, Product Director, or Head of Product because they have leadership skills, people skills, and some knowledge of the industry. But most have little to no background in business, marketing, economics, or product development. Some companies go even further and promote an engineer with project management experience to Head of Product.
I was right with you until the last sentence of this. As an engineer-turned-PM who is still very much technical, I can count on one hand the number of technically competent PMs I've known in my life, and have plenty of fingers left over. Having experience developing products can easily be a liability, because while delivering software is important, you're mostly expected to be an advocate for the business, which means that you live in the world of corporate politics and can't be perceived as too in the tank for the tech staff.
What I see is the exact opposite of what you've described: the PM that gets ahead is invariably someone with a background in business or marketing, and the technical background is deemed almost irrelevant. If you spend too much time focusing on technical issues, someone swoops in with the theater of "data-driven decisions" and "rapid iteration" -- you can justify virtually anything by cherry-picking statistics, and it's always possible to criticize the development speed of a team when you don't involve yourself in the details -- the role quickly becomes about spinning a compelling story to upper management.
Basically, a huge percentage of PMs understand little more than the first few chapters of The Lean Startup.
I think the comment you're replying to agrees with you - it makes more sense with the last two quoted sentences swapped. I could be wrong but this interpretation seems consistent with the rest of the comment.
"Many software companies hire smart people as CPO, Product Director, or Head of Product because they have leadership skills, people skills, and some knowledge of the industry. Some companies go even further and promote an engineer with project management experience to Head of Product. But most have little to no background in business, marketing, economics, or product development."
I was saying that many companies already make a mistake by putting unqualified people in senior product roles, and some go even further by making the bigger mistake of promoting an engineer with only project management experience straight to Head of Product.
>> Many have great people skills, but little understanding of customer service, building products, or scaling a business. And funnily enough, those are all real careers and degrees.
Where would people skills rank then in your hierarchy for product managers?
People skills matter for product managers, but they come after customer and product experience, business and product strategy, and execution and delivery. Otherwise you just end up with a nice PM who doesn't know how to move the product forward.
Would also be really nice if companies selected CEOs with a deep understanding of the core business.
> I would think the engineers usually get their kick out of making things fast or easy to maintain
Is your company hiring? Because I've spent 30 years being this engineer and nearly everyone looks at me like I've got horns growing out of my head.
That's not where most engineers find their job satisfaction, more's the pity. And they think they know better than users. There's a reason UX has been around for at least four decades longer than DX. Developers think both are made up.
If a user holds an ice cream cone upside-down and their ice cream falls to the floor, do you blame the user for not holding their ice cream cone upright or the creator of the ice cream cone for a stupid design that allows the ice cream to so easily fall out of the ice cream holding device and onto the floor?
I find far more often that bad UX is the result of someone trying to use a tool for something it wasn't designed for. They might even clob several different tools together in an unholy abomination to get it to do what they actually want instead of having a tool built to do precisely what they want (and once that tool has been built - people will inevitably misuse it to do things other than what it was designed for and then complain about its poor UX for doing those things).
> If a user holds an ice cream cone upside-down and their ice cream falls to the floor, do you blame the user for not holding their ice cream cone upright or the creator of the ice cream cone for a stupid design that allows the ice cream to so easily fall out of the ice cream holding device and onto the floor?
Playing along with this analogy, what I think we see a lot of in product development is the customer going to the PM and saying they need the cone to have a cover. The PM and the customer iterate over the specifics of the cover. PM goes to the engineer and tells them the cone needs a cover that meets x, y, and z requirements. Engineer, knowing how you're supposed to use the ice cream cone, objects. PM, knowing what the customer needs, insists.
> Engineer, knowing how you're supposed to use the ice cream cone, objects. PM, knowing what the customer needs, insists.
That’s the kicker. They know what the customer _wants_ not what they _need_
The number of times a Jr engineer has asked me “how do I accomplish task X in technology Y, it’s really important!”
I always, always ask “what problem are you trying to solve. Not once in over 15 YoE has the solution been to use X.
A good PM doesn’t say “this is what the customer needs” because most of the time the fucking customer doesn’t actually understand what they need.
The engineer knows that holding the ice cream cone upside down means they’re trying to use the product in a way it was never intended, so they push back.
A good PM would ask “why do you want to hold the ice cream cone upside down, customer?”
“Oh well we don’t actually want to hold it upside down, we just get frustrated that sometimes when we put too much ice cream on/in the cone it falls out. So if you can make the cone hold the ice cream while upside down, the problem is solved!”
“Oh, so what you actually need is a bigger cone that can hold more ice cream?”
“Oh, yeah that would work too”
meme about Spider-Man facepalming, where Spider-Man is the engineer
My point is that by letting the customer define the solution rather than explain the problem, nobody knows they're even trying to hold it upside down. The why of it all is lost in some PM / Engineer power struggle that usually results in ice cream cones having covers (and a happy customer).
As a sw engineer, I’m going to tell our customer that the thing they claim they want they do not need.
Because I’ve done this enough times, they’ll listen to me and we won’t waste time on it.
You should try it, instead of designing soggy ice cream cone caps.
And thus the tub was conceived. By someone who was watching people wrangling with cones.
Unfortunately tho, it also suffers the same huge design flaw: hold it upside down, ice cream hits floor. =(
And thus, the milkshake was born. And it was good.
> I find far more often that bad UX is the result of someone trying to use a tool for something it wasn't designed for.
Isn't that the point? In the story the engineers weren't designing a tool well-suited for the customers, but for whatever abstract scenarios they had in their head. In the open source world it's more reasonable and common to design a tool not predicated on the predominant models and workflows. And every once in a awhile those experiments result in something very valuable that helps to break predominant paradigms. But in the commercial space solving customer's immediate problems in a manner that is intuitive for them is paramount.
> In the story the engineers weren't designing a tool well-suited for the customers, but for whatever abstract scenarios they had in their head.
A joke exists about how developers will never be displaced by AI because that would require clients and/or project managers to accurately describe what they want the AI to build. On one hand that is extremely egotistical of developers. On the other it is also factual.
To my understanding of the story the developers had designed what was being communicated to them by someone who described what customers asked for and not what the customers actually wanted or needed. Nothing to do with what the engineers thought customers wanted and everything to do with what project managers had expressed to the engineers about what customers wanted. Speaking with the customers directly gave them a better idea of what was actually being asked for. So they built that instead.
My takeaway from the story is to fire the project manager. Not to make devs call clients.
Product and project managers can have similar issues of perspective as engineers, chasing trends in the industry or losing the forest for the trees (feature checklists, etc). But, yeah, having devs talk directly to customers can be problematic. If you give a customer a direct line to an engineer, sometimes they can monopolize the engineer's time (they feel they can leverage an "inside" contact) or skew their priorities. Having engineers work closely with tech support is a good middle ground, such as by fostering 1:1 relationships with support or even fielding tech support tickets themselves (tech support tickets have more finality than, e.g. sales support issues). That way they can get a broader perspective on pain points and potential new directions. It can really help refine a product beyond what can be achieved by lobbing feature and bug tickets over a fence or through formal group meetings (which often can be either too structured or too chaotic).
God forbid an engineer should have an opinion on UI/UX.
I have long believed that the biggest issue here is that engineers and power users generally have a much higher “pain threshold” when it comes to poor or complex UI/UX. They are not always the best people to judge how or if less experienced users will tolerate or adapt to those patterns. It’s fine to have opinions but they must be prepared for them to be challenged. Even better if they can invite others to challenge them, which is essentially what talking to your users achieves.
> engineers and power users generally have a much higher “pain threshold” when it comes to poor or complex UI/UX
I don't think that's entirely accurate. We tolerate steep learning curves if the result is an increase to our power. That's why we are power users.
Vim, for example. Some of us put effort into learning it because it's a powerful and efficient editing language that will enable us to easily accomplish hard things.
Caring about the system itself and being willing to put effort into it are what separates power users from normal users. We don't do this because of masochism, we do it because we want to increase our power.
Normal users want the system to just do what they want without any thinking or effort at all, as though it was a highly specialized tool for their exact task rather than a powerful programmable general purpose computer.
Personally I don't care at all about how "less experienced users will tolerate or adapt". This unceasing focus on the wants and needs of normal users frequently hinders us. Developers typically reduce the complexity and feature set of a piece of software in order to turn it into something a normal user can deal with. We want more power, not less.
Normal users don't really matter unless they are directly paying our salary. We should all favor ourselves unless we're getting paid to focus on someone else.
The two biggest causes of major UI problems I see are:
1) Exactly what you wrote: power users don’t even realize they clicked through five things in ten seconds any one of which would have derailed a weaker user, because they’re so used to bad UI that it’s almost invisible to them.
2) Zero care given to what’s most natural for the platform, for cost of development & maintenance, or what’s easiest for the user, when (bad) designers and (bad) “product folks” get involved and are way too into the wrong kinds of “consistency”, especially brand and cross-platform consistency (yo, I’m not sure it’s worth spending extra money fucking up contrast and platform norms on your inputs so your fucking radio buttons are “on brand” or whatever, like, I’m deeply skeptical of the actual business value of that kind of thing, though I can see the PowerPoint presentation value… and that’s why it happens)
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?
Ultimately, you need to decide who your target user is. Do you want to cater to the lowest common denominator, or do you want to want to make something power users can customize to fit their workflow?
Neither answer is necessarily wrong, you just need to make a choice.
> you just need to make a choice.
This fallacy is at the heart of the failure of modern software.
Making things work for the median user is almost entirely about defaults and intuitiveness. If everybody is sending messages all the time, there should be a conspicuous button for sending messages.
Making things work for power users is about allowing those defaults to be changed. It's fine if this is five deep in a menu somewhere. It's fine if there is an option for "advanced mode" that opens up a bunch of menus that are otherwise hidden. It's fine if this requires you to write your own filter rules etc., as long as that's available. What's not fine is to make the limited interface the only interface.
Simple things should be easy and complex things should be possible.
> Simple things should be easy and complex things should be possible.
I love this.
Building on this thought: When you are starting to build something, you have very limited resources. Focus only on making simple things easy and forget everything else. Once you have product market fit expand into making complex things possible. This applies to 90% of all products.
Those goals are far less at odds than you seem to be implying.
One of UX principles is exactly trying to do both.
My mom can use gmail, but she doesn’t even know about its hotkeys and accelerators, or Labs and whatnot
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.
Using? Are you paying?
If you're building a website that is accessible to the public at no cost, I don't see the distinction.
The issue is that software engineers most often strike a balance between passive aggressive and overly opinionated... Its a shit mix if you ask me- very frustrating personality to work with.
Isn't that the same as UI/UX people being generally clueless about how to build applications for the very platform for which they are designing? Designers and product managers constantly have to be guided about the logical and the structural constraints of their target platforms, to be given workarounds, to be taught how to logically divide their reusable components so that they can build their dream design system which, by the way, always fights the platform's native design system.
It's totally fine to have an opinion on UI/UX if it is informed by cognitive psychology and other relevant HCI subfields, in the same way that it's OK for UI/UX to push for designs so long as they are also informed by business and engineering.
That’s the attitude he’s talking about!
> People around Desktop Linux could write a complete book about dismissing user's complaints.
On Linux we enjoy flexible systems that empower us to change the things we don't like all by ourselves without any need to involve any "project managers" at all.
And it's completely fine if Linux systems are built around the needs of programmers and power users. It's not like normal users are paying us. Linux users should focus exclusively on themselves and their own needs.
While PMs have their own share of quirks to work around with and your comment doesn't say they have no faults at all, I wholeheartedly agree with you here. I've worked as a developer, QA, systems operator, and a bunch of other positions. Holy cow, we are all full of ourselves (PMs included), but the disdain of a lot of developers towards the end user (sometimes PMs fault) is incredible. A bunch of nerds ignoring common people use cases and abilities. And it keeps happening and most still don't recognize what's happening.
I've worked as a Manager so I've had to deal (and collaborate) with this kind of misunderstanding, but it truly gets tiring when developers complain about users trying dumb things (for developers) over and over again, yet they themselves have learned nothing from previous encounters with this phenomenon and complain instead about stupid users (or PM, or company, or whatever).
I kind of think this is correct but not for the reason you think. To most engineers, users are the annoying thing on the other end of a ticket. They “don’t know how to use the product properly”.
I’ve also had great success dropping engineers directly in front of customers. I think it’s just because it humanizes the person behind the ticket
I think you're right. Similar to the article's title, a useful thing is dogfooding. But where this can go wrong is because conversation is engineer to engineer (not exclusively) is that the takeaway can be "Oh, I was holding it wrong" instead of "this was not as intuitive as I thought, how can I fix that?" I know there's backend vs frontend arguments[0] but I think backend needs to be conscious about front end. When we write backend it is easy to just focus on making things work but we're a few steps back from typical (or targeted) use cases.
Classic problem with us eningeering types, right? When you're in the weeds it is easy to see the differences. Humans are always biased to forget how difficult it was to learn something, judging on level of current (subjective) difficulty. For me a big change in framing came through Linux. I'd convince my friends to use it and then as the years went by I saw how much easier it became to do so. Now, for the most part it is much easier for an average person to use. There difference isn't "holding it wrong" so much as "it's hard to hold" (or "it's hard/unintuitive to hold correctly"). Even just with the more recent rise of TUIs. Even us terminally terminal types are loving the new TUIs and ultimately that is a frontend thing. It's just frontend for backenders, allowing us to stay in the environments we are efficient in, maintain our power and flexibility, but also get some aesthetics (which has functional utility! I bet you use syntax highlighting, and not just because it is pretty).
There's a strategy to writing backends that I think helps both backend and frontend: write flexible code. It draws from the unix philosophy, where functions (or small programs) should be containerized or focused. Then the complexity happens by putting the things together (there's a hierarchy to this). Helps write backend code so it is easier to maintain, reduces repetition, allows for quicker feature development, and ultimately makes it far easier to read. It's a little more work up front, but it sure pays dividends. It helps front end people because ultimately they are towards the... *front end* of that hierarchy. Makes it easier for them to pull pieces together, wrap things, and communicate with backend types.
Honestly, I think the biggest roadblock to this strategy is the constant push for rushing. Why is there always time to do things twice but never enough time to do things right? It all depends if we're running a sprint or a marathon. A sprint is all about speed, but a marathon requires a lot of strategizing. A marathon requires some sprinting, but you can't sprint the entire thing. We like to drop sayings like "don't let perfection be the enemy of good" but truth is it's not about perfection, it is about different ideas of what is "good enough." Which, is ultimately an issue of communication.
[0] I'll still argue backend is more important ;) because that's the foundation. Your building can't stand, let alone be pretty, if it doesn't have a solid foundation and skeleton. All that is invisible though. Maybe that's why these arguments occur.
I don't think it is ironic, but makes perfect sense. It's about the marathon strategy.
I think another important part of "running a marathon" is having excess time. It is hard to predict disaster, but you can prepare for it. You don't want the exact number of lifeboats so that each passenger on the ship has a seat on a lifeboat. You need excess because in a disaster it is likely a lifeboat will fail. The lucky thing with time is that if you finish ahead of schedule you can just go onto the next thing. It's always better to finish ahead of schedule than behind. But if you always predict to be on schedule you're more likely to fall behind because there's more ways to fall behind than get ahead.
running without slack means every bump in the road adds a delay which makes the manager's troubles even worse when they have to report the inevitable delay (which leads to a negative spiral of rush-and-delay)
Sure, a rally car isn't as fast as nascar, but which environment are you in? Super smooth road with only left turns and is built to allow you to go as fast as possible? Or literally anything else.
> You have to absorb those bumps. But if you have no shocks you just rattle apart.
yes, and the real issue is, there are no smooth roads (ime anyways)
> Super smooth road with only left turns and is built to allow you to go as fast as possible?
whats interesting is, from a high-level perspective, riding with shocks (slack) can feel more like nascar than rally even if the day-to-day has bumps.
and of course, aside from slack, there are other things that help get to "nascar" such as good specs, good/easy architecture, low-interruption/async communication, and good management, but even then its just reducing the likelihood of bumps...
This story of whittling down the product to meet the needs of the user as grepped from several sales calls assumes that a small sample is statistically representative (and it’s not) and assumes simplification always makes for a better product (and it doesn’t).
When I ask 15 users for their input, only 3 will speak up, and their needs and views don’t fully overlap.
Photoshop is a great example of a product that was extremely complicated and difficult to use but dominated the market for many years.
Microsoft has continually made updates to its products over the years, making it basically do the same thing but with unnecessary and frustrating changes, and people keep buying it.
Yes, UX is important, and A/B or similar evolutionary testing is important. Yes, devs tend to overcomplicate things. But, there’s no magic simplification bullet.
PMs don’t help make good software.
Don't try to tell them that.
>somebody is berating product of engineer's genius like it would be a retarded hamster
Where can I find this hamster and is it available for adoption?
The fact that Jobs wasn't an engineer shows this clearly isn't just an engineering problem.
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.
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.
How to say datadog with more words.
That might explain why the UI seems to change every other week
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
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.
Always fun to see an exchange on Reddit like:
Person1: "thing doesn't work?"
Person2: "yeah it doesn't work for me either"
Person3: "it's always something I have to work around"
Person4: "I work for <company> as a customer support outreach social media community engagement executive. Can you go and jump through hoops and open a support case?"
Not raising it internally, not getting anything changed or fixed; suggesting the customer do more work to tell the company about the problem. A person who works for the company and is paid to read social media and has read the complaints, is not only apparently ignoring them but annoying the customers as well.
Alternate Person4: "<sigh> I work for <company> as a technical employee and we've been begging to get this fixed for years. As a workaround you can <xyz>. Email me directly if you need more help, and if we get a patch to fix ever, I'll let you know".
I can relate to Alt 4. Having my work email on something and finding out the person behind the desk is a customer can be unfun.
I haven’t used the products of any company I’ve worked for.
You can never rely on support reps to escalate UX issues to product teams for a couple reasons.
First, from their perspective if they are able to solve an issue by following their script, even if it took 20 convoluted steps, everything is working normally. People are used to occasionally dealing with workarounds so it's not a big deal in their mind.
Second, it's not in their interest to report UX issues. They are measured by the number of tickets they close, so the issue that gets a lot of inbound support and they know an easy workaround for is nicely boosting their numbers. Eventually these things get fixed by product and they move on to doing the same thing with other tickets.
Perverse incentives. They are judged by how long the call takes, and every time they escalate a common problem that the devs could fix, now their numbers will go down and they'll get punished for their good work.
Dell at one point pulled the plug on outsourcing their tech support. They spotted this moral hazard partway through the process and decided it was better to keep it in house.
On the opposite side of moral hazard, early in my career I worked for a large web security company in tech support. We were not permitted to escalate to engineering at all. Often this meant the only solution was to apply our own, unofficial code changes!
> We were not permitted to escalate to engineering at all.
I have no words! Except that I really want to know the organizational dysfunction that ended up creating that policy.
At my last job I worked in professional services, and after reporting multiple issues over and over and over through the normal process I finally wormed my way into a friendship with engineering and product leadership. A conversation with someone they trust was THE ONLY WAY to get them to take seriously a Jira report from the field saying "this is annoying/broken at every customer. Yes there is a workaround, but can we get it fixed?"
Product at every company I've worked for only ever cared about prioritizing shiny new features or bugs that have people screaming at them.
This is spot on and echoes my experience (seeing it from the dev side)
speaking as someone who clawed their way up out of the support mud...
sometimes it's a lack of accessible escalation procedure (no, a bug report is not the same thing as "this feature sucks to use and needs to be revisited), and sometimes it's just the unfortunate fact that those support reps most capable of clearly explaining these issues (or better yet, understanding the underlying mechanisms that cause the issues) get promoted out of front-line support roles (hi)... or move on because they're not satisfied with remaining in support (hi).
obviously there are a ton of exceptions to this rule but i've personally covered just about all those bases throughout my career. i would have loved to have seen engineers get involved with the burden of support, but maybe that's just because i came out of dysfunctional shops... not that they're not all dysfunctional in one way or another.
I think this is pretty much it: everyone capable of doing quality support has the skills to double or triple their salary by doing something more interesting (usually dev or sysops).
The way I've typically solved this is by keeping an eye on the support inbox myself. It takes just a few minutes every day and I've caught some pretty low-hanging fruit with this that really does make the product better. Sometimes it's as simple as just adding a permalink somewhere.
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.
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.
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.
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.
Then incentives and (I hate this word) KPIs aren't aligned. That's arguably a somewhat separate problem though.
> 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.
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.
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.
> 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."
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.
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.
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.
Many such cases of employees adding negative value.
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.
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
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"
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.
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.
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.
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.
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.
Working with customers now and then simply translates to better products and also less maintenance issues, which is _better_ for said developer.
Most SWEs are almost certainly better at PMing than the average "career" PM. They just don't want to do it.
Agree, also the whole thing reads kinda fake in the first place.
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.
-10x employees DO exist!
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
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
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.
> 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.
> DevOps engineer is more capable/actionable at turning customer needs into working solutions
That’s been my experience all my tears in industry.
I, too, have had many, many tears in this industry.
;P
An errant autocorrect a little too correct to correct.
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.
> 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.
> 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.
For my scope documents I spend hours questioning users and validating each step and asking “why don’t you just…?”, and try and boil that down.
Doesn’t matter if you drive VS Code every day though, because that means You Know Better (tm), and to hell with the discovery process.
I actually wouldn’t have a problem with pulling engineers into those discovery exercises directly, except when I have, they’ve just refused to engage. Come out without asking many questions and seemingly haven’t listened to a thing.
It’s like engineers just think it’s all beneath them, (and I accept I was a bit like that when I was engineering), so forcing them to do the calls isn’t an awful idea.
> I actually wouldn’t have a problem with pulling engineers into those discovery exercises directly, except when I have, they’ve just refused to engage.
I know not everything comes across in a short HN comment, but that truly sounds like a "Why don't you just...?" solution. What does the user of your work actually need?
> It’s like engineers just think it’s all beneath them
Well, are they wrong? You seem to recognize — and I wholeheartedly agree — that when an engineer throws a "I just did..." solution in front a customer and the customer finds it to beneath them to use, it is the engineer who has failed. The customer is completely justified in pushing back on something that isn't right. They shouldn't have to accept slop just because that's what you delivered. But it seems you aren't willing to hold yourself to the same standard?
> The engineers will spend 10 minutes thinking about it, come up with a solution
This is fine if coupled with a dose of humility. Coming up with obvious solutions then researching why they don't work (or asking an expert) is a good way to understand the domain.
> (that won't work, but they insist it will) and dismiss the problem as "trivial", and think the guy is an idiot
This is obviously bad, but engineers often have imperfect people skills. I like to think they're aiming for the first but accidentally end up doing the second.
> it is not their job to rip each detail to shreds
It is an engineer's job to ask questions during planning when they're confused. This feels like it might be bad people skills again, because "ask questions" and "rip each detail to shreds" are in the same direction.
The first rule of Hacker News comments is it's never the engineer's fault
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.
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.
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.
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.
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
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.
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.
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.
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.
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
Yes, many PMs suck. And many engineers suck. And communication is always lossy. Having many/all engineers take some calls helps to mitigate those.
You're assuming they have Product Managers at all. Or that they're not massively oversubscribed.
The person who wrote the original post self-described as acting as a product manager.
Yes, fire the PMs should be a meme.
Perhaps, but being told something very often cannot possibly replace experiencing it yourself.
I’ve worked at companies where the PMs couldn’t talk to customers…
Good. All Engineers should deal with the clients directly.
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
It's one thing to be told (by a PM). It's another thing to believe.
This should be common knowledge
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.
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?
Yup. In other words, they have shit PMs.
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.
> I have been at countless places where the engineers are out of sync with the product.
Me too, but surprisingly it happens more often at places with the most Product Managers.
My worst experience was at a company that tried to enforce a specific ratio of Product Managers and "Product Designers" to engineers. If you added up the designers, product, project, and program people the total was higher than the number of engineers.
It only made everything worse. Fighting your way through the Product Management bureaucracy while trying to avoid having one of the PMs view your input as a threat was a job in itself.
Great Product Managers are invaluable additions to a company. The modern version of Product Management has attracted a lot of people who thrive on bureaucracy and process. The proliferation of Product Management influencers has made it much worse.
100%, my current team could benefit from a strong technical PM, but the risk of negative impact from a poor PM - and the 10:1 ratio you see of bad-to-good PMs in the wild - has me pushing back against hiring one. The risk isn't worth the reward.
you're not wrong, but i don't think forcing engineers to take sales calls is the right move either. there's lots of soft skills involved in running a successful call that engineers aren't trained or even interviewed on.
(i'm definining "sales calls" as the initial discovery call before a demo or proof of concept is agreed upon. i would be okay with having engineers _ride along_ for complex presales demos, but even then, product should really be serving that role.)
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.
Yeah I think having engineers understand product is important as I think it's the harder to get right than the basic engineering. Most of the products I've worked on have failed for product reasons so just from a logical standpoint it makes sense to focus on making sure that's a strength for a team.
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.
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.
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?
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.
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.
> 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.
> 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.
Reddit has become an outlet for creative writing. This might have been inspired by some real life events, or it might have been pure fiction. Either way the end result is dripping with the typical Reddit creative writing elements, with a dash of LinkedIn style business storytelling.
Lots of people also lie in the reddit comments.
They say they have a certain job, work for a certain company, or know how to do a certain task; and they get the terminology completely wrong, or make up stuff that is obvious to someone who actually knows, but sounds good to people who don't know.
Karma is a hell of a drug.
It sounds like it's a B2B SaaS product that's gone through multiple pivots with very weak guidance on product on every step.
Not that I'm disagreeing with you, but it's a very common way for things to go wrong.
There's just something about the specifics that seems really odd to me. "60% of features"... really? Sixty percent, specifically? Like I think this story is maybe based on some series of events at a SaaS and I agree with you in principle but it seems like the author ran it through a Linkedin thought leader LLM.
60% of the features in a product small enough to rewrite in 2 weeks is probably 3 features.
You can tell it's fake by the LinkedIn-y prose, which is always short sentences followed by a "mic drop moment."
Of course it's fake, it's Reddit. How does this dredge reach the front page?
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.
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.
> Because they finally understood who was actually using our product.
Yes!!!
> The biggest problem with most engineers is actually over-engineering.
Err, wait, go back to step 1. Over-engineering is sometimes a byproduct of not understanding the customer use cases. That lack of understanding is the biggest problem.
So, I’m an “engineer” —- my most common frustration with other engineers is their lack of interest in understanding of the actual product being sold. In my experience, sometimes the reason is job-fit issues, sometimes it’s ego, but usually it’s a combination of culture and incentive.
I worked at a place that made a robo-calling sales crm and they thought it would be great if during an offsite they had everyone use it to cold call places and run through some script they'd prepared. They didn't seem to understand nor care about what sort of anxiety that could cause not-sales-people. That's when I decided to start looking for another job.
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.
"does anyone use this?" is a running joke where I work because we always say yes to a feature request, most of them get used briefly by one customer, then we have to maintain/test forever just in case
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.
Sales engineers should be the spirit animals of PMs/SDEs.
They often are having to integrate the company's software with the whole stack of the customer.
They experience the pain of real world setup/optimization/bugs more than anyone else in the company.
They generally are savvy to the challenges of actual software engineering and what is realistic to get done in a given time frame.
They are usually technically articulate enough to frame the challenges in an understandable way for SDEs.
They are driven to improve the customer experience because it also makes their lives better, vs the sales guy looking for ways to just close a sale for commission.
They are very aware of what the competition is coming into bake offs with as far as features and support.
They can let you know what bugs and missing features are costing the company the most money and customer sat.
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.)
I've seen something like this before. A monitoring team said that front-line engineers should be opening tickets for every alert that came in. There were upwards of 10,000 unique alerts per hour. Critical issues had been missed due to all the noise. The directors and VPs got an earful enough times that they forced the monitoring team to open tickets for all the alerts and troubleshoot them. The next day the system was down to about a dozen unique alerts per hour after excluding informational alerts and the remainder were eventually closed out. It was the first time the boards had all been green for real this time vs. painting them green for the media and the Gartner Group.
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.
Every screen after that had "Press F1 for help" on it either on the top or bottom line of text
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.
What you're describing is customer success, which is almost always post-sales. Engineers working with customers post-sales is a great idea. *Pre*-sales is where it gets tricky.
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.
This is hilarious:
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.
We make a B2B application, and I jump at the opportunity to join in on a support call with a customer or otherwise see how our customers use our product.
I knew nothing about the sector when I started, but I've grown a fairly decent understanding of the challenges and pain points. However every customer does things a bit differently, and so it's useful to experience it first hand.
That our dev team has such good understanding of the domain and our customers has been instrumental to the company's rise to a dominant position, I think. You just make better decisions, from small to large, when you're more in-tune with how the application will be used.
This is a recurring theme in quality control. Let the workers investigate and solve the problem themselves.
I always say the engineers and designer should actually use the product (including cleaning!), then we will have better products. It’s true for household items. It’s certainly true for software products.
OK, but do the actual sales people like to use the workflow that an engineer likes?
Just because as an engineer I might try to be the end user, in order to design a UX to solve a problem, doesn't mean that the people who aren't engineers who will ultimately be using the UX for sales will actually like the workflow an engineer likes.
If anything I have found from experience that what an engineer finds intuitive and fluid is not the same thing that most non-engineers find intuitive or fluid.
This makes me question why we need product managers.
You could record the calls, have AI summarize them, and then have AI create user stories.
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.
Very risky strategy with engineers that don't have good "customer presence" depending on the kind of sales calls they "ran." This is something I would expect product managers to do. I would say that this is more of a product management failure than anything else. Unless it's a super small early-stage startup, in which case all bets are off and I'd expect everyone to kind of do everything.
I don't think you can build a unified platform using anecdotes. That's why product research and product market fit is a thing. Not product customer fit. Unless you're willing to understand how to address your market segment's painpoints, you're just going to have a platform like jira that does nothing great but everyone somehow limps along with it.
I worked at a place where every new dev was required to spend a month or more working on the frontline helpdesk. It was very effective.
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.
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.
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.
I managed a tech team back in the late 90's and we were building a product used in a semi-industrial process. Every software dev joining the team spent their first week on the factory floor actually doing the job. Then when they started looking at the code they had some context.
Forced every politician to use average health insurance. They rewrote our national healthcare polices in 2 weeks.
I can’t comment on whether the PMs are doing their job, but I’ve been building on my own for almost a year now. Working directly with the end user is what motivates me and it’s very eye opening. A lot of engineering thought can miss without guidance. Some experience is always worthwhile.
It doesn’t really look like the solution was simply forcing engineers to join sales calls. The real issue seems to have been a breakdown in communication between engineers and those relaying customer needs.
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.
Here's what I see:
* PM asking a client: "Do you want beautiful logging, metrics and shit?" - "Hell yeah we want logging, metrics and shit!"
* PM telling devs: implement beautiful logging, metrics and shit
* Devs spend half a year implementing all that shit
* The client looks at the final product: "What is this shit? We need a freaking green checkmark!"
Relevant:
https://www.youtube.com/watch?v=hNuu9CpdjIo
I am pretty sure that post was written with a chatbot. It reads like LinkedIn glurge.
Do we have any evidence of the claimed sequence of events?
All this says to me is that they have no technical product/program management in place to actually do what is described.
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.
Inhumane. Humans shouldnt be exposed to sales calls. Thats why sales "people" exist.
I forced every engineer to take sales calls and now our platform is command line only.
What kind of commission was involved and are the engineers now given product designer titles?
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.
Thankfully the comments agree that OP was the problem all along.
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.
And from experience, customer requests will not only be pushy and aggressive, but often at odds with company policy and directions. If they have a direct way to contact, one may end up not being able to do one's job due to the interruptions.
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
Yes, god forbid that an engineer would be contacted directly to solve a problem they have. The thought alone.
Yes, god forbid people escalate their issues properly so they go to the right people. The thought alone.
Dogfooding works
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.
difficult to do unless you're building tooling/personal productivity stuff. i don't know how a company would dogfood a point-of-sale platform, for example.
Like this. =)
Force the people making it to use it for a while. Even just a day.
fair!
Someone apply this to the Microsoft 'teams' team please.