Holistic healthcare for products, docs, support

September 21, 2022 · writing

3 // Customer support is like surgery: sometimes urgent and necessary, but never desirable as a first line of defense, with very high costs to both yourself and your patient.

2 // Good documentation and tutorials are preventative healthcare, like chiropractic: catch and cure the problems early, before they’ve escalated into acute frustration.

1 // Empathetic product design is like robust wellness and health, avoiding a whole universe of potential problems and altogether averting the need for treatment.

Applying the wrong level of treatment is annoying your customers and costing/slowing your business.

Just as an interventionist doctor might leap to solve every ache and pain via invasive surgery, some companies wield customer support like a bonesaw to solve every symptom while leaving the deeper root cause unresolved. And the opposite bias occurs also, with folks sprinkling herbal tea on something that really does warrant a more urgent and personal response.

(Reminds me of an old zen koan: Asked to describe journey toward enlightenment, first monk says, “Mind is like a mirror accumulating dust; every day, polish the mirror.” Second monk replies, “No mirror, no dust, no polishing.” Second monk gets the promotion.

This framing came out of our team’s discussion while getting our beta reading software ready for full self-serve. After months of manually onboarding every user, this milestone forced us to go through every little concern and confusion that we’d previously answered in person, and to decide on the “correct” level of treatment for it.

In some cases, we’d write up a lengthy, in-depth help doc only to realize that the whole article was just compensating for sloppy product design. Wherever possible, we improved the product such that we could safely delete the doc. (In a few cases, we’ve left the doc as a temporary crutch.)

In other cases, documentation actually is the correct layer at which to solve an issue, in which cases we’ve integrated the knowledgebase directly within the product itself.

Two situations in particular have seemed to demand a doc-native approach:

1 // Docs are best for examples, best practices, and emotional reassurances to guide folks through a “scary” task, such as sending out a rough manuscript to the very first beta readers:

2 // Docs are best for multi-step checklists/processes/guides for stuff that must to be handled outside of our product’s workflow, in adjacent tools, such as instructing an author on how to cleanly format their master manuscript:

Apart from that, I’ve been pleasantly surprised to see that we’ve mostly been able to solve stuff at the product level. (And we’re ready with customer support to identify where we’ve failed.)

For now, we’re treating customer service requests as a root cause trigger: we solve it for that person using immediate surgery, and then ask ourselves whether that issue is rare enough to justify leaving it as a hands-on support issue, or whether we can solve it more permanently at the product or docs layers.

(For context on the above image, Marc is a cofounder – we expect to start shifting support to a non-founder teammate in a few months, after we’ve worked through enough support requests ourselves to identify the majority of what ought to be solved at the docs or product levels.)

Beyond being (hopefully, eventually) better for our users, this seems like a sensible guiding principle for small teams that need the support burden to scale sub-linearly to the number of customers. (Logarithmic scaling of support would be nice, and seems achievable with this approach.)

← all writing