Credit: Polina Tankilevitch

How to Deal with B2B Sales-Driven Feature Requests

We’ve all been here. This is how to deal with this VERY common situation in B2B software companies.

TL;DR

• Sales-driven feature requests are inevitable in B2B software. You can’t avoid that.
• But how you handle them in your company is up to you.
• Be a partner with the Sales teams, and help them understand how you balance product direction and market needs with individual customer requests
• Create a clear process and evaluation criteria around how these requests are communicated, evaluated and fulfilled.
• Focus on maintaining product direction (vision) and objectives while minimizing diversions that cost time/effort and have low ROI.
• Competitive advantage and winning markets, not just individual deals is the ultimate goal.

Table of Contents

• Understanding Feature Requests
  — External Factors
  — Internal Factors
• Should We Build this Feature Request?
  — Define an Evaluation Process
  — The Evaluation Criteria
• But What About Deal Size?
• Whales and HIPPOs
• Key Points to Remember
• That Wall Street Bank
• Some Feedback Please

EVERY product manager who has worked in a B2B software company has had to deal with this situation. Every single Product Manager. If you’ve never dealt with this, you are a rare breed, or you’ve never worked as a product manager in a B2B software company. Here it is:

A Sales Rep comes with news of a big deal in the works with a very important prospect, and in order to close the deal, we ONLY need to deliver a feature request that this very important prospect needs. When can it be done?

Have you ever had that happen? The choices are “YES, I’ve dealt with that.”and “YES, I’m dealing with that right now.”

I’ve dealt with this situation MANY times over the years; one notable one was when a Wall Street bank wanted a “small feature”. The deal size was reasonable — about 3X our average deal size — and the sales rep in question was a really good rep who didn’t come to us with frivolous requests.

He also raised the issue very early in the sales cycle — always a good thing to do <hint, hint Sales reps> — and told me it was more of an FYI at that point, because he was still scoping out the details. I told him I really appreciated the heads up and would await additional information.

I’ll tell you how this sales deal wound up at the end of this post, but I want to dig into the decision process for evaluating feature requests like this.

Understanding Feature Requests

Let’s dig into “feature requests” themselves. A feature request is an ASK (not a demand), from a customer or prospect, for the company to invest time and effort to fulfill a specific need or desire they have. Feature requests have a number of factors that we should be aware of:

External Factors

1. the requested functionality
2. the (assumed vs. real) underlying problem or need that the request is addressing
3. the real reason for the request (I’ll dig into this)
4. the urgency of the request (when it must be delivered)
5. the value/importance of the request to the customer

These are all from the customer/prospect side of the feature request. There are other internal factors as well to think about.

Internal Factors

1. the cost/effort to implement that request
2. the technical requirements/challenges to implement the request
3. the level of support that feature will need once implemented
4. the breadth of customers that could also use that functionality (always important)
5. the timeline for when that work can be done given other commitments
6. the impact of that work on other work being done. i.e. does it disrupt other work, and if so, which work and by how much?
7. the potential that functionality will need to be expanded/improved in the future based on future customer needs (also important)
8. how well that feature request aligns with your current product direction/vision and objectives. (REALLY important)

As you can see, there are quite a few factors that could (or should) be considered when thinking about implementing feature requests. Each one of them can have important detail to consider. I won’t go into all of them, but here are a few things to think about when in this situation.

External Factors

The requested functionality

In virtually every case, the “request” is a request for a specific capability or solution to a problem/need the customer has. It’s usually described in very simple terms —e.g. we need to get data from your product into our parts management system — that is often incomplete (why do they need to get that data?, what will they do with it? what data is needed?, what kind of data volumes?, how often?, etc.) and needs much more detail. That detail is, of course, critical to identifying the solution and scoping it out. In fact, once this and other details are understood, the true nature of the problem can be understood, and the solution requested by the customer/prospect may actually not be the best solution to the problem.

The (assumed vs. real) underlying problem or need

As much as the feature request is what is initially conveyed, the crux of the matter lies in the underlying problem or need the customer is trying to address, and this is almost NEVER conveyed up front. So first things first.

Work with Sales to speak with the prospect to understand the “feature request” first hand, and try to understand the REAL underlying problem or need. They’ll talk solutions — we need a feature that does X — and you need to understand problems — what is the situation that causes them to need a feature that does X.

Keep in mind that they’ve already decided (with some level of confidence) on the solution they believe will best address their need. But you still need to understand that need and the context AROUND that need so you and the company can truly understand WHY that need is important in the context of the sales deal.

The reason behind the request

This is an interesting one and really deserves attention. There can be different reasons for a feature request during a sale. Most are what I call legitimate requests, but some are not. Some come from a very different perspective.

