For many first-timers with great ideas, the process is exciting but also a bit intimidating.Most product teams have their own processes for handling customer requests. But what about would-be customers and their “dealbreaker” requests? If you’ve spent much time in product management, you’ve probably encountered a few of these. Usually they come from the sales team in some variation of, “Super-awesome-prospect is going to buy! But we just have to build X for them first. We can do that, right?”
How to Manage “Dealbreaker” Requests from Prospects
After all the customer research, persona development, competitive intelligence, MVPs and A/B tests, we’d like to think our products can serve the needs of our target market and meet enough requirements that they’ll buy, subscribe, or pilot. Sure, there’s always plenty of room for improvement, but you’re pretty confident there’s enough there to get people onboard as-is.
That is, until your sales team starts bringing in prospects who love the product and see its value…but need it to do something else before they can move forward. We’re not talking about buying it now with the understanding that eventually they’d like it to do one more thing. They need it to do that thing before they’ll start using it and hand over their money.
When this happens, your best laid plans are at a crossroads. Do you temporarily shelve your deliverable schedule and divert resources to close the deal? Or, do you push back in favor of your already established roadmap? Before making up your mind, here are some considerations to remember when a “dealbreaker” crosses your desk.
What does the prospect actually want?
We’ve all heard the old adage that “the customer is always right.” And as experienced product managers, we’ve learned to take that undeniable truth with a grain of salt. While there’s no denying a customer’s feelings or pain points, they’re not always the best at both diagnosing the root cause of their issue and coming up with the ideal solution.
Customers are trapped in their own particular worldviews and colored by the specifics of their experience. Therefore, they’re potentially unable to envision the full possibility of options. As with any request, you can’t take requests from prospects at face value. Unpacking requests, getting to the root requirement(s), and devising elegant solutions requires deep understanding of their source. And you’ll need more than second-hand info from an enthusiastic salesperson with commission on their mind to get the level of understanding you need. Which brings us to our next step…
Speak with the prospect directly.
Whisper down the lane is a dangerous way to pass on any important information. And inserting a salesperson into the communication chain rarely improves a message’s clarity. So, when a hot prospect demands your product do something new to secure their business, cut out the middlemen. Have a direct conversation with the prospect.
There’s plenty of upside to this. You’ll have the opportunity to delve into what the prospect is trying to accomplish rather than jumping straight to implementation recommendations. You can also explain what the product is already capable of. This alone could potentially alleviate the need for custom work altogether, or even uncover some temporary solutions. And, you’ll have the opportunity to see how their needs might be similar to those of other current customers and prospects.
Depending on the nature of their request and your own technical chops, don’t be afraid to include a representative from engineering on the call as well. This way if things take a turn into more technical territory you’ve got some backup. Plus, you won’t have to try and translate your understanding of the prospect’s needs if it’s out of your depth.
Are you accelerating development or taking a detour?
Most dealbreakers fall into one of two categories:
- They want something you would eventually like to build but haven’t prioritized.
- They’re asking for something you would otherwise never consider.
The former might be something already on your roadmap. Or, it could be something you hadn’t prioritized but would clearly be useful and valuable to other customers. While you may not want to postpone another project to let this feature jump the line, you’re not derailing your overall plans either. These requests are usually a little easier to swallow and justify. But, they do still represent an opportunity cost since they’ll be delaying something else you previously deemed more critical to bring to market.
The second category, however, is more fraught. It is a total distraction—and possible derailment—of your plans. It’s not only something you weren’t planning to do, but it’s something you definitely wouldn’t do if it weren’t for this specific customer asking for it. Whether it’s integrating with a third party service, supporting double-byte fonts, or creating a customized workflow, these represent true interruptions to your strategy. And they can and will impact overall growth and functionality. Are you willing to do this in the name of landing a single deal?
Understand what the request’s costs are.
Although it should be obvious to everyone, any request you fulfill for new customers come at the expense of something else. It’s highly unlikely you had a team of engineers just sitting around looking for something to do. So don’t be afraid to highlight these costs to the salespeople bringing them to you as well as senior management (who might be more focused on closing the deal than its impact on other deliverables).
Break out the cost of every request in the following ways:
- Human Capital: How much time (including yours, development, testing and operations) will this request take?
- Actual Capital: Does this request require the company to buy additional software, hardware, cloud services, or licenses (not to mention if outside contractors are required)?
- Ongoing Expenses: Will the request require ongoing support or create a new dependency that will make things more complicated in the future?
- Opportunity Cost: What would get bumped, moved, or dropped from the roadmap to fit this in? What other customer requests might be delayed? What is the cost of delay?
Switching the conversation from “in a vacuum” to “real-world impact” is critical when you’re looking for stakeholders to evaluate a special request objectively.
Understand the potential upside.
Before you even engage your team to begin scoping out what it will take to build something special for a particular prospect, you need to “get real” with the sales team about what is at stake. Not all customers and opportunities are created equal. You need to understand what landing the new customer in question would actually mean for the business.
This assessment can be measured in multiple ways:
- Upfront revenue (how much money you’ll see Day One or Year One of the deal)
- Lifetime customer value (how much money this customer represents long term)
- Strategic importance (is this going to be a referenceable customer? Will this open new verticals and niches to your business? Will it create headline-worthy buzz that might justify some extra development?).
With the potential upside properly assessed, the next step is to suss out just how legitimate this opportunity is… and just how pivotal is this custom request to landing the business. There’s a big difference between someone having a “good meeting” with some takeaway product enhancement requests and a prospect that is truly willing to buy a product and roll it out in scale.
Is the request a one-time ask…or the tip of the iceberg?
A prospect’s initial request for custom work can be an early indicator for what kind of customer they’ll be over the long haul. If they need some baseline items to meet security requirements or integrate with their LDAP to enable SSO, it’s a sign that they’re a serious enterprise that wants a seamless implementation enabling widespread adoption. That’s generally a good thing and a sign of a client with significant potential for revenue and growth.
On the other hand, if they’re asking for a lot of little things that aren’t core to your product’s primary functionality, it may be a hint that they’re never going to be satisfied with the core product and will consistently request additional custom work. In this case, you need to consider the “Lifetime Cost” of the client and decide if they’re going to be more hassle than they’re worth.
Every little one-off represents opportunity cost. And every new use case is yet another test scenario you need to run through in every regression test. It’s also a new source of future bugs and compatibility issues. For a growth-focused companies who are trying to support lots of customers, this can become a legacy client that’s constantly creating drag on your overall release cadence and stifling innovation.
Consider strategic customer fit.
If a prospect is requiring you to make changes or enhancements to your product before they even start using it, your company should step back and ask itself if this customer is the right fit for their strategy. If your product isn’t good enough for them as-is, is that because they’ve brought to light a shortcoming that a vast swath of your potential market will also value, or are they simply trying to fit a square peg into a round hole?
While no one wants to turn away a sale, bringing on a client that will require constant hand-holding, coddling and customization can create long-term repercussions. Committing to the wrong kind of client can shift your focus (and your development team’s) for the larger objectives you’re all shooting for.
Get customer commitments in ink.
During a “normal” product development process, there’s a complex decision making process to determine if a feature is worth adding. Is there a real demand and use case? Will it increase usage or revenue or customer satisfaction? Can it reduce friction or limit churn?
But when a customer or prospect is asking for something to be built just because they want-slash-need it, you’re placing your trust in them that it will be the magic bullet that unlocks your product’s potential for the company in question. But building something on spec is rarely a good idea, even when a customer or prospect specifically asked for it.
Both parties should have some “skin in the game” before a request gets slotted into the development calendar. There are a few ways to handle this.
- The customer can sign an agreement that they will purchase the product (or a set volume of the product/licenses/etc.) once the project is complete
- They can make the purchase now with an understanding that their custom request will be delivered by a specific date or get a refund or other financial consideration
- Or, they can just put cash on the barrel to pay for the work they’re requesting. (This is most appropriate for work that is truly one-off and customer-specific).
Sometimes Sales Requests Win
In the end, it’s not always your call. It’s likely that others in the organization will have strong sentiments of their own about how to deal with dealbreakers. If the company is desperate for revenue or a big name logo, there may be little interest in saying no.
Regardless of how the wind is blowing at the top, it’s your job to provide senior management with data so they can make an informed decision. Present a firm picture of a dealbreaker’s upsides as well as its impact on your schedule, your resources, pre-existing customer commitments and long-term consequences. Even if it feels like you’re throwing water on the potential closing of a significant deal.
Stick to the facts and keep any opinions you may have within the context of the information you have. By forcing sales to qualify the opportunity during the data-gathering process you’ve already done the hard part, even if the ultimate decision is out of your hands.
