Lessons from product development that made me better at B2B sales

Definition: What is a Product Owner?

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. 

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. 

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

1. Quick and easy access to technical information
2. Pricing.

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.