Hacker News Reader

Comment by andrewfong | Hacker News Reader

A more subtle aspect of customer service here is that, as the dev or PM responding to the customer, you have a lot more power to give the customer what they want.

A BigCo can hire a lot of CS people but the best they can do sometimes is "we hear you and we'll pass along your feedback".

View on HN

Alas, you’ve found the reason this won’t scale. Doing customer support as the CTO is a superpower (up to a point!) for both user growth and product design. But there’s going be to come a point where we have to hand some portion of support over to a dedicated support team, and no matter how well we train those folks they’re just not going to be quite as empowered and effective. The longer I can kick that can down the road, though, the better!

(At least for the business. My sleep schedule would improve amazingly!)

You want Support Engineers who are up to speed on your code review processes and standards and given access to commit "straightforward" bug fixes. They exist :)

https://gitlab.com/gitlab-org/gitlab/-/merge_requests/125249 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/131316 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/131469 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/130988 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/132806...

From there, you need to build a culture that is welcoming of "strangers" contributing code. You get these two things, you get nits and gotchas fixed directly from pain points customers are having, while product engineering is (mostly) focusing on feature dev.

This is simple support tiers.

Tier 0 are effectively secretaries who can file structured info around issue.

Tier 1 are dedicated support people who can follow scenarios and guide customers through the product.

Tier 2 are what you call "support engineers". They know the product, features, code, upcoming features and so on. For an in house product they are capable of making straightforward bugfixes.

Tier 3 is sometimes called "vendor support". For an in-house product this is effectively product development team.

As you can see, good supports bleeds into or blends with product development. This is how you get support answers like "this feature is planned to go live Y24Q1, but you can sign up to beta in exchange for feedback" or at least "This is not supported, but you can use features x and y to achieve similar result", instead of "Sorry, such workflow is not supported"

Reply on news.ycombinator.com