111–120 of 221 posts
Earlier quoted context omitted.
> 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.
An errant autocorrect a little too correct to correct.
> 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/ac…
Earlier quoted context omitted.
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(…
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 e…
Where would people skills rank then in your hierarchy for product managers?
> 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/ac…
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 custome…
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.
Earlier quoted context omitted.
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.
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.
> 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/ac…
> 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/ac…
> 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/ac…
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 know…
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).
Earlier quoted context omitted.
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 know…
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…
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.