How Do You Decide to Build a Feature to Close a Deal?
Product managers get blasted with feedback. The most challenging comes from sales. (#40)
A key part of a product manager’s job is collecting feedback. It’s often overwhelming because of the volume and disparate sources.
Feedback comes from everywhere: customers, customer success/support, marketing, sales, the CEO, the board of directors, the janitor, your mom, etc. Beyond feedback there are other inputs into the product management process, including your own ideas, competition, current trends, and more.
It’s a wonder product managers aren’t permanently wearing giant earmuffs to block out the noise.
Feedback from sales is the hardest to navigate.
Tell me (in the comments below) if you’ve heard this before:
“If we build such-and-such, the client will buy. We need to build the feature right now to close the deal!” - Most B2B salespeople at some point in their careers
Sigh.
Contrary to some people’s opinions, product managers aren’t blind order takers and roadmaps can’t be flipped on a dime.
So what do you do?
I asked that on Twitter and got some great responses. The discussion on the thread is worth digging into because you can feel the angst experienced by many product managers struggling with this situation.
The only real answer is to bring product people into the sales process.
The job of product people in sales is as follows:
Ask better questions
Share the roadmap
Show the love
Let’s break that down further:
1. Ask better questions
Sales calls are an opportunity to dig in and ask, “Why?”
Not all sales people want you doing this, because they think it derails from closing the deal and puts you at odds with the prospect. But without doing proper research, you can’t really understand the customer’s needs. If you don’t get the requirements clarified, you can’t build the right feature, or divert the customer’s attention to something else, or point out that your product already meets their needs (or most of them), but in a different way that’s suitable for now.
You can also train the sales team on how to do customer discovery. If they’re able to probe a bit before saying, “Sure, we’ll build that for you!” it’ll go a long way to making everyone’s lives easier. I would encourage salespeople to read Talking to Humans — it’s short, easy to read, and makes a great argument for why it’s so important to ask the right questions.
When a prospect says, “I need X built or I can’t buy the software,” the response shouldn’t be, “Great, we’ll get that built ASAP". Instead it should go as follows:
Prospect says, “I need X built or it won’t work.”
Salesperson says, “Good to know. Can you help me understand how you would use X?”
Prospect explains…
Salesperson says, “That’s helpful. And can you share why it’s so important? That’ll help when we bring the product team in to figure this out with you.”
Prospect explains…
Salesperson says, “Fantastic. Let’s bring a product person into our next meeting so we can really make sure we scope this out properly.”
Prospect feels listened to and happy.
Salespeople may invite you in even before this conversation happens. That would be amazing! If you, as a product manager, can be involved in the early sales calls you’ll learn a ton. You’ll see how the software is being sold and get a feel for how customers are reacting.
Maggie Crowley, VP Product at Toast, said: “I try to join as many demos/ongoing sales processes as I can so that I’m in the room when the ‘request’ happens and can do a tiny bit of problem discovery. Don’t listen to people who say it doesn’t scale - it’s always good even if you’re only getting a % of total prospects.”
The ensuing conversation on Twitter was amazing and worth sharing here:
2. Share the roadmap
I’ve often found that sharing the roadmap with prospects “distracts” them from their custom feature request. Ideally they’re so excited about the roadmap that their specific request becomes less important (which is a good sign that it was never a dealbreaker to begin with).
You don’t want to go into the nitty gritty details—just the highlights. Jason Knight said: “It's effectively a marketing document. Call out your big bets. I've had success with a ‘Now/Next/Later’ format in some sales-led organizations, others will demand quarters at least. All roadmaps have the ‘subject to change’ disclaimer that everyone claims to be bored of seeing, but conveniently forget it if you don't put it on there!”
Focus on the value you’re creating (not just a list of features). I previously wrote about how to use strategic roadmaps (while working with developers), which also applies here. You want customers understanding, “What’s in it for me?”
Salespeople can also present the roadmap. But they can bring you in as a product manager to dig into the details.
Prospect says, “I need X built or it won’t work.”
Salesperson says, “Good to know. Can you help me understand how you would use X?”
Prospect explains…
Salesperson says, “That’s helpful. And can you share why it’s so important? That’ll help when we bring the product team in to figure this out with you.”
Prospect explains…
Salesperson says, “Fantastic. I do want to show you our upcoming roadmap and get your feedback. I’d love to get your thoughts on what we’ve currently prioritized and where that might sit in comparison to what we’ve been discussing.”
Salesperson goes over the roadmap.
Prospect feels listened to and happy. Prospect might say, “Very good to know, but this feature I need is still at the top of the list.” Or they might say, “Actually this roadmap is awesome. I don’t want to mess with that. Let’s go!” Either way you’ve built a better relationship and can move things forward.
3. Show the love
You can’t build everything for everyone, but you can make everyone feel special, especially in an enterprise B2B context. Part of the product manager’s role is providing a customer with confidence that they’re going to receive an appropriate (read: high) amount of attention.
Every customer thinks they’re your #1 customer, right?
Sales can bring product people into the conversation to demonstrate the level of commitment your company is putting into getting a deal. “We’ll provide you with a direct line of communication to our product team,” works.
Incidentally, product managers can also provide tough love. It’s not all rainbows and sunshine. Salespeople can’t play “bad cop” but product managers can. Not to an extent that turns customers away or pisses people off, but enough to have frank, honest conversations with customers in a way that they appreciate.
I like how Joshua Solomin put it:
“In my experience customers are more willing to hear bad roadmap news directly from a PM than a sales person, since we can up-level the discussion to a more broadly applicable solution, or explain why it doesn’t strategically fit.”
What else can you do to improve the relationship with sales?
It’s not uncommon for the relationship between product and sales to be strained. The sales team has a clear job: close deals. Often they’ll do it by any means necessary, which may include promising any feature a client wants in order to win. Then they throw that over the fence to product and ask/tell you to build it. And around and around we go…
My immediate countermeasure is transparency. Product teams tend to get insular the more they’re barraged with requests, information and demands. Do the opposite. Be fully and completely transparent.
It starts with the roadmap. Make sure the roadmap is completely accessible to everyone all the time. Product teams should have nothing to hide.
But it’s not enough to simply have the roadmap, sprint plans, etc. fully available, because honestly, no one is going to look. So you’ll need to book regular meetings with the sales team (which is true of other teams/departments as well) to walk them through key things and make sure they understand why you’re doing what you’re doing.
You can use regularly scheduled meetings as opportunities for the sales team to share what they’re hearing and for you to share what’s going on—a bi-directional conversation designed to drive understanding and alignment. After all, you’re all on the same team, right?
On Twitter, both Jeffrey Erickson, Founder & CPO at Viable and Jason Lemkin, Founder at SaaStr suggested leaving room in any sprint plan for sales-led requests:
I’ve never done this before, but I can see how it works, especially as you scale. You may even have a product team dedicated to specific client requests. Alternatively you could allocate specific sprints to client requests, similar to how I’ve recommended before that you dedicate time to bug fixing.
How do you decide if you should build a feature to close a deal?
There’s no easy or perfect answer to this question, but here’s a framework that may help:
1. Is the feature already on the roadmap?
If yes, fantastic! Let the client know it’s in the plan and approximately when it’ll be delivered (I always hesitate to provide exact dates unless you’re certain). Hopefully that’s sufficient to keep the client happy, but there may be push back on timing. If so, you can negotiate doing the work earlier and shifting the sprint planning.
2. Does the feature request fit your strategic goals / mission?
Build enough custom features and one day you realize you’re building a completely different product. That’s not usually a good thing. Ideally the company’s goals and mission are clear, and they can be used as a filter for all feedback coming into product.
Having said that, everyone should be open to the possibility of pivoting. It’s rare that you’d pivot off one client request, but everything is a signal. Collect enough signals and you may realize you’ve built the wrong product, or you can change the product and reach a new customer segment or expand into a new market. If you’re going to pivot, do it the right way.
3. Does the feature solve a real problem? Is it well thought through and designed? Do you know how you’ll measure the feature’s value?
Don’t build stuff for the sake of it. Make sure you understand the root problem, because how you solve it may be different from what a customer is asking for. This is where doing proper customer discovery is so important.
Once you know the problem is real, you need to make sure the feature’s design (i.e. how it works) is done well. If you’re building something for a specific client, you’ll most likely have to show them the proposed solution and get their thumbs up on it. But be careful here, because they may push the feature design in the wrong direction.
Finally, you need to know how you’re going to measure the features value and efficacy, both qualitatively and quantitatively. Data is critical to the product management process.
4. Is the feature valuable to other clients? Can the request be bundled or expanded into something that’s valuable to more customers?
Ideally you’re never (or almost never) in a position where you build something for one client. Everything has a cost and new features (even small ones) add complexity to a product.
When a request comes in through sales, you can look at it from a few different perspectives:
See if similar requests have come in before; if so, this may alter your upcoming prioritization. This is especially true if lost deals are attributed to missing this functionality.
Talk to similar customers and see if the feature requested would interest them; this may give you more confidence in the request and help you learn more.
Try and bundle the request into a relevant theme, which ideally is already on the roadmap; this can be shared with the client, so even if their specific request isn’t being addressed they know you’re focused on stuff that matters to them.
Bundling feature requests into themes is ideal, but not always possible. As Jason Knight points out on Twitter:
5. Are they willing to pay? And are they willing to sign a contract in advance?
Money matters. 😝
The sales team will have to be comfortable asking this question. If the answer is “no” it gets tougher to move forward, and their disinterest in paying may be a sign it doesn’t really matter. If they say “yes” it doesn’t mean you’re absolutely going to build what they want, but it’s now worth digging in, understanding the problem more, etc.
As soon as you take money from a customer you’ll have to truly prioritize the custom work they want done. There’ll be an expectation that their work takes precedence and gets delivered precisely (on time, on budget). So there’s clear risk involved.
6. How big is the potential customer?
In this podcast episode from One Knight in Product, Jason and Jennifer Yang-Wong, VP Product at Contrary (previously: Uber Eats) ask, “What % ARR does a deal have to be worth before you betray the roadmap?”
First, great question.
Second, someone put “I betray the roadmap for money” on a t-shirt (or some derivative of that!)
In the earliest stages, landing a marquee customer is incredible, especially if they’re willing to be a reference (you should fight for that.) Those marquee customers may want specific features built, and not only will they represent a large % of your revenue, they’ll be a building block atop which you can acquire other customers. I’d still recommend minimizing the customization you do (and verify all the other questions too) but in this scenario you’ll likely jump.
At a later stage, as your company is more established, each customer is a lower percentage of your total revenue. But remember that the sales team is trying to hit a quota, so they’ll feel the pressure no matter what.
Generally speaking, the bigger the customer the more resources you’ll allocate. The big risk is that you get consumed by that one customer and can’t focus on anything else. I’ve seen this happen to small startups, and they can be crushed by accident.
7. Are you OK with the tradeoffs being made?
Every choice you make is a tradeoff.
“We can build such-and-such, but we’ll have to pause that other thing we were going to do.”
Product managers spend a lot of their time identifying, communicating and debating tradeoffs. It’s basically the job.
If you’re being transparent and communicating with the whole company, including the sales teams, these tradeoff discussions are easier. But I guarantee you someone will say, “Can’t we just do it ALL?!?!” The answer is always, “No.” And, “Pick.”
The 7 Question Framework for Deciding to Build a Feature to Close a Deal (or Not!)
I’ve attempted to visualize the seven questions above in a diagram. This is not 100% perfect for all situations, but it might help you (and the rest of your team + company) think through how you make strategic decisions.
“Opinions are like assholes, everybody’s got one and everyone thinks everyone else’s stinks.” - Simone Elkeles
Great article Ben! You really talk about issues that resonate with me in the startup/entrepreneur world!