Legitimate requests — In MOST cases, feature requests have very legitimate origins. The prospect is buying your product to solve a problem they have and their environment or processes or governance rules etc. have a specific need that isn’t addressed by your software. It could be an integration to a system for data exchange, or it could be an internal process that requires special approvals that must be recorded in your software, or something ancient in their tech stack that must be supported…who knows. But in all those cases, there is a legitimate need (more or less).

BUT, there are some cases where the need isn’t what I would call legitimate. These needs fall into different buckets that have more to do with personal gain or company politics.

Resume Building —The feature request may be for reasons such as resume building —which happens more than you’d think with cool technologies like AI or VR.

AI is the current rage, and I’ve spoken to people recently who are getting feature requests for “AI support” in places that it makes ABSOLUTELY no sense. But the people at the customer site want to get AI exposure so they’re asking vendors for AI features so they can get that exposure. I saw this first hand in the early days of Big Data where people were resume building and using vendors to help with that task.

Oh I was just kidding about the leg. I just wanted these two things.

Leverage — Another reason for feature requests that I’ve seen is leverage with the sales rep. Sometimes prospects will make feature requests for something beneficial but not absolutely critical, so they can have negotiation leverage when it comes to agreeing on the price and other terms and conditions. e.g. they’ll “grudgingly” say they can hold off (for a while) on the feature request but want something in return.

My assumption is they’re doing that with all vendors. It’s a way to also gauge the strength of a sales rep. i.e. if a sales rep is willing to say yes to feature requests, without much negotiation or investigation, they learn something VERY valuable they can use in negotiations. This is a good reason to have a process to engage Product Management EARLY in the sales process when these situations come up. Alternatively, if you train your Sales Engineers to intercept or spot these requests and escalate them to Product Management early on, that is also beneficial.

Credibility Building — One final reason that I’ve seen is when the prospect champion or influencer wants to build credibility for themselves within their company, and they believe they can show this by getting vendors to do their bidding (so to speak).

It’s not often that you see this, or can be certain of it, but it does occur. Once, a prospect actually admitted this to one of our Sales Engineers, that he had really pushed internally for this project that we were all trying to win, and wanted to show others (executives I’m assuming) that he could deliver for the company. And, by implication, one way to do that was to get vendors to agree to custom feature development.

It’s REALLY important to understand the real reasons behind the request so that you and your company can respond appropriately.

The urgency of the request

For many (but not all) sales reps, these requests are ALL absolutely urgent.

Sales rep: “We need to get this done right away. Can’t close the deal without it.”

But the real decision maker on urgency is the customer. Find out from them the value — the why — as well as the when.

In most cases, customers are willing to wait for legitimate feature requests, because they understand that things take time and there is other work being done.

In one case I dealt with, while the sales rep wanted the request done ASAP, but after some prospect conversations, we found out that all they REALLY wanted was a commitment at the time of signing the deal, and would be willing to wait 6 months (possibly more) as their own internal implementation of our product wouldn’t begin for at least 3–4 months after signing. Good to know.

Internal Factors

Those are some of the external factors. But there are also internal ones to consider. Here is a bit of detail on a few of them.

Cost/Effort to Implement

This is the first, and sometimes the only, factor that people consider. But even in this case, the actual cost — salaries/loaded cost of those who will “build” the feature — is never really accurate. It’s an approximation, which usually underestimates the time/effort for many reasons including, but not limited to: Planning Fallacy, Optimism Bias and Hofstadter’s Law.

Hofstadter’s law is an interesting one. It reads:

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Other reasons for underestimating can include internal pressures to “do it sooner”, unforeseen technical problems or people issues (absences, departures, reorgs etc.)

Even if the development cost is NOT underestimated, there are other costs to consider such as ongoing cost of support and maintaining the feature for that one customer, and the cost of NOT doing other work that could have been done or that gets delayed for this feature request.

Technical challenges to implement

This is the second factor people will look into when deciding whether to implement a feature request. In most cases, there may be few significant challenges, but if the feature request is something that your team is not familiar with, or something that is outside the scope of where your teams focus, this can cause issues.

Underestimating the technical challenges will also impact the time/effort to build and deliver, so keep that in mind.

This is why it’s important to REALLY understand the request in as much detail as possible. Not only does this give you knowledge to consider various options to addressing the request, but it will help you assess the technical challenges more effectively.

Alignment with product direction and objectives

The last factor I’ll cover is how well does this feature request align with the product direction. Is it something you likely would have considered at a later date? Does it fit in with the use cases or target users you have? Or is it something you wouldn’t have done, that represents a new market or use case? These are important questions to understand.

