12 ms·

"Do Thinks That Don't Scale" is probably the absolute heart of my (bootstrapped, two-founder) company. Off the top of my head, we: * Manually create pre-con

by Doches 3y ago

"Do Thinks That Don't Scale" is probably the absolute heart of my (bootstrapped, two-founder) company. Off the top of my head, we: * Manually create pre-configured accounts for potential customers, sometimes with up to an hour of entering in their existing data so things look familiar right from first login. * Investigate problems and repair live data, usually just by logging in as a user and using the tools in the product. Can they do this themselves? Sure. Do they appreciate our doing it instead? Oh, hell yes. * Have screen-sharing calls where we walk customers through the process of linking our product with third parties (e.g. OAuth pairing with Square so they can process payments). * Call customers who are want help or advice with _other parts of their business_ that aren't related to our product, but about which we know something. Don't know what you should put in your vendor contracts or what % you should charge for sales commissions? Give us a call; we'll help you out. ...plus probably dozens more that aren't fresh on my mind. We work flat-out to onboard every single customer, no matter how small, because word-of-mouth is our only growth channel and delivering a surprisingly human onboarding/support experience is the best way I know to generate great referrals. It doesn't scale, but it's also probably our main growth driver. It'll work until it doesn't, I guess, but so far doing things that don't scale is how we scale.

dclowd9901 3y ago
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...
throwawaysleep 3y ago
> Investigate problems and repair live data, usually just by logging in as a user and using the tools in the product. Can they do this themselves? Sure. Do they appreciate our doing it instead? Oh, hell yes. This is definitely one that doesn’t scale as eventually they don’t allow devs to see prod data, so using user accounts is a no go at my org for that reason. Makes things infuriating for both clients and customer support.
- Doches 3y ago
  Not being allowed to see production data (or even in some cases see production!) was my greatest frustration in my last corporate job. But to be fair, keeping engineers off the live data was…pretty non-negotiable at most customers. Which leads to some pretty boring days onsite, when “onsite” means “in the SCIF”
  - dmoy 3y ago
    > SCIF Though there's a big sliding scale there, between "not allowed to look at prod user data for privacy/etc reasons" and "the giant black hole of nothing-comes-out" in a SCIF.
- closeparen 3y ago
  If “devs” can’t have access to production data then they can’t be responsible for production issues, simple as. I would say 95% of my intellectual horsepower at work goes into queries and analysis of production data tables, event streams, and logs to investigate issues or confirm key invariants are holding. Production is infinitely more creative than anyone sitting down to write unit tests. Organizations refusing to learn from it, as a matter of policy, either have incredible confidence in their testing and formal verification regimes… or much more likely don’t give a shit about correctness.

by Doches 3y ago

dclowd9901 3y ago

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

throwawaysleep 3y ago

> Investigate problems and repair live data, usually just by logging in as a user and using the tools in the product. Can they do this themselves? Sure. Do they appreciate our doing it instead? Oh, hell yes. This is definitely one that doesn’t scale as eventually they don’t allow devs to see prod data, so using user accounts is a no go at my org for that reason. Makes things infuriating for both clients and customer support.

Doches 3y ago
Not being allowed to see production data (or even in some cases see production!) was my greatest frustration in my last corporate job. But to be fair, keeping engineers off the live data was…pretty non-negotiable at most customers. Which leads to some pretty boring days onsite, when “onsite” means “in the SCIF”
- dmoy 3y ago
  > SCIF Though there's a big sliding scale there, between "not allowed to look at prod user data for privacy/etc reasons" and "the giant black hole of nothing-comes-out" in a SCIF.
closeparen 3y ago
If “devs” can’t have access to production data then they can’t be responsible for production issues, simple as. I would say 95% of my intellectual horsepower at work goes into queries and analysis of production data tables, event streams, and logs to investigate issues or confirm key invariants are holding. Production is infinitely more creative than anyone sitting down to write unit tests. Organizations refusing to learn from it, as a matter of policy, either have incredible confidence in their testing and formal verification regimes… or much more likely don’t give a shit about correctness.