A little over 18 months ago, I transitioned from my Software Engineering role into one of Business Development and Sales Management. Since then, I have developed a new set of skills and reflected on some of the similarities and crossover between the two roles.
As I grew in seniority within software engineering, I developed into 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, understanding evolving stakeholder needs, effective communication between many individuals, and not being afraid of taking responsibility.
So, what can we learn as sales professionals 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 where 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.
Hubris had allowed my judgement to become clouded. Instead of checking in with my stakeholders, I decided to save the results for a “big reveal”. 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 coming 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 sales. It is vital that any potential sales opportunity is qualified at the earliest moment to avoid wasting time and investment on your and your potential client’s behalf. 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, asking for a full list of detailed requirements upfront, can lead to large documents with unnecessary detail that muddy key, high-level requirements and prevents 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 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.
In sales, I found the “Asteroids” approach can be transferred almost directly – it’s important to record the key needs or challenges from a prospect at the start of a relationship. I make sure to qualify and understand the needs clearly (see Listen, Ask, Listen Again below) and watch out for “big rocks” masquerading as “little rocks”. Endeavour to develop a “trusted partner” relationship with prospects. I aim to develop a relationship of mutual trust with prospects and, as the relationship develops, explore the detail of their needs and potential solutions together.
If you work in 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 sides.
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, who worked in an administrative role. Alan 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, 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.
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 and 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 free-lance opportunity to redesign a company website. I was working directly with the owner-manager called Willy. Willy was in his 70s, quite eccentric, had 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 as 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 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” and then added, “come on lad, you’ve earned yourself lunch”. Willy drove me in his sports car, which was equally eccentric. We ate lobster.
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 but had also 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 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 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.
In 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 18 months whilst reflecting on my previous experiences in Software Engineering. Of course, there are probably more similarities I could draw on, such as the Definition of Done vs closing a sale; however, I feel these are the most relevant.
- 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.
Perhaps you have some perspective on this as a reader and would be interested in engaging or feeding back to me – in which case please reach out to me.