If the request DOES NOT align with product direction/vision, markets, use cases etc. then realize that building it and supporting it will be MORE costly for the company as it will require special handling and knowledge as compared to the work and customers you normally deal with.

This of course assumes you have a clearly defined and communicated product direction/vision. Sadly, a lot of companies don’t have this, so when it comes to this factor, they don’t have anything concrete to compare against and so every feature request looks “reasonable”.

This is a bad state to be in. And IMHO when this happens, I always look at the Product Leader (VP Product, CPO etc.) and wonder, why they haven’t done their job to define that direction/vision. It Product 101 quite honestly.

Should we build the feature request?

Given the factors describe above, here’s the method to evaluate these Sales-driven feature requests.

Define an Evaluation Process

At a macro level, have a clear process defined with the Sales team/leadership, Engineering and Product Management. This is the job of the Product Leader (VP Product, CPO etc.). Sometimes this will be driven by an astute, product-minded Sales leader, but really it is Product Management’s job to define. It should look something like this.

1. Sales alerts Product Management as early as possible of a feature request that might be tied to a sales opportunity. NOTE: This could (should) be during joint PM/Sales funnel reviews, but that is fodder for a different blog post.
2. Product Management and Engineering work with Sales to collect the information needed to do a rough scope/sizing of the request
3. Based on pre-defined evaluation criteria (I share mine below) a tentative yes/no/TBD is given to Sales for the opportunity.
4. As the deal evolves and more information is available, the decision on the feature request updated. It can be committed to late in the sales cycle based on the needs of Sales.
5. The deal closes and the feature request commitment is addressed, or the deal doesn’t close and everyone moves on.

There are of course a lot of details and assumptions in the above, but it is a general process that I’ve followed in several companies and that worked well.

There MUST be trust and open communication between Sales/Engineering/Product for this to work.

The Evaluation Criteria

There is no single BEST way to evaluate an opportunity. Each opportunity is unique, each company is unique and the situation for the company at the time the opportunity arises is unique. What may seem like a great opportunity and feature request one year (e.g. in a booming economy) might seem out of synch with the market the next year (e.g. in a struggling economy).

This is just an example, but it’s important to understand that context is very important when making these decisions. That also makes these decisions a struggle in many companies, because there CAN be a lot of subjectivity involved and different voices (e.g. Sales vs. Product) carry different weight.

Additionally, given every deal has revenue or some business benefit associated with it, and this is important to most companies 😄, we need a way to evaluate that business benefit in a context that is aligned with the company’s overall best interests.

The following diagram provides a framework for thinking about deals and feature requests. I call it the Feature Request Matrix.

A framework for considering Sales-driven feature requests

This is a simple 2x2 matrix. The horizontal axis measures alignment with Product Objectives and Direction. I mentioned above that it was important to have this defined.

The vertical axis measures the Cost/Effort and/or Technical Difficulty of implementing what’s being requested.

There are 4 quadrants labelled 1–4. Let’s walk through them, but not in numerical order.

Quadrant 3 — High Alignment with Direction, Low Effort/Cost/Difficulty

This is the easiest one to consider. It’s almost always a Yes, because the feature request aligns with the Product Direction/Objectives, and the Cost/Effort/Difficulty are low.

Sales reps that bring these kinds of requests will almost always be happy with the response. I’ve seen these kind of requests come in — e.g. a new integration that we would likely have done in the future, but makes sense to do now because of the deal — and am usually happy to say Yes.

Note that timing is still to be determined, but it’s usually something that can be added in the near future without too much disruption to other work in progress.

NOTE: This is another reason to have defined Product Vision and Objective, and ensure that the Sales teams understand them. That will help them better understand the rationale for decisions related to feature requests.

Quadrant 1— Low Alignment with Direction, High Effort/Cost/Difficulty

This is also (usually) easy to decide, though I’ve seen some heated “debates” on this type of request.

The feature request DOESN’T align with our current Product Objectives and Direction, AND has a high Cost/Effort or some significant Technical Difficulty. Why would anyone do it? And the answer isn’t “for the revenue”.

Keep in mind that the significant effort for this feature request will divert resources AWAY from what else you were planning on doing, thus delaying future revenue that would have come in. It’s not a zero sum game either. The revenue from Product Direction aligned work is 10x or more the revenue from the same effort for work that isn’t aligned to your product direction.

Companies make this mistake very often — approving these requests because “revenue” — when they don’t have clear Product Vision/Objectives/Direction etc. Don’t be one of those companies.

