It’s not every day that product development and B2B sales are found in the same blog together.
However, when I transitioned from my background in software engineering and the role of Product Owner into one of Business Development and Sales Management a few years ago I noticed something interesting. Not only have I developed a new set of skills. I’ve also found myself reflecting on some of the similarities and crossover between the two roles.
Whilst this title can have various associations, for this blog, we’ll consider the role to be someone who conducts the day-to-day development direction of a product to meet user and stakeholder needs. Ultimately, it’s the person accountable for a product’s success or failure.
It’s a role that requires constant attention to detail. Specifically, understanding evolving stakeholder needs, effective communication between many individuals, and not being afraid of taking responsibility.
What can B2B sales professionals learn from the world of product development?
Qualify Early; qualify often
There is a phrase sometimes used in product development; “fail early, fail often”. The intention is to avoid spending large amounts of time or investment in something that ultimately “fails big”. The associated approach, popularised through agile software development, is to test the simplest and earliest version of any product or idea against the user base or stakeholder group for analysis and feedback. Whilst the product may not be fully functioning, a decision can be made about how and whether to continue. The goal is to save time working on the wrong or unnecessary features.
I can think back with fondness to an occasion early in my career as a junior developer. I happened to be working on a particular feature and had convinced myself that I had all the answers to create a masterpiece. As I worked hard and polished away, my thoughts strayed to imagine revealing the fruits of my labour like a silk sheet being smoothly pulled off a supercar to the sound of applause.
Instead of checking in with my stakeholders, I decided to save the results for a “big reveal”.
Hubris had allowed my judgement to become clouded. Unfortunately, instead of “oohs and ahhs”, the reveal was met with silence, frustration, and confused questions. As a result, I wrestled with the emotions of creative rejection and came to terms with the fact that I had wasted much time polishing the proverbial turd.
People don’t know what they want until you show it to them ~ Steve Jobs
I have learned we can re-use this mantra rephrased as “qualify early; qualify often” in B2B sales. It is vital that any potential sales opportunity is qualified at the earliest moment to avoid wasting time and investment. It is also essential to repeatedly qualify throughout the sales process. Just because you had a positive initial conversation doesn’t mean every subsequent discussion will yield positive results for both parties.
A game of asteroids
I like to consider product development as a bit like a game of Asteroids. For those lucky enough to be too young to remember, Asteroids was a simple, early computer game where the player pilots a ship in 2D space and shoots large rocks that split into multiple smaller rocks. You continue to shoot until all the small rocks have been destroyed. A popular strategy to win is to avoid too many small rocks floating around at any given time.
A common approach to product development is to record large requirements [big asteroids] up-front and then break these down over time into smaller requirements as needed, assuming the large requirements include the primary stakeholder needs. The alternative is asking for a full list of detailed requirements upfront. This can lead to large documents with unnecessary detail that muddy key, high-level requirements. Ultimately, preventing ideas and discussions of potential alternative solutions.
There are, of course, risks associated with identifying only “big ticket” items upfront.
Firstly, it requires strong product knowledge, associated industries, and the end-user community. Small but significant needs mustn’t be dismissed as “minor requirements”. To avoid this trap, “big ticket” items should be seen as important needs instead of the time/scale of a potential solution. Secondly, the big-to-small approach requires mutual trust in all parties so that a reasonable balance can be identified between needs and solutions. The old agile value of “Collaboration over Contracts” can break down if either party is unreasonable or inflexible.
Watch out for “big rocks” masquerading as “little rocks”
In sales, I found the “Asteroids” approach can be transferred almost directly. It’s important to record the key needs or challenges of a prospect at the start of a relationship. I also make sure to qualify and understand the needs clearly (see Listen, Ask, Listen Again below). Endeavour to develop a “trusted partner” relationship with prospects. I aim to develop a relationship of mutual trust with prospects. Then, as the relationship develops, I’ll explore the detail of their needs and potential solutions together.
If you work in B2B sales, I imagine you may have seen and completed comprehensive requirements documents. Such documents are often intended to protect organisational decision-making and apply an objective approach. However, they can sometimes obscure wider organisational needs. My experiences in product development have allowed me to work the angles and keep an open mind to needs or business functions that may exist off to the side.
Listen, Ask, Listen Again. Be Curious
I’d been working with a client for a little over two years when I had an opportunity to shoot the breeze one morning with a chap called Alan. He worked in an administrative role and was a man of habit. He knew what he needed to do, when to do it, and each week he would get it done – like clockwork. Alan had joined the business after we had implemented a bespoke solution and was talking to me about how he used the software. “Every Friday, I run reports. One for every single customer. And I print them out and put them on the boss’ desk”.
I smiled at him. I was feeling good about the fact he was talking about the software we’d implemented and how he used it every week. “That’s great,” I said. But I noticed Alan’s face wasn’t reciprocating the positive emotions I was feeling. I waited for a moment and then realised something; Alan was complaining to me in a very polite manner.
I was curious. “Is everything working ok?” I asked. Alan looked pained but then said, “Yes”.
“Show me,” I said.
“There’s got to be a better way”
Alan spent the next few minutes showing me the process he went through to create customer reports. Find a customer… click… print report… click… find next customer… click. He smiled at me, realising I could see the problem. It turns out Alan spent nearly 3 hours every Friday printing reports in this manner. “There’s got to be a better way”, he appealed. There was.
A week later, I was back with an update to the product. Alan was sure enough at his desk… click… wait… click… wait. I interrupted him for a few minutes to apply the update and showed him a new “Print All Customer Reports” button. Catchy.
What was curiosity worth that day?
3 hours a week x 48 weeks = 144 hours / 7 hours = 20 days/year. The improvement marked a big step forward in client success.
The experience made me realise the same skills apply between product development and sales. When a client or prospect tells me something, I listen carefully, ask a follow-up question to deepen my understanding and listen carefully again. Having a curiosity for deeper understanding has helped me build trusted partner relationships. Clients and prospects don’t always express exactly what they need but instead might describe problems or challenges they’re facing. Listen for these and engage to consider solutions.
The hippo enclosure
At the very start of my career, during the rise of the “dot com boom”, I was working on a freelance opportunity to redesign a company website. I was working directly with the owner-manager called Willy. Willy was in his 70s, quite eccentric. He’d run a successful business for most of his life and had quite a fierce temper by all accounts. What Willy didn’t know about his business wasn’t worth knowing.
However, when it came to discussing the website, Willy presented me with an immediate dilemma. When I inquired about his thoughts, his eyes started to dazzle. He described how he would like visitors to his website to have the experience of flying through a “window of opportunity”. To ensure I hadn’t misunderstood, he went on to say he wanted the visual experience to be the 3D view of someone flying through a window, after which they would come across his products and services. After he’d finished regaling this idea, he paused, grinning, and looked me right in the eye to ask if I could do it.
I realised I had to make a decision.
The idea sounded slightly ridiculous, and I started to wonder if Willy had considered what he actually needed from a website. I was pretty sure his idea could be brought to life, but I would be betraying Willy’s trust in me to simply “yes” him. Instead, I responded plainly with, “What outcome does your business actually need from a website”?
Willy stared at me for a moment, his head turning slowly purple. He looked angry. I waited for an outburst. But instead, when he spoke, Willy’s voice was surprisingly soft; “no-one’s asked me that question before”. From across the room, the voice of his business partner, a straight-talking Irishman, piped up. “He just spent £100,000 on some idiots who designed our current mess of a website.” He then added, “Come on lad, you’ve earned yourself lunch”. Willy drove me in his sports car, which was equally eccentric. We ate lobster.
Yes isn’t always the right answer
After lunch, I had the opportunity to view the current website. It was awash with animations. Flaming text. Everything you can imagine from a late-90s website, but it was of little functional use. It was clear to me what had happened. The previous company had not only taken Willy for a ride. They’d implemented every single random thought without question.
With Willy’s approval, I spent the afternoon talking with the sales team to understand their relationships with prospects and what we’d now term “the buyer journey” looked like. It became apparent there were two primary needs for the website
Quick and easy access to technical information
Willy also conceded that he wanted the giant rotating picture of his face and the animated logo gone. The new website we created together, by all accounts, was a success.
Building trust is essential
Building a trusting relationship with the most influential member of the buying team, or the ultimate decision-maker of the business, is arguably one of the most essential steps in the B2B sales process. However, another critical aspect of the sales process that must not be overlooked is the end-users of your product/service. Naturally, the decision-maker and end-users can be the same – but not always. It might feel easy or tempting to “yes” your way through the sales process with such an individual. However, you’ll risk creating a problem down the road if you ignore the “real” business needs.
In our business (implementing CRM), it is important to understand or engage with key members of teams such as sales and marketing to ensure the best solution is delivered. Such engagement ensures the best solution and also gains buy-in from those team members – critical in a successful CRM implementation.
Ask yourself, “Who am I not speaking with?”.
In B2B sales, this experience helped me learn the importance of identifying the buying committee and asking, “Who am I not speaking with?”. I learned that Identifying and engaging with the wider buying audience allows for a deeper understanding of needs and broader relationships to exist. Needs that are not on your radar may exist, and working with more than one individual will increase your chances of closing.
There are four practical lessons I have learned over the past few years whilst reflecting on my previous experiences as a product owner.
Qualify early and often – don’t waste time chasing the wrong prospects or trying to close deals that aren’t right. Instead, qualify and focus on the prospects and deals that are a good fit. Remember to qualify at multiple points during the relationship
Track key needs and break them down to discover detail – start with the important and/or high-level needs and break them down into more detail as the conversation and relationships develop
Listen and be curious – ask questions and listen carefully, ask follow-up questions to ensure understanding and build trust. Be curious about your prospect’s needs
Consider your audiences – ensure you’re speaking to the best individuals to both understand needs and close the sale
Of course, there are probably more similarities I could draw on, such as the skills required for software project completion vs closing a sale. However, I feel these are the most relevant.
Have your own thoughts on this? I’d love to hear them
We use persistent cookies that stay on your computer or device after the browser has been closed and last for a period of time specified in the cookie.We use these cookies for remembering your language preference.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.
This cookie is installed by Google Analytics.
Provided by Google Tag Manager to experiment advertisement efficiency of websites using their services.
Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.
Hotjar sets this cookie to detect the first pageview session of a user. This is a True/False flag set by the cookie.
Hotjar sets this cookie to identify a new user’s first session. It stores a true/false value, indicating whether it was the first time Hotjar saw this user.
Hotjar sets this cookie to know whether a user is included in the data sampling defined by the site's pageview limit.
To determine the most generic cookie path that has to be used instead of the page hostname, Hotjar sets the _hjTLDTest cookie to store different URL substring alternatives until it fails.
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
Mouseflow sets this cookie to identify whether a visitor is new or returning.