Earlier quoted context omitted.
God forbid an engineer should have an opinion on UI/UX.
That’s the attitude he’s talking about!
[deleted]
I forced every engineer to take sales calls and they rewrote our platform
101–110 of 221 posts
Re: I forced every engineer to take sales calls and they rewrote our platform
#102Re: I forced every engineer to take sales calls and they rewrote our platform
#103I 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.
Re: I forced every engineer to take sales calls and they rewrote our platform
#104> 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.
You can tell it's fake by the LinkedIn-y prose, which is always short sentences followed by a "mic drop moment."
Re: I forced every engineer to take sales calls and they rewrote our platform
#105Forced every politician to use average health insurance. They rewrote our national healthcare polices in 2 weeks.
Re: I forced every engineer to take sales calls and they rewrote our platform
#106Earlier 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.
Those goals are far less at odds than you seem to be implying.
Re: I forced every engineer to take sales calls and they rewrote our platform
#107Earlier 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.
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
Re: I forced every engineer to take sales calls and they rewrote our platform
#108> 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 customer side of things.
Re: I forced every engineer to take sales calls and they rewrote our platform
#109> 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…
>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?
Re: I forced every engineer to take sales calls and they rewrote our platform
#110> 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…
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…
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.