And keep in mind, in ALL cases, for a Sales Rep or Sales Manager, the revenue of the deal is what they are looking at, as THAT is attributed to sales quota and compensation. They don’t have to worry about the engineering implications, so they’re going to push hard regardless of the quadrant.

Quadrant 2— High Alignment with Direction, High Effort/Cost/Difficulty

This quadrant is an interesting one in that the request is aligned with the product direction, but requires a LOT of effort or has high technical difficulty/risk. A lot of companies will simply say “yes” if the deal size is big enough, but there is a better way of handling this.

Get additional (significant) clarity on the REAL needs, and identify what is TRULY the minimal deliverable to address the problem. Customers are usually looking for the easiest way to meet their needs. So, start with the simplest (least effort) option and see if you can get the customer to sign off. If they do, then that’s great. If they don’t, you can find out what (incremental) enhancements are needed to get their sign-off.

I’ve seen this in real life, and most customers are flexible if their request has significant technical challenges or is a very significant cost/effort. Some companies will pay vendors extra for “custom” work, but be careful in those discussions, because custom work paid for by a client is NOT the same as product functionality you add based on a request. If you’re confused about the distinction, ask your manager or the legal or finance teams at your company.

So the approach here is to get additional detail and break up the proposed solution into smaller parts and define the absolute minimum to address the need. The goal is to figure out a solution that gets you into Quadrant 3, OR, tell the prospect/customer that you cannot fulfill that particular request, but have a workaround ready, just in case.

BTW, what may seem like a “workaround” to you, may be a totally acceptable solution to the customer. I’ve seen this several times. We (Product/Engineering) of want to create “clean” solutions to problems, but for many customers/prospects, a less elegant solution that solves their problem is often sufficient. Keep in mind that while this may be OK for one customer, it may be problematic for others if the feature gains traction, so find the right balance of when working through these problems.

Quadrant 4 — Low Alignment with Direction, Low Effort/Cost/Difficulty

This quadrant can be a challenging and often contentious place to be. Some people will look at this and say, “Well, it’s low effort, so let’s just do it”. Others will look at the low alignment to Product Direction and say “No, it’s a distraction.” My response here is “It depends.”

Here we have to look beyond the Cost/Effort, Alignment criteria. Because the effort/cost etc. (overall risk) is low, there is often pressure for leadership to just “get it done.”

If these types of feature requests happen rarely — 2 or 3 times a year, then sure, just do it. The total of that effort is not big and those features can be managed either by feature flags or configuration settings so they’re exposed only to customers that actually need them.

But if this happens regularly — e.g. once a month or even more — then you’re not only diverting a lot of resources to this work, but you’re creating a lot of unaligned features that need to be implemented, documented, supported, updated etc. These grow over time, and divert resources in the long term. It’s like negative compound interest. It starts slow, but over time, it really eats into your resource pool and ability to focus on new market needs.

Also, the more you say Yes to these types of requests, the more Sales and others will expect you to say Yes to future requests. And then what does that say about your commitment to a Product Direction and Objectives?

It means that revenue takes priority. and once that precedent is set, it is VERY hard to change.

So look at other factors such as the how influential the customer is (total lifetime value, ability to be a reference account etc), whether the feature request itself is something that could lead to expansion revenue in some ways, or if there are other meaningful benefits. Is there a CSAT factor? Is there additional revenue in the future etc?

If you see enough such evidence, then say Yes, If the opposite is true; not influential, no reference potential, no expansion potential etc., then say No. But have this discussion out in the open and remind all parties of the opportunity cost, previous such features that were implemented without additional benefit etc.

It’s not easy saying No, but do it in a way that provides clear context and understanding, and be willing to give in when needed — i.e. lose a few battles but win the war.

But What About Deal Size?

I’ve seen different companies implement variations of this process. Some were more rigorous, some had little rigour at all. The question comes down to how interested is the company in long term competitive advantage?

i.e. If the default answer to sales related feature requests is “Yes”, or “Yes if the deal is big enough”, then none of the above will matter much. The company is sales/revenue driven and isn’t thinking about longer term competitive advantage.

I’ve seen some companies work this way, and it does reap short term benefits. But in the long term, it becomes a drag on growth and more focused competitors will come along and eat their market share, because while the company was diverting resources to specific feature requests, the competitor was focused on meeting broader market needs and delivering great user experience.

But with respect to deal size, in most companies I’ve seen, small deals don’t merit inclusion of feature requests. Good sales people will push back on the prospect on feature requests tied to smaller deals, or use it as leverage to increase the deal size.

You could, as a Product Management organization, stipulate to (or get agreement with) the sales team, a minimum deal size before feature requests get any focus. e.g. if your average deal size is $50K, you could say that nothing below $100K should be entertaining specific feature requests. The actual number is up to you of course, but this is an example if you want to set a floor.

