Don’t make your problem the customer’s problem

Over the years I’ve been reading and thinking a lot about product development. Slowly I’ve come up with some rules to guide the product development process.

There’s plenty of platitudes out there for building great products but you can’t live by them all.

One rule I’ve been pushing at Mindscape in recent years is simple: Do not solve our problem by making it the customer’s problem.

Let me give an example of this rule being applied & broken. Take Raygun.com – our crash reporting service. When an error occurs in your software it’s sent securely to our server so we can notify you, extract data about the error and generally help you make your software better, faster.

We do not enforce a rate limit when sending errors. However all competing products appear to have rate limits.

Who benefits from rate limits?

The company providing the product. They remove their need to scale the service to handle customer load.

Who loses?

The customer. What if the error is about the billing system being down is getting dropped by the rate limiter? What if there is a big spike in errors but everything looks normal because the customer was already sending data close to the rate limit?

How confusing, unclear and problematic this could be for the customer.

Why do this?

In this example, everything I can find suggests it’s to manage the server load the service needs to deal with. Solving load problems can be difficult. It’s a classic case of “solving” a product problem by turning it into a customer problem.

Solving the root issue

In this example, we designed the back end of Raygun to ensure that we can take a vast number of errors coming in. We then made sure that the architecture didn’t suffer from noisy neighbors – if one customer is pumping a million errors per hour into the system, another customer does not get degraded performance. We had to bake this design in from the start and it did take some thought and time to get right. The winner here is the customer but by having our customers win, we also win.

Another benefit in this example is that a service like Raygun can then send real trend data to the customer about their errors — all their errors, not just a sample of them. They see the real world view of their software problems.

That’s just one example

I’ve used Raygun as an example here because it’s a problem we actively tried to not put on our users. I encourage you to look at your own software and start asking the question: Is our solution to this problem to make it a customer problem?

Everything in moderation

Am I saying our products are perfect? Absolutely not. Here’s some points to consider:

• Just because a customer wants a feature doesn’t necessarily mean it’s a problem you’ve moved onto them.
• Opinionated software can often seem the most resistant to solving customers problems, however it’s often a case that the customer needs more education on why you product behaves the way it does. Often it’s for a very good reason that may not be obvious initially.
• Software cannot serve too many masters without becoming unusable to everyone. Make sure you’re sticking to your actual intended goal of the product.
• Shipping is important. Don’t use this rule as an excuse to constantly put off shipping. As long as you note down that you should resolve an issue in a future version it’s OK, nothing is ever perfect. Remember: if you’re not embarrassed by your first version, you released too late.

Consider that every problem you outsource to the customer is a potential road block to adoption and should be resolved as soon as possible.

While you’re here, if you’re a software developer, why not signup for Raygun and see if it can help you in building better software.