Jason Fried over at 37signals
mentioned
today that he gets a lot of questions about “growing the business”: why aren’t they, when will they, etc.
They don’t plan to. Not in the traditional sense, by hiring. What’s important here is that they have oriented their business, and especially their products, to succeed without requiring additional head count. This means:
- fostering self-service to minimize personnel required to do routine account service (billing, signup, cancellation, etc.),
- improving usability and intelligibility to minimize personnel required to perform technical support,
- measuring their ability to keep customer support workload down even as enrollment grows.
I happen to work for a major medical device manufacturer, and I don’t think I am revealing any secrets when I say that while we talk a good game about fostering self-service and making our products easier to use and just plain figure out, we’ve nearly doubled our sales force and our customer service head count has grown significantly. It is nice to “show commitment to customer service,” but this is an expensive way to do it. I suspect we and other manufacturers (and our customers) would be much better served by an orientation similar to that of the 37signals folks.
I suspect that the groups that conceive of, design, develop, and build our products do not work toward metrics that encourage the reduction of customer service load, except when it comes to specific problematic features of already-released products. As Joel Spolsky once put it, “you get what you measure.” We are getting a product every 18 months (metric: schedule) that does more than its predecessor (metric: can we sell it) and is more reliable (metric: returns per thousand units shipped), but isn’t necessarily easier to use, more appealing, more pleasurable to use, or requiring of less support.
Here’s where the story gets interesting. Were we to add the missing metrics and do nothing else, suddenly these products (which dominate their market) would be scoring very poorly internally. There would be great pressure to stop using the new, bad metrics, because they wouldn’t seem to have a relationship to revenue, which would probably remain high. But adding metrics such as total cost of support per thousand units shipped would solve the second problem : you can’t solve a problem (the first problem, the real problem) until you measure it, which is a form of admitting that it exists at all.
Were we to add the missing metrics and suffer a while with unhappy numbers, sooner or later people would start asking what could be done about them, and one or more of three basic responses would emerge:
- Distort the system
- Distort the numbers
- Improve the system
Distortion of the system might occur were we to outsource a component of our support functions to lower its cost. Such a move would result in lower total support costs for any product shipped thereafter, but not because the product improved. Something to watch out for.
Doing away with the “faulty” metrics would be an extreme form of distorting the numbers. A more likely form would be to adjust what costs make it into total cost of support, or narrowing the timeframe over which that total is recorded and/or projected. Perhaps initial training costs wouldn’t be included, or only support costs in the second, third, and fourth years (once the less certain users shake out) might be tallied. In either case, we’d be back to denying the problem rather than measuring it.
Improve the system? Lets, please.
