121–130 of 221 posts
> 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.
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…
PMs don’t help make good software.
* 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!"
Earlier quoted context omitted.
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 mea…
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.
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 -> produ…
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.
Earlier quoted context omitted.
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.
> 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.
> 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…
Product at every company I've worked for only ever cared about prioritizing shiny new features or bugs that have people screaming at them.
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…
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 design…
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.