7 ms·

What you’re describing here is _good customer service_, which basically doesn’t scale at all ever (at least in any automated way). You provide more tools to exp

What you’re describing here is _good customer service_, which basically doesn’t scale at all ever (at least in any automated way). You provide more tools to expand the capability of CS, but at some point, you simply just have to hire more and more CS people. This isn’t a knock by the way. Good customer service makes a customer feel like there’s someone just waiting at the company to help them. Kudos to you for providing that experience. So while these aren’t great examples of “doing something that doesn’t scale (with the eventual goal of scaling)”, it’s a great example of “doing something that doesn’t scale (to provide a better product)”.

supportengineer 3y ago
You can also give the tools directly to the customers, and you can bundle/package the tools into future versions of the product. A common pattern is to have a public git repo and the customers can git pull to get the latest versions of the support tools.
- Doches 3y ago
  Shipping tools as a git repository sounds delightful, at least to my engineering-minded heart. So painless! Free versioning! Rollbacks! If we were in the devtools business I would certainly consider that. Sadly, though, owners of small retail businesses tend not to be as comfortable with version control as one might hope…
BoorishBears 3y ago
I disagree: if you're a good product owner, it will aid with the goal of scaling. For example, when you're sitting there walking them through something they could do alone, are you just playing back some script, or are you getting an understanding of where they went "aha!" and making note of how you can embed that aha moment into the product itself?
- Doches 3y ago
  You’ve found me out! Not only is it excellent customer service, it’s also priceless market research that I would be lost without. Side conversations during calls like that have led to more improvements and features (and in one case an entirely new side product) than I can possibly count.
ssharp 3y ago
Based on every mega-scale consumer tech company, the best way to scale customer service is to make it as useless and frustrating as possible.
- mattmaroon 3y ago
  Apple would be a notable exception. As would Amazon. I think you’re referring specifically to Google and Facebook, and you’re right. I think the big difference is the amount of profit per customer. Google and Facebook make a small amount from a large number of people so it makes sense that they could not profitably scale customer support. In the instances where they make a large amount of money off of a small number of people, mainly ad sales, their support is much better.
  - avgDev 3y ago
    I at least don't expect anything from FB. I must also say Uber's CS is absolute garbage. I just cannot believe how bad they are. I have been unable to use uber for weeks and have been reaching out to them non-stop every few days. It is like speaking to a brick wall.
    - arcanemachiner 3y ago
      Have you tried social media? Companies can be strangely responsive on those channels. Try reaching out to their Facebook or Twitter/X profiles.
      - avgDev 3y ago
        I don't use X but might try facebook.
  - mfitton 3y ago
    I've had consistently bad experiences with Apple support.
  - eichin 3y ago
andrewfong 3y ago
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".
- Doches 3y ago
  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!)
  - lbotos 3y ago
    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/125249 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/131316 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/131469 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/130988 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/130988 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/132806/diffs 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.
    - friendzis 3y ago
      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"
balaji1 3y ago
Doing things manually for a while might be natural to some builders/hackers. Customer service is one such example where many builders are willing to go above and beyond. So maybe the OP does not have to read too much into the PG quote.
richardw 3y ago
I think where it helps with scaling is that they’re very involved in all the pain points. None are hidden by client silence. Then they can build this learning into the product. Simplify, fix UI, add, remove. That digs you out of the daily effort trap.
ska 3y ago
> which basically doesn’t scale at all ever It basically scales fine, the problem for companies trying to bump margin is it's roughly linear with customers...

supportengineer 3y ago

You can also give the tools directly to the customers, and you can bundle/package the tools into future versions of the product. A common pattern is to have a public git repo and the customers can git pull to get the latest versions of the support tools.

Doches 3y ago
Shipping tools as a git repository sounds delightful, at least to my engineering-minded heart. So painless! Free versioning! Rollbacks! If we were in the devtools business I would certainly consider that. Sadly, though, owners of small retail businesses tend not to be as comfortable with version control as one might hope…

BoorishBears 3y ago

I disagree: if you're a good product owner, it will aid with the goal of scaling. For example, when you're sitting there walking them through something they could do alone, are you just playing back some script, or are you getting an understanding of where they went "aha!" and making note of how you can embed that aha moment into the product itself?

Doches 3y ago
You’ve found me out! Not only is it excellent customer service, it’s also priceless market research that I would be lost without. Side conversations during calls like that have led to more improvements and features (and in one case an entirely new side product) than I can possibly count.

ssharp 3y ago

Based on every mega-scale consumer tech company, the best way to scale customer service is to make it as useless and frustrating as possible.

mattmaroon 3y ago
Apple would be a notable exception. As would Amazon. I think you’re referring specifically to Google and Facebook, and you’re right. I think the big difference is the amount of profit per customer. Google and Facebook make a small amount from a large number of people so it makes sense that they could not profitably scale customer support. In the instances where they make a large amount of money off of a small number of people, mainly ad sales, their support is much better.
- avgDev 3y ago
  I at least don't expect anything from FB. I must also say Uber's CS is absolute garbage. I just cannot believe how bad they are. I have been unable to use uber for weeks and have been reaching out to them non-stop every few days. It is like speaking to a brick wall.
  - arcanemachiner 3y ago
    Have you tried social media? Companies can be strangely responsive on those channels. Try reaching out to their Facebook or Twitter/X profiles.
    - avgDev 3y ago
      I don't use X but might try facebook.
- mfitton 3y ago
  I've had consistently bad experiences with Apple support.
- eichin 3y ago

andrewfong 3y ago

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".

Doches 3y ago
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!)
- lbotos 3y ago
  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/125249 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/131316 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/131469 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/130988 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/130988 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/132806/diffs 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.
  - friendzis 3y ago
    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"

balaji1 3y ago

Doing things manually for a while might be natural to some builders/hackers. Customer service is one such example where many builders are willing to go above and beyond. So maybe the OP does not have to read too much into the PG quote.

richardw 3y ago

I think where it helps with scaling is that they’re very involved in all the pain points. None are hidden by client silence. Then they can build this learning into the product. Simplify, fix UI, add, remove. That digs you out of the daily effort trap.

ska 3y ago

> which basically doesn’t scale at all ever It basically scales fine, the problem for companies trying to bump margin is it's roughly linear with customers...