Bad product decisions come with the label “just this once, just for that customer.”
Building one-off workarounds or features for important customers is the same as building temporary bridges for each driver to access their river-side home. A single, permanent solution to a problem is far more desirable rather than wasting bandwidth and resources on constantly providing your customers with a temporary patch.
Two metrics every startup needs to obsess over are growth and churn. You want impressive growth that isn’t undermined by caustic churn. Churn is a complex concept, but regardless of how you measure it (churn of users, activity, or revenue), keeping it low is crucial.
When you’re a new company trying to win your first customers, the loss of any one of them hurts. If you’re charging for your product, the first loss of a paying customer has all the painful elements of your first break-up. So, when a customer asks for special treatment, be it a feature or a favor, it’s incredibly hard to say no. But being accommodating to everyone is a slippery slope. These requests have impact beyond your customer-facing team. They go to the heart of your product development decisions, feedback loops and engineering bandwidth.
Different types of customer requests
There are lots of reasons why a customer will ask you to make exceptions for them. Some of these are easy calls: discounts, refunds, custom pricing, extended trials, feature access. Bargaining and bartering are part of any business, and these requests are usually straight yes or no answers that don’t require much time or effort from your team. Keeping, or losing, a customer here is a matter of a few simple decisions.
More complex requests often involve things like missing or yet-to-be-finished features. If you’re a product-driven startup, it can be difficult to say no when a customer identifies a known shortcoming in your product. Often it’s a feature you should have built already, or one you currently planning to build. When an important customer – whether high paying or high profile – recognizes this shortcoming it hits a nerve, and can cause knee-jerk re-prioritization, but we’ve talked about that already.
The real tricky requests are one-time technical workarounds, often seemingly simple ones. You can anticipate the range of reactions a “no” gets: from acceptance to understanding to disappointment all the way through to cancellation threats, or actual churn. For a startup fighting for every customer, particularly ones willing to pay, it’s tempting to say, “Sure, but just this once.”
“No” is often in your best interests
Here’s why saying yes to these special “one-time” requests is not your best choice: it’s a temporary bridge.
What do I mean by that? Well, bridges are meant to be permanent solutions used by all road users. In this sense they are like a product feature. Temporary, one-time workarounds are analogous to a bridge that you build and disassemble every time it’s needed.
Once you say yes to this kind of solution, even if you tell the customer it’s a one-time thing, it becomes harder to say no because there’s now a precedent. While you may think you’ve solved a customer’s problem and kept a customer, in reality you’ve set an expectation that sets the customer up for bigger disappointment later.
Setting bad precedents
Set realistic expectations around the actual capabilities of your product.
The conclusion of too many “just this once” answers is that you now find yourself doing multiple temporary fixes, that take up more and more of your engineering time, to solve a problem you want, and need, to fix permanently. At best, you’re investing time in keeping your customers, which means you’re no longer SaaS, you’re a consultancy. But more likely, you’re building temporary fixes that are weak, unstable and vulnerable to failure. Worse still you’re robbing feedback from your product team, hiding them from the true product shortcomings.
Instead of saying, “Yes, just this once” the harder but better plan is to say something like, “No, our product doesn’t do that now, but it’s definitely on the roadmap” or “No, this is not something within the scope of our product.” This will disappoint some customers, and you might lose some customers with either answer. But it’s better to set realistic expectations around the actual capabilities of your product than to allow customers to become dependent on your engineers. There’s opportunity in difficult conversations: it’s a chance to build stronger customer relationships and improve your product in the long run.
Features that scale
What about doing things that don’t scale? This is important. Some incredibly successful startups cite the value of early efforts that wouldn’t scale in the long run, like Product Hunt’s hand-written notes to early loyal users (pictured above). As I read it there are two types of activities here: customer relationship building efforts like handwritten thank you notes, or personally emailing new signups; and technical efforts that inform future product plans, such as helping people install your product. Once you’ve understood and validated the need for a feature, not scaling it is going to underserve your customers and hurt your business. That’s not the goal of doing things that don’t scale.
As a software company, you should be building a product that will bring in the right kind of revenue. That means building a product you can sell over and over at scale. This is the key to being a solution for your customers’ problems and the key to faster growth. You won’t achieve the right kind of user or revenue growth by building a custom solution or service that is unique to each of your users.
Saying no to the slippery slope of temporary patches may feel painful in the short term, but it forces you to focus your engineering time on a better, scalable and sustainable solution. Building a feature instead of a patch will help you win and retain more customers in the long run.
You’ll build bridges for your biggest and best customers with good intentions, but the impact this has on your product will come back to bite you. You’ll never build a real bridge, when you’re too busy hacking together temporary ones.
Comments