54: How to stop common B2B dysfunctions in the product team
For those of you who work in business-to-business (B2B) companies, how many of these sound familiar?
“Our product team is always called in to fight customer fires post-sale.”
“Sales people bring product managers along to answer customers’ techie questions.”
“The product team isn’t allowed to speak to customers unless they’re in a sales meeting.”
“Our sales team will often sell something that doesn’t exist, then make it the product team’s problem to make it happen.”
“Our product backlog is full of priority feature requests that the sales person says the customer needs before they’ll purchase.”
You’re not going crazy – nor are you alone. These are common dysfunctions plaguing product teams in B2B companies the world over.
How do you stop them happening? Read on for some suggestions.
A square peg in a round hole #
In B2B companies there is usually some kind of ‘solution selling’ methodology in place. The specifics of each selling technique may vary from case to case, but they broadly tend to be along the lines of:
- identify a customer’s pain points;
- highlight the implications of the problem for the customer’s business;
- present a product solution;
- tackle customer objections; and
- close the deal.
Not an unreasonable approach, I’m sure you’d agree. But isn’t it a coincidence how often the solution happens to be something the vendor can provide, regardless of the customer’s problem?1 With all that pressure on the sales people to close deals, it must be so tempting for them to go ahead and hammer that square peg into the round hole.
Here’s why: when a sales person identifies a plausible opportunity with a customer, they’re typically expected to forecast the deal. This prompts them to look ahead to the commission that they’d gain from the deal.
In their minds, that commission is already theirs for the taking. Loss aversion means they push even harder to close the deal and secure the commission. Details such as the practicality and suitability of the solution for the customer – and feasibility for the vendor – can be left by the wayside.
This is one of the reasons why product teams so often find themselves chucking their carefully researched roadmap out of the window in favour of a creating a product for a target market of one customer.
Two different conversations #
A common misunderstanding is that product teams can learn about customer needs during a sales meeting. Simply put: they can’t.
A commercial negotiation is a game between the sales person and the customer. Both sides know they’re in the game, and each plays their cards close to their chest.
The sales person is trying to find the right combination of words, assurances, product and services that will convince the customer to sign on the dotted line.
The customer is typically seeking evidence that the product will deliver on the sales person’s promises (or an assurance it will be rectified if it doesn’t), is trying to negotiate the best value deal for their money and is perhaps hoping that the purchase will make them look good.
This poker game is by definition adversarial – and frankly neither the right time nor place for a customer development discussion.
If you’re attempting to understand market problems and validate possible solutions, you shouldn’t be pitching anything. Instead you want your customer to open up about their working practices and problems.
With a sales person in the room, the customer will be less likely to open up. To reveal the extent of their problems would concede the sales person an advantage in the negotiation (greater customer need = charge more).
Besides, a product manager typically needs to speak with users in the first instance. It’s not always the case (at least in the B2B world) that the users are also the buyers.
(Sure, at some point the product manager may be thinking: “How can I improve the purchase process for my product?” Chatting with the various people involved in a customer’s purchase decision would help the product manager to understand what makes them tick, but this is more about understanding buyer’s needs and processes, not pitching product at them.)
By and large the best way to increase the odds of a product sale is to have a good product to begin with. And that comes from understanding and meeting users’ needs.
Don’t derail my deal! #
One of the most common reasons I hear for the sales team blocking access to the customer is that they’re afraid that product team’s user research will upset potential deals.
I’ve yet to meet a product manager that would wilfully sabotage sales of their own product. If a deal does go away, it’s far more likely that this was because the customer felt that that offer wasn’t what they were looking for, rather than because of an ill-chosen word by a product manager.
Nevertheless, some prudence and sensitivity to ongoing commercial negotiations is always a good idea, so if you see the sales team getting twitchy about a particular prospect, maybe skip over that one. There should be plenty others in your target market to speak to.
How a B2B product team should be working #
Each of these examples are symptoms of a more widespread condition: a product team not being allowed to be a product team.
Ideally a B2B product team should:
- have direct, unfettered access to both potential and existing customers and users, outside of commercial discussions;
- not have to fulfil the role of sales support, either pre- or post-sale (there is value in this function, it simply should be a different team providing it);
- have authority over their products’ roadmap and to veto one-off products, features or solutions before they’re sold to a customer; but
- be able to assist the sales team by sharing insight into the market problems that can be solved by existing products.
Keep up! Product management has evolved #
Many companies haven’t realised the role of product management has changed dramatically over the last twenty years. It’s evolved from being a profession characterised by strict process adherence and focus on technology to one that’s passionate about understanding and solving user problems with empathy, agility and a more scientific approach.
With that in mind, it’s no wonder that so many companies, particularly large ones, are only now just beginning to recognise the untapped potential in their product teams.
But we’re not there yet. Partly standing in the way of this evolution is a chicken-and-egg problem: product teams at these kinds of companies tend not to be sufficiently empowered to change their role and responsibilities.
It’s not a lost cause, though; there are things you can do.
Play internal politics to win #
Whether you like it or not, where there are people, there’s politics – especially in companies.
As a product manager, you should have a few advantages over the other players in this game: objectivity, evidence and empathy. So try this:
- Map out your internal stakeholders – think about who’s influential in the company and interested in what the product team does. Understand who’s pro-product and who’s not.
- Figure out stakeholder needs and goals and how a more empowered product team would help them to achieve what they care about. If you can prove this to them with things you’ve already done, even better.
- Enlist their help as champions for the organisational changes the product team needs.
Speaking about his time as Deputy Director at the UK’s Government Digital Service (GDS), Tom Loosemore knew his team had to win over the ministers with their prototype (the ‘alpha’) to earn permission and trust to move into the larger next phase of GOV.UK:
A government minister should look at the alpha and say: “I want one of those”.
There was no way we’d get permission for the real thing unless the customer had that reaction.Tom Loosemore, speaking at Mind The Product Conference in London, 2012
In other words, while the alpha of GOV.UK may have been tackling a selection of actual user problems (advice when you’ve lost your passport abroad, and so on), the most important user persona for the alpha was in fact ‘the influential minister’. Once they had the support of the ministers, they could really start to solve user problems.
Call it playing politics, but it ultimately enabled something very beneficial for users to happen.
Points to remember: #
- Think about how you would identify and win over influential stakeholders in your company to build a better product team.
- How could you allow stakeholders to experience first-hand the benefits of a different approach to the product team?
Get over your Cassandra complex #
If you know the story of GDS, you’ll know that it was Martha Lane Fox who convinced the UK Government to establish GDS in the first place and give them permission to work in a different way. This brings us nicely to the second way to make change happen in your organisation: bring in a respected, external expert.
The expert may well be making exactly the same points in favour of empowering the product team as you have, but their words will carry more weight because they’re seen as an expert. This is another cognitive bias known as the halo effect.2
In Greek mythology, Cassandra, the daughter of King Priam of Troy, was blessed with the gift of prophesy but cursed with never being believed. She correctly foretold the fall of Troy at the hands of the Greeks, but nobody would listen.
As someone who’s at different times been both fighting for change within an organisation and that external product management expert, I truly appreciate how incredibly frustrating it can feel to be forever speaking the truth without being taken seriously.
If you feel like you’re getting nowhere fast, change tack. Try making your point more convincingly with evidence – show, don’t tell – or bring in an external voice to make your point for you more effectively.
Points to remember: #
- Consider bringing in an external voice to help win over the influencers and decision-makers in your organisation.
- Try not to be frustrated if decision-makers are more influenced by external voice over yours – this is cognitive bias at play.
Wrapping up #
- Because sales teams use commission as an incentive, this tends to be what drives their behaviour. If you want to change their behaviour, change the incentive.
- A sales conversation is not the right context for a customer development discussion. A product team needs direct access to its users and customers.
- Effecting change in your company without authority means you need to understand the needs and aspirations of your influential stakeholders to make them your champions.
- Sometimes you need to use the halo effect of external voices to get people to listen to the same good points you’ve been making all along.
Understanding why particular dysfunctions have crept into a B2B company puts you in a far better position to set about eradicating them. True, it will be hard work and take time for a disenfranchised product team to gain trust and authority, but it’s by no means impossible.
For more about making the relationships work between product, sales and other teams in your company, grab yourself a copy of my book The Practitioner’s Guide to Product Management. It’s a fine read, though I’m admittedly biased.
A version of this article was originally published on Mind The Product on 4 February 2016.
- I’ve only ever worked with one sales team that would genuinely recommend other vendors’ products if they were more appropriate to their customers’ needs. (At Zeus Technology, long since acquired.) Funnily enough, they had a tremendously good relationship with their customers, who would contact our sales team first before making any purchasing decision. ↩
- As an aside, bringing in actual users to describe how painful the problem you’d be solving is for them, either in person or via video clips, can also be incredibly powerful when you’re making the case to create a product or deliver a particular new feature. This is less about the halo effect, more about triggering empathy with the decision-makers. ↩