8 ms·

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

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

wordofx 1y ago
PMs don’t help make good software.
- hinkley 1y ago
  Don't try to tell them that.
hvb2 1y ago
Assuming your PM is for product manager not project manager. I would think the engineers usually get their kick out of making things fast or easy to maintain. If you have a product manager and the customers hate the product, how is that the engineers fault? I've built a couple useless features that I wouldn't want to use and couldn't explain how to use. But if you have a product person, they get to design is BECAUSE they're in the line of fire. That's a comfortable position to be in as an engineer, except that you sometimes have to build things more than once.
- zamadatix 1y ago
  There are two separate problems, and they aren't mutually exclusive, but this post seems to be specifically about the latter case (if one believes the story, of course): - The PM(s) are bad at listening to customers or turning customer feedback into a focused set of requirements. - The engineer(s) are bad at following the requirements or going back to the PM(s) when the requirements aren't clear. In the first the PM(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product. In the second, the engineer(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product. In either case, it results in the product not fitting the customer needs. I think there are better ways to solve either gap than just having the engineers join sales calls to hope it works out, but I suppose any approach is better than letting the problem sit.
  - pyman 1y ago
    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.
sillywabbit 1y ago
God forbid an engineer should have an opinion on UI/UX.
- ijidak 1y ago
  But is it an informed opinion? Every human has an opinion on practically everything. But has that human put in the effort to justify pushing that specific opinion? In this case, is the opinionated engineer humble enough to realize that using software in their day to day life does not equal using software in our customer's context?
  - sillywabbit 1y ago
    If I use the product, I'd expect that feedback to get the same weight as any other customer. And not be dismissed because it came from a 'technical' person.
    - spacecadet 1y ago
      Using? Are you paying?
      - sillywabbit 1y ago
        If you're building a website that is accessible to the public at no cost, I don't see the distinction.
  - spacecadet 1y ago
    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.
  - rcfox 1y ago
    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.
evanjrowley 1y ago
>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?
Nadya 1y ago
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).
- wahern 1y ago
  > 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.
  - Nadya 1y ago
    > 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.
matheusmoreira 1y ago
> 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.
deleted 1y ago
[deleted]
rendaw 1y ago
The fact that Jobs wasn't an engineer shows this clearly isn't just an engineering problem.
klingon33 1y ago
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.
anbotero 1y ago
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).
ccakes 1y ago
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
- godelski 1y ago
  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.

wordofx 1y ago

PMs don’t help make good software.

hinkley 1y ago
Don't try to tell them that.

hvb2 1y ago

Assuming your PM is for product manager not project manager. I would think the engineers usually get their kick out of making things fast or easy to maintain. If you have a product manager and the customers hate the product, how is that the engineers fault? I've built a couple useless features that I wouldn't want to use and couldn't explain how to use. But if you have a product person, they get to design is BECAUSE they're in the line of fire. That's a comfortable position to be in as an engineer, except that you sometimes have to build things more than once.

zamadatix 1y ago
There are two separate problems, and they aren't mutually exclusive, but this post seems to be specifically about the latter case (if one believes the story, of course): - The PM(s) are bad at listening to customers or turning customer feedback into a focused set of requirements. - The engineer(s) are bad at following the requirements or going back to the PM(s) when the requirements aren't clear. In the first the PM(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product. In the second, the engineer(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product. In either case, it results in the product not fitting the customer needs. I think there are better ways to solve either gap than just having the engineers join sales calls to hope it works out, but I suppose any approach is better than letting the problem sit.
- pyman 1y ago
  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.

sillywabbit 1y ago

God forbid an engineer should have an opinion on UI/UX.

ijidak 1y ago
But is it an informed opinion? Every human has an opinion on practically everything. But has that human put in the effort to justify pushing that specific opinion? In this case, is the opinionated engineer humble enough to realize that using software in their day to day life does not equal using software in our customer's context?
- sillywabbit 1y ago
  If I use the product, I'd expect that feedback to get the same weight as any other customer. And not be dismissed because it came from a 'technical' person.
  - spacecadet 1y ago
    Using? Are you paying?
    - sillywabbit 1y ago
      If you're building a website that is accessible to the public at no cost, I don't see the distinction.
- spacecadet 1y ago
  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.
- rcfox 1y ago
  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.

evanjrowley 1y ago

>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?

Nadya 1y ago

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).

wahern 1y ago
> 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.
- Nadya 1y ago
  > 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.

matheusmoreira 1y ago

> 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.

deleted 1y ago

[deleted]

rendaw 1y ago

The fact that Jobs wasn't an engineer shows this clearly isn't just an engineering problem.

klingon33 1y ago

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.

anbotero 1y ago

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).

ccakes 1y ago

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

godelski 1y ago
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.