As I wrap up my second year of taking a break from a traditional career, I’m meeting with some entrepreneurs who are building interesting companies. I thought it would be beneficial to answer some of the commonly asked questions that I get in a series of blog posts over the next few months. We are also hosting a Pop Up Business School in February, so the topics of starting and growing businesses are very top-of-mind for me.
We work so hard to create a great product, and then work just as hard to sell it. But then one day we wake up and realize that the customer is asking us for more than we can—or want—to deliver.
How do we say no to a customer? When do we say no to a customer? How do we even decide if we should say no to a customer?
Start with Context
It’s important to remind yourself, and your team, that when a customer asks your company for more, it means they are finding value in your product and they also believe you can deliver additional value. That’s a very positive signal for your business.
Often, we forget that and focus solely on the pressure a customer can put on our teams. Keep in mind that it’s good when you win customers, it’s good when those customers value your product, and it’s good when they want you to do even more for them. Likewise, it’s bad when a customer does not value your product, when they don’t speak to you, and when they quietly send you a cancellation notice.
Even the most boisterous customers are better than the quietest customers who are on their way out. The request you are evaluating is a strong positive signal for your company.
You can think of your customers on a spectrum. On one end you have customers who have purchased your product and don’t even use it, you never hear from them, and eventually they will cancel. On the other end you have customers who rely heavily on your product for a core part of their business (such as paying their employers, serving their own customers, etc). These customers will push you hard to do even more for them. Don’t be upset when they pressure you for even more value.
The 50% Rule
A customer request for more functionality, expanded services, or some other seemingly “custom” request is a wonderful opportunity to test it against your short- and long-term plans for your product.
I have heard it said that bank tellers are trained to spot counterfeit money not by learning all of the ways to make fake bills, but rather by constantly handling and inspecting the real thing. Product management is like that. The better you know your own product, how customers use it, and your plans for expanding it, the easier it will be for you to spot genuine product requests that fit well with your plans—and those that don’t.
It helps to properly articulate the customer’s request for new product functionality. When you get a request, don’t assume you or your team fully understands it. Spend a bit of time discussing with the customer and even mock up the feature, report, or capability. This helps you be certain you are identifying their need, but even more, you are creating something you and your team can compare to your current product and future plans.
My general rule is that customer requests need to have at least 50% overlap with the product roadmap. If it is less than 50%, then we would be essentially throwing away over half of the work we would be putting in to the project.
On the flip side, if a request has more than 50% overlap, then I would feel like we would be advancing our product and doing it without needing to raise capital to do so—and without the associated dilution that comes with selling part of the company. It is a beautiful thing when a customer will pay you to extend your product in a direction that you planned anyway.
Two Examples
The initial product of my company was an online portal for enrolling employees in their insurance benefits, primarily health insurance. One request that I agreed to do early on was to extend the software to enable a company to pay their bills online. I felt like enrollment and billing fit well together, so we built an e-billing system for one of our first customers. It worked great for us and our customer, and those products and customers are still generating monthly recurring revenue for the company.
Another request I got early on was to create an imaging system so the insurance company could scan their documents and associate with their customers. While I saw a potential future use for this product extension, after several discovery meetings I determined that we would need to work with third-party hardware providers and that our skill set was not aligned. I passed on this request and over the years saw many companies try to fill this request with little success.
It was helpful to have a clear product roadmap for our first product: electronic enrollment of benefits. As requests came in, we held them up against our product roadmap, and if there was 50% or more similarity, we would often take them on. In the case of e-billing, to determine the request’s fit, we literally printed one of our enrollment reports, which detailed all of the members enrolled in a benefit, and then taped it to a wall next to a paper insurance bill. They looked almost identical! They were two sides of the same coin. Our decision to move forward with the customer’s request was a no-brainer.
Don’t Skip the Obvious Questions
Do you like the customer? When you do custom work for someone it will require extra time. If you have issues with the customer, then you will not want to devote that extra time and the project will suffer.
Some of the best work my company did in extending our product happened with customers that had become good friends. Be wary of agreeing to time-consuming requests for customers that do not respect your company. However, if you have a special relationship with a company, if they are a good reference and help you get new business, and you can price it properly, then it may be a good opportunity.
On the flip side, never agree to do a bunch of extra work for a customer who may not be able to pay you. Make sure they’re financially sound before you say yes to additional work.
A Framework for Saying No
We focus so much on getting to yes that we forget to develop our skills at saying no. We need to hire our first team members, we need to build our first product, we need to raise some money, we need to sell to our first customer. A long string of yeses are required for survival and growth.
But sometimes we need to say no.
If you determine that a custom request needs to be turned down, there are a few steps to follow. Here is my framework for saying no to custom requests:
- Remind your team that this is a valuable customer and their use of your product is what makes you successful.
- Communicate to your customer that you value them and you are thankful that they see such value in your product that they would ask for more.
- Share with them how much time and effort you have put in to evaluating their request. Customers want to be heard and respected, so this step is key to developing the relationship beyond this situation.
- Reiterate your long-term product plan.
- Share with them how their request contains good functionality, yet it doesn’t overlap with your product plans in the near term. It may in the future, or it may come about through some partnerships or the use of a third-party custom software partner.
- Offer a way to solve a portion of the need through some upcoming functionality and agree to reevaluate the request in coming product roadmap planning sessions.
- A great outcome of a no is to pull the customer even closer to your product roadmap process, so be sure to offer (and follow up on the offer) to include the customer in strategy sessions, early looks at draft product roadmaps, early adopter programs, early adopter customer advisory groups, etc.
Large companies grow large because they know how to survive. If you are having this conversation with a large customer, they will respect you when you make tough decisions that ensure your company continues to grow. They instinctively know that if you make poor short-term decisions and your company suffers, they will ultimately suffer by not having a strong long-term partner.
In all communications, be respectful, kind, offer follow up, offer ongoing communication, and solve as much of the problem as you can. And when a no is needed, deliver it in person, face to face. It’s an opportunity for you to learn more about how your products create value, and a chance to practice delivering a healthy no when needed.
Soon after a no, look for an opportunity to serve the customer in a simple and beneficial way. Create a new report for them and surprise them in your next software release, or look at the list of requests they have in the regular queue and knock a few of them out faster than agreed. You want to incrementally increase the value you bring and be a good partner. Even when you cannot make the big leap they are requesting at the time.
I once had the CFO of a huge insurance company pull me aside after a presentation to their executive staff. He encouraged me to learn to say no to his company. He said he saw smaller companies get crushed by the never-ending demand of custom requests. Over the years, he saw many companies go out of business by trying to say yes to every one of their requests, and the only way to survive winning them as a customer was to learn to stay focused on your core product. It was a great bit of wisdom and helped me guide our decision making over the years.
Turn Custom Work Into Sellable Products
When you do agree to extend your product for a customer, be sure to include the ability for you to promote their use of the product. A simple example is to draft a press release and related quote from the customer as part of the deal. Once the new capability is delivered, the press release automatically goes out.
You can also create an early adopter group around the new capability. I would always try to set a small group number of 5 to 10 early adopter customers for the new functionality. So even though it may have been a custom project for one customer, we would bring in a few additional customers to help in feature design, testing, and rollout. This then creates a sense of excitement and momentum around the new offering. It also creates a built-in set of client testimonials. And most importantly, it allows your team to design something that can be used by a broad set of your customers from the outset.
“Yes” and “No” Are Stage-Dependent
I started my software company in June of 2000. That was three months after the infamous dot-com crash. Venture capital and private equity investments dried up for several years after that, along with the recession that followed the 9/11 attacks.
To bootstrap our company, I spent a ton of time with our few early customers and searched for projects that aligned with our core long-term product vision. When we found alignment on one of their key business issues, we negotiated pricing and terms to extend our software.
Because I was selling to large and established insurance companies, I knew they had plenty of cash. Cash was not their issue. But cash was my issue. While I always maintained a theme of monthly subscription to our software platform, I often negotiated substantial up front cash payments in exchange for taking on special projects. I only did it for customers that I knew respected our company and would be good references for us.
I often signed us up for very big new features in aggressive timelines, as I knew how strong our engineering and product team was. What the large insurance company got was rapid software development on key business issues. What we got was cash, with no equity dilution, and access to more customers from the reference.
As we grew, I tapered these types of deals, and by the time we went public in 2013, we had almost entirely eliminated custom projects and developed an ecosystem of third-party companies to handle customer requested extensions. The key is to know what stage you are in, what your long-term product vision is, and which customers respect your company.
Summary
When a customer asks you for more, immediately pause and be thankful that you have a customer, that they find value in your product, that they believe your team is capable of adding even more value, and you have someone who will help fund further product development. Then test the request against your product plan. If it complements your plans, then get creative and make it work. If it contradicts, then use it as an opportunity to clarify your plans with your customer. Every encounter is an opportunity to help your company be more successful.