How to Avoid Building Custom Features for One SaaS Customer
There are many smart alternatives to "no" that won't kill your roadmap.
TL;DR - If big customers ask for you to build specific features, simply telling them “no” isn’t the best strategy. It will hurt customer satisfaction and, eventually, cause churn. Instead, this post outlines several strategies to keep big customers happy with you while you execute on the best roadmap for your company and your customers overall.
A common problem in SaaS is when big customers or sales prospects demand that you build specific features, often with the implicit or explicit threat that they won’t buy or renew without those features.
These requests put PMs in a tough spot: you don’t want your company to become the outsourced development shop for a few customers’ idiosyncratic workflows, but you also don’t want to offend a good customer and don’t want to be responsible for your company losing short-term revenue. And you don’t want to lose the confidence of your Sales team or your CEO who’re on the hook for that short-term revenue! What to do?
One approach to these requests is to take a Steve Jobs approach and flatly refuse. We’re all familiar with entrepreneurs who proudly ignore customer requests, using justifications like this:
This meme has a core of truth: most customers have short-sighted desires that won’t help their (or your!) company’s best interests in the long run. Building exactly what customers ask for will incrementally drive your company into irrelevance because you’ll never be able to carve out enough engineering time to work on truly transformative progress that few customers ever ask for.
But they’re still your customers. You should love them! Even if you don’t love them, they pay the bills. It’s not your job to “take orders” for features, but it *is* your job to convince your customers that your roadmap is a good solution for their company. Doing this convincing requires more flexibility and EQ than a reflexive “no”.
When I led Product at Cantaloupe, we had a lot of large, opinionated customers who were never shy about telling us what they wanted. Feature requests came up in many renewal discussions. Every year we had big customers threaten to leave over a feature they wanted ASAP. We sometimes had customers send us specs and screenshots of features they wanted us to build! And of course our Support and Customer Success teams were deluged on a daily basis with feature requests—many of which were too obscure or off-target to make it onto our roadmap.
Over many years of practice, our team got *very* good at handling these situations. Below I’ll share a few of the techniques we used to keep customers happy while keeping the roadmap mostly on-track.
To avoid a “sales-defined product roadmap”, build mutual trust and respect with your Sales team
PMs should be working hand-in-hand with Sales to understand feature requests and to figure out the right way to respond to those requests. But in some companies, the Product and Sales relationship is dysfunctional. For example, salespeople may commit to features and expect Product and Engineering to deliver them.
As a PM, you don’t want Sales free-lancing and defining the product roadmap by promising features to customers. But you also need to understand where Sales is coming from. If a feature request is important enough to get on your radar, there’s a salesperson who’s working with that customer whose commission (and maybe their job too!) might be at stake if that feature request isn’t handled well. So it helps to be empathetic and creative. Your goal is to help Sales to stop promising features by showing them a better way to achieve what they want (to close deals) without always needing to promise features to get deals done.
I’ve found the best way to achieve this is to work in parallel. On one track, improve communication and trust and help the Sales team see you as a resource that can help them close more business and to avoid deals that will fall apart later. On the other track, you must communicate clear guidelines about how Sales should talk about the future with prospects. The two tracks reinforce each other; if Sales sees you as a benefit, then you’ll have a much easier time getting them to stop promising.
Here’s a few practices that worked for us:
PMs should attend Sales meetings at least monthly. The more the Sales team sees you, the more you’ll hear in advance about deals with roadmap impact. Deals for medium-size and enterprise customers usually take 3+ months to close, so that gives you time to hear about it if you’re in the Zoom or the room. A good excuse to attend is to ask what feature requests, competitive issues, and customer complaints they’ve been hearing. Also you can talk through what’s in the next release or discuss what’s just shipped.
Tag along on sales calls. Especially with large/enterprise customers, it can really help the salesperson if a sales-savvy PM can attend to give demos, answer questions, and otherwise show the customer that they’re important enough to justify “a product executive from HQ” being on the call or in-person visit. Some salespeople can be hesitant, thinking the PM will screw up their deal. It helps to find a salesperson who isn’t hesitant, and to help her close a huge deal. Others will notice. The more you’re viewed as a close-assister, the more Sales friends you’ll have. These calls and visits are also great opportunities to talk with customers, to gather user feedback, to extract competitive intelligence, etc.
Don’t write features and dates into contracts! Work with your sales team to never put specific feature deliverables (and, especially, dates for those) into written or even verbal commitments. Doing this puts cashflow at risk and removes roadmap flexibility which may be needed to close other deals. Also, I’ve also been told that an accounting rule prevents recognizing revenue from contracts that demand future deliverables. Don’t do this! Instead, work with Sales to come up with alternatives. One thing that worked for us was promising a customer that we’d work on their request “first”, meaning it’d be the top priority of our team starting X weeks from now. Or that it’d be our third priority after feature A and B (that the customer also wanted) were shipped.
PMs should encourage (and later, require!) salespeople to call them before promising unreleased features to a customer. This is the main thing you want from Sales: before promising anything that hasn’t shipped yet, they must check with you first. Over time, try to make it a rule. Caveat: if you always say no, they won’t call you! Try to figure out how to help the salesperson accomplish what they want, which is to close the deal. Finding creative ways to help them achieve that—and to avoid saying no—is what the rest of this post is about.
Tips for Handling Feature Requests from Important Customers
Once you’re on the same page with Sales, now you need to figure out what to do about the customer’s request. Here’s some techniques that have worked well for me and my teams in the past.
Generalize features. You can often take "custom" requests from top customers and generalize them into something that applies to a wider customer base. If you have to do something for your largest customer, try really hard to figure out how to make it add value for everyone else. If your top dog customer pushes back on generalizing, it often helps to point out that features built for one customer never work as well as features built for everyone that have more eyeballs ensuring quality and more users clamoring for improvements. For this reason, smart customers often won't want custom features—as long as you gently educate them about why custom features are bad for them too.
Know your customer directly, and especially their decision-makers. You should be in regular, real-time (calls and ideally visits) contact with your top customers. Don't wait until they call support to complain! You should know what keeps them up at night. Get to know the decision-makers who actually drive upgrades and cause churn at that customer. Learn their top business problems, not just their team's minor gripes with your product this week. Know how you can help make your champion look smart and get promoted!
Solve problems, not support tickets. Uplevel the discussion with the customer. Understand why they're asking for a particular feature or report or change. See if they've tried other ways to solve the problem. Understand the business process that led to the support ticket. Understand if this is a really big deal or only a minor annoyance. If you have a feature in the roadmap that may address the problem, show them a demo or screenshot, ask for their feedback, whatever you can do to align this incremental custom request with a larger and more generalized thing.
Code as last resort. As technology experts, we instinctually think that technology is the best solution. But often it's not! The answer to the customer's problem might not require changing the product. It might be a blog post, or help video, or FAQ, or other cheaper artifact. It might be training a customer yourself about how to use an advanced feature. Or training your support team. Your development team will love you when you take work off their plate, and your customers will love you if you deliver faster solutions that don't require a product release.
Coalesce and stack-rank requests from different stakeholders at the same customer. It’s common to get requests from many different people at the same large customer. Each of them usually thinks that their request is the most important. A technique that worked well for us at Cantaloupe was to ask the business decision-maker at these customers to choose a single point of contact on their staff who’d prepare a single, prioritized list of all of the company’s requests. This forced different people at the same customer to work together and come to consensus. When working with our most strategic and/or challenging customers, this simple process had many benefits:
Helps the customer understand why you can't do everything at once. Avoids “I want it all and I want it now” noise because it’s obvious even to non-PMs that you’ll work on the list in order.
Keeps you out of internal fights among different stakeholders at the customer. If Steve in Accounting team wants feature X but Theresa from IT department wants Y, requiring a stack-ranked list puts the onus on the customer’s senior execs—not you!— to decide whether Steve’s or Theresa’s asks are more important to them.
Avoids you having to track one-off requests from random people in the customer’s company. All feedback must get funneled to one customer contact who might say “no” or “we already have that” or otherwise avoids your team wasting time documenting a low-priority or unnecessary request.
Keeps things focused on items at the top of the list. Lower-priority needs might even go away by the time you are done with the top items, which saves your time without the customer feeling like you’re stalling them.
Note: even if there’s no common executive at the customer who can enforce priorities, you can invite your stakeholders at that customer to a conf call or in-person meeting and facilitate the stack-ranking. These meetings can be magic; they often lead to fast consensus because no one wants to beat up their co-workers in public like they beat you up privately!
Proactively meet with your largest customers about their requests. At Cantaloupe, whenever we met with a big customer to review their prioritized list, we transferred their list to a Google Sheet in a standard format and gave the customer read-only access. Then, for the largest customers, we’d meet with them 2-4 times per year to review progress on their list and to make changes if needed. Not all customers got this non-scalable experience, but even if you have hundreds of customers you can probably afford this process for your top 10 most-strategic accounts. A nice side effect of recurring reviews is that customers saved up their feedback and complaints for the meetings, instead of bombarding our team with one-off requests. Another benefit is that these meetings were a great opportunity to connect with customers to ask about what’s changed in their business, about what our competitors are doing, etc.
Always ask how new requests should be prioritized vs. old ones. Whenever you get a new request from a customer with multiple outstanding requests, always ask how the new arrival should be prioritized relative to the old ones. If the new thing isn’t at the top of the list, you’re off the hook until the top one ships, because of course the customer won’t want you to stop working on their top priority! 😄
Include your roadmap (as a list, not swimlanes with dates!) in prioritization discussions with trusted customers. I try not to have a prioritization discussion with a big customer about their incremental requests without discussing the whole roadmap too. If there were items on the roadmap that the customer wants, we’d ask them how those items should be prioritized relative to the customer’s specific asks. Sometimes our top roadmap items would be ranked ahead of all custom asks, which meant we could deliver the customer’s top asks *and* our own top priorities at the same time. Seeing the full roadmap also helps the customer internalize that if they get 10 minor incremental fixes, then it'll add months of delays to get that cool feature they've been drooling to get since they signed up a year ago!
Tip: don’t frame these discussions as “here’s our roadmap” but rather translate the roadmap to a simple prioritized list and say “here’s a list of features that other customers have asked for and which we’re considering working on next” which lowers the stakes because you’re not actually committing to anything.
Get your customers together! If you can, get your customers together in one place (physically or virtually) for an "advisors group" and get them to prioritize your roadmap (per above: as a ranked list, not swimlanes and dates!) along with any incremental improvements the group asks for. In other words, take the single-customer process described above and scale it to a group of your top strategic customers. Groups of senior decision-makers often do a great job at helping you identify the most important things. Also they tend to be focused, because they don’t want to look dumb in front of their peers by focusing on trivial stuff or bad ideas. Plus, each individual customer may want to make your company their servant, but the group overall more than anything wants you to be successful and to stay in business, otherwise everyone loses. Some industries are too competitive or too busy to make this work. But when it works, your customers become a team of cheerleaders rooting for your success. Hint: if it's in-person, you'll need to pay for hotel & group meals. Don't be cheap!
Show progress. If you can't deliver all 10 things the customer asks for, deliver one this quarter and tell them about it. Deliver one next quarter and tell them about it. And so on. Any time you have good news about anything they want moving through the release, let them know. Humans love progress bars vastly more than a spinning wait cursor or blank screen. Be a progress bar!
Prove that you understand how important the problem is, even if you can't solve it yet. How you communicate with and relate with a customer often matters as much as what and when you deliver. An enterprise customer has often made a career-risking bet on your product. The biggest fear of your customer isn't that you'll be late. It's that you'll ignore them and *never* solve the problems you promised you would—just like every other B2B tech company since the dawn of time. If you can't solve the problem right now, at least spend the time with the customer so that they know that you understand the problem and really care about will solving it in the future. SaaS is not about today's tech, it's about the promise of a better future. Make them believe!
Propose partial solutions. Sometimes a part of a customer’s request is compatible with your priorities, but the remainder isn’t. If that happens, consider splitting the ask: deliver the strategic part yourself and leave the rest for manual work or a partner to handle. For example, I worked with a large customer who wanted direct access to our production database in order to extract data every day into a data warehouse. This was not OK for us, because it’d introduce a hard dependency between our frequently-changing DB schema and would restrict future innovation. But they were adamant. We compromised on a partial solution: an API layer over our existing custom-report feature. The customer built custom reports to extract the data they wanted, and then could use the new API to pull data on a regular basis. The customer’s technical team hated this idea because it was hacky and caused more work for them, but the customer’s management team overrode those concerns because they felt that a “good enough” partial solution was better than nothing.
Leverage decision-maker vs. team mismatch. The anecdote above about decision-makers overriding their own team is actually pretty common. A customer’s decision-maker(s) often have different priorities from the folks on their team. People on the team are usually most focused on making their jobs easier and boosting their personal KPIs. But decision-makers are typically focused on top-level business results, so they’re sometimes willing to make decisions that will make their team’s life more difficult in exchange for saving money or time, or to support some other higher-priority initiative. This usually means that decision-makers can be more flexible than the people who work for them. As PMs we can (carefully! politely!) leverage this to uplevel the often-myopic feedback you’ll get from power users who don’t sign checks.
Maybe: empower partners and developers to fill feature gaps. Mature SaaS companies like Salesforce don’t build every customer request either. Instead, they put an API surface on their products and nurture a partner ecosystem to build what the core product lacks. If your product has very clear integration cases (like the “get output of a custom report” example noted above) then building an API makes sense. Just be careful: changing API behavior later is much more painful for customers than changing UI because retraining humans is usually cheaper and faster than getting code changed to respond to your API changes. What usually happens is that you’re stuck supporting the “V1” API for many years after “V2” ships. Also, supporting developers often requires a different set of people and skills than supporting GUI users. So be open to API-ification to reduce pressure on custom feature requests, but be aware it’s not a panacea and might make things worse. Before adding your first API, talk with someone who’s done it before and get their advice!
Charge a lot to influence the roadmap. Commonly, requests from customers are already on the roadmap. This is a great opportunity for Sales to get additional revenue for work your team was going to do anyways! For example, if we were going to build feature Z in 6 months, but a big customer is willing to sign up but needs Z sooner, then I’m usually open to rearranging the roadmap (e.g. ship Z in 3 months) to help the deal close. My main ask for Sales is to have the customer understand that the privilege of getting something on the roadmap is rare and *very* expensive. In addition to preventing customers from demanding free roadmap influence later, a high price also differentiates customers who *really* want a feature vs. those who can live without it. The latter deals are cheaper for the company (no new R&D!) and often close quicker instead of waiting for the features to ship.
If all else fails, say “no” clearly and directly (but let Sales say it)
Sometimes a customer’s requests are so specific-to-them and expensive that there’s no way to justify the large engineering investment and opportunity cost (revenue you could get from other customers using the same engineering investment). When that happens, your company’s best bet is to be honest with the customer about why you can’t fulfill their requests. Don’t delay or hedge because the customer will just get angrier. Your customers are businesses too; they may not agree with your priorities but they will probably understand.
Note that delivering bad news to customers is usually *not* PM’s job, because it may have revenue consequences. Instead, bring someone senior on the Sales side to lead that discussion to deliver the bad news and deal with the blowback. You should attend if they want you there, but ultimately it’s their quota and job on the line, so you should follow their lead.
Another reason why it’s good to let Sales break bad news is that good salespeople can turn lemons into lemonade. For example, we once had a very large customer who made a long list of feature requests and promised to churn if we didn’t build them. The asks were specific to that customer and not generalizable, and the total cost of building them would be 12+ months of our total roadmap capacity. So we had to say no. But instead of simply divorcing the customer and losing all that revenue, this Sales genius figured out a way to keep (and even grow!) part of their business. For the rest, he offered free consulting time to migrate part of their business to our biggest competitor. The customer won because they got a faster, cheaper path to tech that they believed would better meet their needs, while not incurring the hassle and expense of ripping out all our tech. We won because we retained a lot of recurring revenue, and because the customer felt he’d been treated fairly so didn’t bad-mouth us to others. And as an added bonus, our top competitor acquired a really demanding customer who’d tie up their engineers for a long time with custom requests!