But for larger deals, or deals exceeding your minimum, the situation is almost always the same, so deal size isn’t really a factor, until it is. 😄

Whales and HIPPOs

There are two situations where things get a bit muddy (slight pun intended).

Fun Fact: Hippos and whales (the real animals) are evolutionary cousins. Just thought I’d share that.

Whales

These are accounts that have previously, or have the future potential to bring in large deals to the company. There are usually very few whale accounts (or opportunities) at any given time, but when they appear, Sales teams, and sometimes entire organizations line up to land those deals.

In cases like this, you might get feature requests in Quadrants 1 or 2 (i.e. high cost/effort) and there will be a lot of pressure to say “Yes”. In fact, the decision to say “yes” to the feature request may be made exclusively at the executive level.

If you have little control over the decision, then don’t sweat it. Take the decision that is handed down and do your job. BUT, if you are part of the process — and this can be a really great learning experience — work closely with the leadership and Sales team, show yourself to be a positive contributor in landing the deal, and be involved so that you can bring clarity and alignment to any feature requests that are raised.

HIPPOs

HIPPO is the acronym for Highest Paid Person’s Opinion, but it often gets used to refer to the person themselves (typically an executive or leader) who decides unilaterally that something should be done.

In sales opportunities, a HIPPO decision might extend beyond the “Yes, we will build that.”, and also get into the “This is how we will build that and when we will deliver that.”

I’ve seen this in companies that are led by a technical founder. Sometimes there isn’t even a sales opportunity connected to the directive. The founder might have had a conversation (or 2 or more) with people outside the company or saw something, somewhere, that led them to decide that some new product direction or capability is needed.

In situations like this, it’s important to have the conversation about effort, product direction, objectives, existing commitment, opportunity cost, disruption,etc. just to make sure that the decision is made with that information. i.e. you’re doing your job in the context of that decision.

But ultimately, if the HIPPO has the authority and decides, then there is little you can do, but move things forward. But the next time the HIPPO decides something similar, you can have the same effort/direction etc. discussion and reflect on the last time this happened and how it turned out, particularly if it didn’t turn out well. Keep in mind that people’s memories are often weak or selective, so “bring the receipts” as they say.

You’re playing the long game here. Don’t forget that.

Key Points to Remember

This is a common but complex topic. I’ve tried to provide significant detail, but as I stated earlier, every company and deal are different. So the goal is not a cookie cutter framework or decision model, but an open process and common understanding of how the Yes/No, Go/No Go decisions will be made.

But keep in mind that ultimately, the goal is business success via the product, and that success is measured in different ways in the short term (revenue most often) and long term (sustainable competitive advantage, market share etc.). The key is to find the right balance of short and long term success without skewing too far in either direction.

Clearly defined and commonly understood product direction and objectives are a must have.

If you don’t have this, you have nothing on your horizontal axis to measure against, and you’ll likely be left with Deal Size as the only arbiter. You are now in a Feature Factory.

That Wall Street Bank…

So, as promised, here’s what happened to the Wall Street bank I mentioned at the top.

I was tracking the deal in Salesforce, and as the quarter progressed, the deal also progressed and it was looking like it would close in about a month. The Sales rep came back to me, updated me on the status and asked me if I had discussed the effort with the Dev Manager. I said I had, and that it was about a 1–2 week effort.

It was definitely a one-off feature. We were certain there were at most a small handful of companies in the WORLD that might need that capability. It was clearly a Quadrant 4 request — Low Alignment with Direction, Low Effort/Cost.

I asked the Dev Manager if he could have one of this developers do a bit more analysis to make sure there were no major technical risks or potential surprises as it was something we hadn’t ever considered before. No need to implement anything until I got additional confirmation from the Sales Rep.

Two weeks later, the Dev Manager came to me with a big smile on his face and told me that his Engineer had done some additional investigation and found a really easy way to implement the feature. It had only taken 4 days. So it was ready for testing by the customer.

I was dismayed. It was early in the day and I asked him if he’d heard the news that morning. He said “No.” The customer was Bear Stearns. It was March 2008. Bear Stearns, a brand name Wall Street bank, in business since 1923, had gone bankrupt the day before. The bank was gone, the deal was gone and that feature was no longer needed.

The Dev Manager shrugged and said “No problem. It was only a few days of work” and walked off.

A little feedback please

If you’ve read this far, thank you. I’d like some feedback on the article to make it better. It should take just 1 minute, but will really be valuable to me. Thanks in advance.

===> Click Here <===