Everyone should read support emails • Hacker News Board

Re: Everyone should read support emails

#141

Post by SpicyLemonZest » Mon, Mar 04, 2019, 5:08 PM UTC

jwr wrote: post #138

lbotos wrote: post #126

Hi, Support Engineering Manager here, who has forgone Dev for a career in Support. In a small company ( As companies grow 2 things that I think are really more valuable: - Support Engineers, These are folks that have commit access and can write fixes, who are focused directly on customers. Don't distract product from new features, Support Engineers can fix low hanging bugs, (button states weird/form is weird, error m…

This is excellent advice. I will add to it: If in a small company you are spending a certain percentage of time/money/effort on support (probably 10-15%), there is no reason for that percentage to be different in a large company. Go through that again with me, please. You've been spending 10-15% of your time listening to customers and providing good service. When you grow, why would you want to provide worse service?…

An organization with 5 customers can babysit each one to make sure they’re happy in 10-15% of their time. An organization with 1000 customers couldn’t do that even with 100% of their time. The only way to maintain a fixed allocation of customer support funding is to make it less high-touch as you grow.

Re: Everyone should read support emails

#142

Post by skiman10 » Mon, Mar 04, 2019, 5:08 PM UTC

Sir_Cmpwn wrote: post #81

Since the article author appears to be the submitter: you should quit Medium. It's not helping your content when a full-page popup obscures it and entices your users away to a sign-up page, then keeps nagging them with popup nagbars on either end of the page. If you need help migrating to another platform, please shoot me an email.

This extension helps Medium become readable again. https://makemediumreadable.com/

Re: Everyone should read support emails

#143

Post by ThomPete » Mon, Mar 04, 2019, 5:08 PM UTC

penagwin wrote: post #117

ThomPete wrote: post #56

When I was at Square the design team would shadow support staff to learn about the kind of problems people are facing and more importantly how people talk about your products, i.e. what they call things, how they try to explain what's gone wrong, what they did to solve it or how they ended up with the problem to begin with. It's the closest thing you can come to true realistic user-testing.

That's not just the closest thing to realistic user-testing, production IS the user testing phase :P

Yup although the sucessful interections with your product is as important for context of where it goes bad.

Re: Everyone should read support emails

#144

Post by Alex3917 » Mon, Mar 04, 2019, 5:18 PM UTC

robbiemitchell wrote: post #64

adwww wrote: post #2

"We can't give devs access to support, because [ZenDesk, FreshDesk, etc] costs 9 gazillion dollars per user"

Exactly. That's why it's helpful to pull the data into a separate UI where everyone can get access to it.

Our product www.fwdeveryone.com is designed for this, if anyone is interested. We make it easy to share specific threads within private repositories for your business for these kinds of use cases.

Re: Everyone should read support emails

#145

Post by jniedrauer » Mon, Mar 04, 2019, 5:21 PM UTC

Starting out in tech support 100% made me a better developer. I've seen the user vs developer tension from the side of the user who deals with broken things every day, hoping that the dev team will eventually fix them. I know how to talk to users now and find out what they really need. And I know how to talk to developers and managers about prioritizing issues.

Re: Everyone should read support emails

#146

Post by TeMPOraL » Mon, Mar 04, 2019, 5:39 PM UTC

duxup wrote: post #112

massivecali wrote: post #94

Earlier quoted context omitted.

I've worked on several projects where the actual needs would get distorted between the customers and the developers in a perverse game of telephone. Each producer or manager feeling the need to reinterpret as they saw fit.

My most recent job the head of the company had a great comment. One of the first things he told me "Our end users are not smart, no matter what anyone tells you. They can barely use a computer. Remember that." He wasn't wrong ;)

Seconding MBCook here; I believe this advice is nonsense.

Truth is, most people are smart enough. If this is a product for internal use, then they might be also extremely motivated, as it happens when handling some piece of software becomes a key element of keeping a job.

Taking the approach of "our users are dumb" makes sense only when you're not thinking about providing value for those users, and instead you're worrying your product could make the wrong first impression (and probably not on users, but the managers), and thus not get bought. It's a valid priority for business, but it would serve everyone better if people were up-front about it.

Re: Everyone should read support emails

#147

Post by evrydayhustling » Mon, Mar 04, 2019, 5:47 PM UTC

lbotos wrote: post #140

evrydayhustling wrote: post #135

Earlier quoted context omitted.

Can you share anything about what you've seen work as far as collecting and broadcasting experience from support to other teams?

1. Invite support to product/eng meetings where you are prioritizing. Add them to the agenda by default so it's natural to expect them to speak. This is huge and helpful. 2. Consider baking in "Support gets a MINIMUM of X things" on priority. Tough conversations will be had, but support/product/engineering will learn how to get what each other need. This one falls apart and "when the going gets tough". Support gets t…

Thanks for this rundown! I'm especially attuned to your (3) and (4); we've run into a lot of CS teams creating "liaison" roles with sales/product/engineering, and even in some cases with finance teams re: categorizing causes for churn and such.

Re: Everyone should read support emails

#148

Post by trynewideas » Mon, Mar 04, 2019, 5:51 PM UTC

lbotos wrote: post #126

Hi, Support Engineering Manager here, who has forgone Dev for a career in Support. In a small company ( As companies grow 2 things that I think are really more valuable: - Support Engineers, These are folks that have commit access and can write fixes, who are focused directly on customers. Don't distract product from new features, Support Engineers can fix low hanging bugs, (button states weird/form is weird, error m…

Some caveats and related advice, having been on the product side and two different customer-facing sides:

Integrate support engineers at least part-time into the product engineering teams. Support engineers who don't know what product is doing can duplicate or complicate product work.

Invest in paying and training the support engineers. Don't pay them well and they'll either transfer to product engineering once they get competent or jump ship to someone else. Poorly trained support engineers who "have commit access and can write fixes" will invariably introduce new bugs that will block product work.

"Don't distract product from new features" is a great goal, but recognize that it's a goal, not a law. There will be fires that product engineering will have to walk into and put out alongside support engineering, especially if your product is more than an small-team app, exponentially if the problem comes about due to systemic design problems on the product side.

It will be tempting to outsource support engineering to save money for in-housing product. Don't. If anything, outsource low-hanging product work before any support work. In-region support engineers make everything about firefighting smoother and customers in every geo will appreciate it.

Incorporate support pain into your dev process. That's not bug metrics—measure the _pain_ your product causes customers. Feature requests are pain. Insufficient docs are pain. Licensing issues are pain. You can insulate product from customers, but don't insulate them from the pain the product causes customers. Use it to help guide the roadmap and you'll find low-hanging fruit that product never considers because, chances are, they aren't interacting with painful parts of the product (otherwise they'd already be addressing it).

Re: Everyone should read support emails

#149

Post by evrydayhustling » Mon, Mar 04, 2019, 5:54 PM UTC

adwww wrote: post #2

"We can't give devs access to support, because [ZenDesk, FreshDesk, etc] costs 9 gazillion dollars per user"

Cost is one issue. Another is that these tools are designed mainly for triaging conversation volume and aren't really designed for PMs, salesfolks, or engineers to extract what they need from historical conversations.

Companies that want to get every team engaged with customer feedback can: (1) Invest in their own data extraction and pipeline to push conversational info into cross-team dashboard. (2) Perform or outsource a bunch of research and report on "voice-of-customer" to the rest of the org. (3) Use active feedback reporting tools like ProductBoard or NomNom to organize (one kind of) customer feedback. (4) Try passive conversation analysis from new tools like frame.ai (that's me!) or scopeAI

Re: Everyone should read support emails

#150

Post by duxup » Mon, Mar 04, 2019, 5:57 PM UTC

TeMPOraL wrote: post #146

duxup wrote: post #112

Earlier quoted context omitted.

My most recent job the head of the company had a great comment. One of the first things he told me "Our end users are not smart, no matter what anyone tells you. They can barely use a computer. Remember that." He wasn't wrong ;)

Seconding MBCook here; I believe this advice is nonsense. Truth is, most people are smart enough. If this is a product for internal use, then they might be also extremely motivated, as it happens when handling some piece of software becomes a key element of keeping a job. Taking the approach of "our users are dumb" makes sense only when you're not thinking about providing value for those users, and instead you're wor…

>Truth is, most people are smart enough

I agree, if we assume they're going to try. It's not a perfect world and IMO most people really aren't trying / putting in the effort on the things we think they should. It's not fair, but if they're not going to try, they're still the person behind the keyboard.