Hi, I’m James. Thanks for checking out Building Momentum: a newsletter to help startup founders and marketers accelerate SaaS growth through product marketing.
A great lead comes in: a real household name, with money to spend. They get through your SDR team qualification with ease. The AE’s discovery call goes swimmingly. The demo is great. And then they ask one single question that threatens to derail the entire conversation.
Prospect: “Do you have [feature]?”
AE: “No, but it’s on our roadmap.”
Prospect: “Do you know when it will be available?”
AE: “No. I can check with our team and get back to you.”
And the opportunity disappears, never to be seen again.
In this post:
Why does this happen?
It’s not because you don’t have the feature available right now.
It’s not because your sales rep doesn’t know what the feature will be available. Usually, it’s an “nice-to-have” compared to the main product anyway.
This phenomenon happens when the sales rep doesn’t understand what the prospect expects the feature to resolve, and what benefit they are attempting to realize from it.
Without this knowledge it’s difficult to overcome objections, like re-prioritizing the importance the overall solution. This trough of momentum makes it difficult to build the urgency needed to move the deal forward.
To overcome, reps need confidence in their understanding of the customer and their problems. This confidence enables them to set expectations, dig deeper with questioning, and move the issue forward.
Usually, this skill comes from reps with domain knowledge: those who’ve done the work before or have intimate knowledge of the workflows involved. SaaS businesses with small teams, or those that are scaling rapidly, will find it harder to educate their team well enough to handle feature objections.
And then (even more annoyingly) you’re missing out on the rich and valuable information to feed back from the sales process to the product team. It makes it harder to gain mid-funnel feedback that could impact product prioritization, and unlock a lot more sales.
So how can you empower sales reps with the information and tactics they need to overcome these objections and push the opportunity forward?
Overcoming feature objections
Luckily, reps can maneuver around these conversations with a little help from the basic roadmap information you may already have.
Splitting your roadmap into ‘landing shortly’, ‘near term’, and ‘planned’ timelines helps your team set those relative expectations with prospects and have more productive conversations.
Educate your team on the problems to be solved
One prerequisite to overcoming objections is to give sales and success teams enough information, without overloading them on the technical details.
There are many different ways to align product, marketing, and sales, but I’d recommend the Jobs To Be Done methodology.
You can read more about the JTBD methodology here, but watch Clayton Christensen in this primer:
JTBD can quickly become imperious for customer-facing teams, but you can use the core concepts to help them understand what customers and users are trying to achieve.
There are five key components of a ‘job’ to be achieved:
Who: Who is the executor of the job, who will be overcoming the problem?
What: What’s the objective that the job executor wants to achieve?
How: What is the process the job executor will follow to achieve the objective?
Why: What are the intended outcomes that indicate success from completing the job?
When/where: What contextual factors matter in this scenario?
Using this framework when communicating the problems under investigation and features to be launched helps sales teams ground product development in a story they can internalize and retell.
Set expectations, question, move forward
Armed with that knowledge, give your team the tactics to overcome those objections.
Here are some template approaches to ensure your roadmap helps, and doesn’t hinder, your team’s sales conversations.
Landing shortly
These are features that are currently under planning and development that your product team have 95% confidence will be implemented within the next few months. The designs are set, the technical build is estimated, and we know what problem it’s intended to solve.
Set expectations:
This is something our product team is working on right now, it’s slated to be available this quarter.
We’re expecting this to [solve problem] by [method].
Question them:
How would you use that?
Is it a feature you’ve used before? How do you achieve it today?
How is that met by the other solutions you’re evaluating?
Move them forward:
Ask if they would be interested in seeing the mockups, or getting early-access when it’s available
Near-term
These are features that you expect to deliver next quarter: they may be loosely scoped, but the opportunity exists to get information that will validate your problem/product assumptions.
Set expectations:
We’re planning to start on this in the next few months for it to be available next quarter.
So far, we understand the problem to be solved is [explain problem].
Question them:
How would you use this feature?
How will that impact your business and workflow?
What problem would it solve for you?
What benefit do you expect to realize from this, and why?
Is it a deal-breaker to moving forward with our solution shortly?
Move forward:
Take notes to understand their problem and share with the product team, to both provide additional validation and see whether the planned features will meet their needs
Dial up the urgency and the pain their other problems are causing, that can be solved instantly with your solution today
Planned
Planned items are in the proposal and ideation stage. Set those customer expectations as such, and deep-dive for details on how customers would use these features. These situations are helpful for impacting development prioritization when there’s a dollar amount available to be indicative of future opportunities.
Set the expectation:
I know it’s something our product team are evaluating this right now, but need more information on how to best solve this.
So far, we’re expecting to help customers [solve broad problem area] and achieve [result].
Question them:
How would you use this feature?
How will that impact your business and workflow?
How do you do this today?
What problem will it solve for you?
How do you achieve the same outcome today?
Is the capability a deal-breaker for this type of solution?
What’s the driving force behind this requirement?
Move forward:
If their requirements are complex, confirm by email to make sure there’s no misunderstanding
Explain that the feedback will really help the product direction, and ask if they’ll be open to contact by the product team
If the deal isn’t a requirement to moving forward, explain how getting onboard now is an opportunity to be involved in the product design and beta process and ensure their needs are taken into account
Avoid saying no and ensure the feedback loop is closed
It’s too easy to say no, shutting down the conversation.
If you can, attempt to turn it back round to the features you do have by re-prioritizing the problems you can solve.
But taking the time to understand requirements and feed that insight back helps product teams to build solutions that accurately meet the needs of your prospects and customers.
Taking note of the problems and features that prospects are interested in, even if the feature delivery is some time away, can also help with re-engaging in the future.
Thanks for reading! Let’s connect on Twitter and LinkedIn, and let me know what you thought.
If you found this post helpful, will you share it with your network?