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