4 ms·

What you describe sounds like a horrible work environment. In every sensible development environment I've encountered there is a wall between the developers an

What you describe sounds like a horrible work environment. In every sensible development environment I've encountered there is a wall between the developers and the rest of of the company: their manager, who's responsibilities include shielding their team members from outside bullshit + the product owner who is the one collecting feedback / feature requests from other teams and prioritizes their requests according to the companies goals (which can of course include "build a user-friendly product"). In a system where there is direct line between the development team and other teams, most of the times the developers will only be able to get very little work done due to constant interruption, and/or they will end up spending most of the time fullfilling the requests by the people who cry the loudest, regardless if that's in the companies overall best interest not.

freehunter 9y ago
I'm not talking about feature requests, I'm talking about "holy shit all of my email is gone, just everything, it's all gone". If I'm a customer and I'm told "we'll put in a feature request and the manager will prioritize getting your emails back according to the company's goals", I'm probably not a customer anymore. I'm talking about "your product documentation says to check the box on the third page, but there are only two pages". If the response is "I'm sorry our developers are too busy getting work done to be constantly interrupted", how many customers are you keeping? I'm talking about "I purchased your product but it redirected me to something called http://localhost:3214/test/test_page.html" http://localhost:3214/test/test_page.html". If the response is "Hi, I'm the manager who is shielding my employees from your bullshit" yeah you get the idea. These are things an outsourced helpdesk (or even an in-house helpdesk) can't fix. But they are problems that real customers are having right now. Maybe it sounds like a horrible work environment to some people. To me it sounds like absolute bare minimum customer support.
- hobofan 9y ago
  Bug fixes are the same thing as a feature request. They have an implementation cost, and an expected gain in revenue (= reduced loss in revenue). It's still the role of the product manager to prioritize it. A 1:10000 freak accident that is not reproducible and therefor hard to fix probably won't be fixed for quite some time, no matter how much it sucks for the single affected customer. Unless you are running a business where each customer pays a relatively big chunck of money (I'd say enough to employ a single developer), you always have to run the numbers, no matter if it is a feature request or a "holy shit" bug.

freehunter 9y ago

I'm not talking about feature requests, I'm talking about "holy shit all of my email is gone, just everything, it's all gone". If I'm a customer and I'm told "we'll put in a feature request and the manager will prioritize getting your emails back according to the company's goals", I'm probably not a customer anymore. I'm talking about "your product documentation says to check the box on the third page, but there are only two pages". If the response is "I'm sorry our developers are too busy getting work done to be constantly interrupted", how many customers are you keeping? I'm talking about "I purchased your product but it redirected me to something called http://localhost:3214/test/test_page.html" http://localhost:3214/test/test_page.html". If the response is "Hi, I'm the manager who is shielding my employees from your bullshit" yeah you get the idea. These are things an outsourced helpdesk (or even an in-house helpdesk) can't fix. But they are problems that real customers are having right now. Maybe it sounds like a horrible work environment to some people. To me it sounds like absolute bare minimum customer support.

hobofan 9y ago
Bug fixes are the same thing as a feature request. They have an implementation cost, and an expected gain in revenue (= reduced loss in revenue). It's still the role of the product manager to prioritize it. A 1:10000 freak accident that is not reproducible and therefor hard to fix probably won't be fixed for quite some time, no matter how much it sucks for the single affected customer. Unless you are running a business where each customer pays a relatively big chunck of money (I'd say enough to employ a single developer), you always have to run the numbers, no matter if it is a feature request or a "holy shit" bug.