064: Empathy in Sales with Ginger Whalen

Ginger Whalen: @gingerwhalen

Show Notes:

• 01:28 - Everyone Does Sales
• 02:11 - Sales is an Exchange: Understanding and Solving Others’ Problems
• 05:58 - “Personas”; Empathy vs Sympathy
• 11:47 - Empathy Requires Introspection
• 15:12 - Persona Example
• 20:33 - Making Incremental Improvements
• 23:15 - Challenges in the UI Business Space
• 29:25 - TL;DR on the Business Development Process

Resources:

• Thinking, Fast and Slow by Daniel Kahneman

Transcript:

CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 64. My name is Charles Lowell. I'm a developer here at The Frontside. I'm here with Jeffrey Cherewaty. Hello, Jeffery.

JEFFREY: Hey, there.

CHARLES: With us today is someone also at The Frontside but not one of our developers. Her name is Ginger Whalen. Just to give you a little bit of backstory on her and why I'm so excited to have her on the podcast is we, about the middle of last year, began a search to bring someone on to help manage and grow and just have their eye on our business pipeline because that's something that's really, really critical, it turns out, to a software agency is making sure that we have clients. We put together a pretty extensive search plan and then we executed it and it was, I think about six months but in the end, we ended up hiring her.

The reason we did was because she had a very unique take on what we would typically deemed the sales process so we learned a lot about it and I wanted to have her on the show so that we could just kind of share with our, I would say, mostly skewed on the technical side audience about what a healthy sales process might look like. Welcome, Ginger. Thank you for coming.

GINGER: Thank you. My pleasure. It's so funny when people talk about sales and they say to me, "Oh, you're a sales person," I think that's so funny because I've never viewed people to be in sales and people not to be in sales. To me, everybody is in sales because all sales is to me is somebody just exploring somebody's problems with them and then when the time's right, you educate them and then you help them see the value of acting on some solution. Who doesn't do that? We all do that.

CHARLES: We all do that. We do it in our day-to-day when we're proposing and discussing and talking about technical solutions, the same principle may be applied in a different level.

GINGER: Yes, some people are just on the hook for it, that their professional goals are tied to that end game.

CHARLES: Yeah. One of the things that struck me as kind of setting you apart when we were doing the interview process is the way in which, I want to say the focus of building those relationships and kind of the focus on understanding and understanding who exactly potential customers are and trying to categorize them and tailor our message so that we can actually maybe help them. Maybe you could explain a little bit about that. What's the front half of that process looks like?

GINGER: That's kind of the bigger subject. I guess sales is the exchange, the educating and helping somebody solve a problem, get what they want to solve that problem. But if you're not speaking in their language and sometimes you hear the term 'knocked around personas' -- the persona you're talking to or the person you're talking to -- if you're not speaking in their language or addressing their pain, talking about their problems, it just so boring to them. It doesn't really seemed like it's going to solve their problem and you just don't hit the target right. You're probably not going make a sale in the end.

That’s what we talked about when we first start talking with Charles and The Frontside team. We talked about personas, who are you approaching, what are their pains -- their business pains, their pains with their engineering team? What do they come to the table with and what would they like you to help them solve? The subject today, we're going to get into this a little bit later about empathy and then is really what it's all about is that gift of really understanding somebody else's experiences, somebody else's problems, their emotions and how we use that in sales as we're going to talk about a little bit more today.

CHARLES: Yeah, I really like that because the drive there is to maybe not always shoot for a sale, to really try and understand like you said, someone's problems and just go out there and talk with interview, listen to a lot of different people and realized you're not going to be a good match for most of those people out there. If that's the case, not trying to view that as a potential opportunity that you want to just kind of force through but rather say, "How can I help this person even when it's not through my services and developing that and having this sales process?" because I think we tend to have a stereotype of what it is as being like I have a goal. When I want to interact with this person, what my agenda is actually to make a sale to them. It's clearly not like that. I think it varies from business to business but that's kind of the stereotype that I had in my head before this process began.

JEFFREY: It feels easier as an engineer to be able to say what I'm trying to do is solve your problem versus what I'm trying to do is a self-centered like, "I want to have your business." That's very different approach to the problem.

GINGER: That's so funny because I view it as exactly the same as what you guys do. You're solving problems, you know the end game is you're going to write this code to figure this out to do this thing and this thing is your end goal. That's the same thing I'm doing as I'm trying to fit my solution with this person but the means to get there, I just have to let it unfold.

Sometimes, it's really hard and sometimes it's really complicated and takes a lot of code and lot of trying and then trying something different, then that broke and then trying something different again. In sales, it's the same thing. Especially at this level, when you're with a consultancy, you have multiple buyers or multiple personas out there. You're selling up into an organization that can get pretty complex and you can have some fits and starts, just like you do when you guys are coding and trying to solve a problem.

CHARLES: Now these personas, this was actually something that was really interesting to me, the kind of introduction is this as you understand the problems and pain points, you're trying to collect them into related that this person has these general challenges and problems that need to be solved. How do you go about developing those personas? What is a persona and how do you go about developing them?

GINGER: First, you have to know who your decision maker is in an organization. From that, you develop your different personas. Now, some of these personas are the absolute decision maker at the end so the guys can assign. Then some of those personas are influencers throughout an organization. For example, in this field, we talk often to a lead developer. We talk to VP Engineering. We talk to CTOs. We talk to presidents and CEOs of organizations. They probably have different organizational goals, different things they're on the hook for.

They have a common vision, absolutely that they're all working toward so maybe a business growth goal that they're working towards. But the VP Engineering might care more about the cohesiveness and the development of his team. He’s going to be really looking for an engineering team that fits well with his team. He wants to make sure that their productivity doesn't go down. He wants to make sure that this team merges well with his so he's thinking about lowering his risk through this experience, keeping everything smooth.

Where somebody at a different level, a CEO is maybe looking at something a little bit different. Are we going to hit this deadline so we can get this product out, so we can get our first customer, so we can get some revenue in? Maybe he's just looking at bottom line numbers. If they come to the table and they have all these different problems or different pains, you really have to speak to each one of them about their pain and make sure you're addressing that. That takes some empathy. Not sympathy, not saying, "Oh, my gosh. I feel so sorry for you having all these problems." That's sympathy. That's pity.

But empathy is not about telling your story, "Oh, yeah. That happened to me." No. It's about understanding their story. It really does take some listening in the beginning to develop your personas and to really get, not coming to the table and saying, "I think this is what his problem should be because he's this guy, this level, in this organization," but really listening to them and letting them tell you what their concerns might be. Don’t be afraid to ask for those because that is how you develop those personas.

CHARLES: Right. You really just have to walk in a lot of different shoes and then write down those stories. That's what a persona is, it's writing down the narrative based on trying to discover people's actual experiences.

GINGER: In the old days, they say personas are about demographics like this guy is about this age, eats this for breakfast and lives here and has this sort of family life. It's a lot more developed than that now and it really again focuses on their pain because you're the consultant in there. That's what they want. They want somebody that's going to be able to educate them on their services or something in the industry, teach them something about their business would be great. But what they're really looking for is someone to help them solve these problems, "Help me solve these problems. Can you do that?" and I would choose that person to work with if they can help me solve my problems.

JEFFREY: So much of this process feels like it's a lot of listening. It's a lot of deducing what the problems are based on what you're being told. At what point in the process do we present a solution?

GINGER: Yeah, a good question. Just like the timing of a joke. That's really important: the pauses and when to do what in the joke or just the flat. During the process, when you're gathering information, you're also qualifying them. As you're asking these questions and getting them to reveal their problems and pains, you have some questions. You really need to get answer to. This isn't just, "Let's go have coffee together and talk about your pains." It's really you're qualifying them. You have some strict qualifying questions that you know about an ideal client for your company.

Some of those qualifiers might be how many employees do they have, what size company are they, what stage of growth are they in? Are they hypergrowth? Are they scaling? Are they a startup? Are they in a certain silo of business? Do you do especially well in education or energy? Then triggers: what's going on with their business? Did they have a lot of recent personnel changes? Is that a trigger that usually helps you segment your ideal client profile? They just have an acquisition. Is that a good trigger or signal that they're qualified prospects for you?

While you're asking these questions and again, identifying your personas going through their pains, you're also qualifying them. I'd say when do you go to the part where you're selling -- Charles has been on sales calls with me and he's probably already noticed -- that you're always selling the value of your organization. You're always selling but as far as giving them a solution to their problem, you wait for that. You don't give that away, right away and you can miss your chance or miss the punchline if you give that away too soon.

I'd say, once you truly understand their problem and then you get agreement from them that this is a problem, this is really important to solve and there's some urgency tied to that, when you have those things, then you can begin your presentation and show them the solution to that problem. But there's two parts: one is identifying the problem, two really find out that they agree. Play it back to them that this is a problem, how does it affect them and if there's the urgency tied to it. That's what you need to know before you propose a solution, I'd say.

JEFFREY: It's interesting that you mentioned how much empathetic sales process also requires introspection and besides understanding the customer's pain points and what problems they need to solve, you also have to recognize what problems we are able to solve and what problems we enjoy solving and that I think is counterintuitive that empathy requires introspection.

GINGER: I agree. You have to intellectually and emotionally identify with somebody and to the point where you can really experience what their attitude or their emotion or their feelings is. That's definitely an introspective thing. Yeah, you're right. Not the typical old school salesperson that just blabbering all over the place, being an extrovert telling their story. It really is more of an introspective. I'll even say introvert way of selling and that can be very powerful.

CHARLES: As you do that, listening and do that introspection and then develop this understanding of your clientele via these personas, once these personas are developed, how do you integrate them back into the business development process?

GINGER: That's a good test to say, "Can I really put myself in this person's shoes? Do I understand them? Do I have a better bond with them now because there's a mutual respect because we understand each other's experiences and thoughts and attitudes, pains and problems about something? Can I put myself in this person's shoes?"

CHARLES: You spend time listening and talking and introspecting and developing these personas of your clientele so then how do you actually, with that information in hand, use that to build your business development process? Now that you have this information, how do you actually leverage it on a macroscopic scale? Like I'm kind of out there in the world now, I've got these personas in my tool box, how do I go out there and interact with people based on that?

GINGER: I view that as an overlay over a sales process. That's the umbrella over the whole sales process. In a sales process, we do our first calls or connect calls or exploratory calls, again where we're learning about the company and their products, getting to know our personas. Then as you understand that persona, when you get into their goals and their plans and their challenges, when you're in the discovery part of your sales process, that's the part where you can transfer those points of pain and their challenges into your solutions.

Again, that's just a part of the conversation where you're speaking about value of the company, you're letting them know you understand their pains. When you get to the presentation, this isn't really explicit. It's not explicit in saying, "I know this is a pain. This is a problem you have," you turn it on its head and you take those challenges that they've told you about and weave those into your solutions. It's kind of where the rubber hits the road there because if your solutions don't solve their problem, it's absolutely where you're going to figure that out when you're presenting or when you get ready for that presentation. Would it help if we talked about, maybe one of those personas and wove that through the sales process?

CHARLES: Yeah, I think that's a good idea.

GINGER: Okay, a popular one with our type of business -- the VP Engineering. The VP Engineering, when we're talking to him, we're really trying to understand what he values, what's important to him in his work, what problems need to get solved. This person is really caring about quality, the quality of the work and the value that they're getting for their money. We talked about their team developing, learning as they work with us.

If that's important, we're probably going to really stress the quality of our service. How do we do that? We’re going to talk about the way we code, the way we test, the way build software. We're going to give them supporting evidence and case studies of how this is played out. We're going to talk about the value in this. We're going to talk about, maybe how we've reduce some time, for example [inaudible]. We've done that recently with a client where he's getting better value for his money because we're talking about his [inaudible] in reducing some of the time to build.

If we're talking about the development of his team, that something he's really concerned about. Is my team going to continue learning? Maybe we can present a story or a case study about a team that when we arrived, it looked this way and when we left, it looked this way. They had these additional skills... I don't know... Maybe you can jump in here but there's a client we worked in where their skills were totally transformed with us pair programming or working alongside them. Something like that are really important to VP Engineering.

CHARLES: Yeah. One of the things that this process has taught me and made me see and try to cast for wherever I can find it is actually trying to really quantify and measure that value. I know that's really hard because what we do is development. That's a really long process. If the product you're developing is successful, that thing that you put in there is worth a lot of money. If, 'thanks,' then it's worth nothing at all and the thing that you did was negative value because it was just sunk cost.

Those are two huge extremes and it feels like how do you get a little bit more fine grained in that and say, "Here's this activity that we're proposing and it's going to save this much money." You hear a lot of this people saying that you should try and do this this but how do you actually go about it? One of the things that kind of working in this way has taught me is really to try and wherever possible, it's not always possible but attach monetary value to the tradeoffs that you're proposing and the solutions like saying, "What is the impact of the work that we're going to be proposing?"

"We think it will save you $30,000." When someone actually takes a look at that and says, "That is a lot of money." That is, "We think that this could save you 50 developer hours per month." They say, "That is a lot of time," which again equates into a lot of money.

GINGER: That would be huge. I'm sure that would make him smile.

CHARLES: Right, exactly. You always hear that but it's trying to be more deliberate about it and really you have to think a lot about it to try and get to that level.

GINGER: Yeah and you just help me thinking about it all the way to the bottom line like that is terrific because in this situation, a VP Engineering, that person might have to sell it up the organization and maybe he has to sell it to the CEO and maybe the CEO is not going to spend as much time with us, may not even meet us directly. Those bottom line numbers might be really important for this persona to internally sell to the person that's actually going to give the nod and about their concern about we're going to get it right the first time, how do we help them get comfortable with that? That’s one of those risk issues that a VP Engineering might have.

Knowing these thing about your persona, knowing the pain that your persona has, all these things can be woven into your presentation. This is where, again the empathy comes in because you are speaking to their pains, their problems. This is an emotional sale. I don't care how technical something is, it is always in the end is going to be an emotional decision. It really is. Who's that author we're talking about that? Daniel Kahneman? His book out there: Thinking, Fast and Slow.

He did this study where he analyzed super, super wicked, smart people and then the rest of us, smart people but normal people. He gave them different decision making challenges and they watched the brain patterns. In the end, the part of the brain that lit up was the emotional part lit up and not the rational side. Even though they may have weighed all the evidence and maybe had a much more complex rational decision making process with their data, in the end, the part of the brain that lit up was emotional side. No matter who it was.

CHARLES: Yeah.

GINGER: Good to know, right?

CHARLES: It’s an adaptation that our brains work so that we actually think that we're acting rationally so we fool ourselves into that. But most of the time, people are making decision with their guts.

GINGER: That's how smart we are. We fool ourselves that way.

CHARLES: It's the ultimate trick. I'm curious. When you have this process in place, you're developing, leaning on these personas, weaving them in to your solutions and the story that you going to be presenting to your clients, how do you iterate on that? Just like we iterate on software, how do you make those incremental improvements and take what you're learning and then feed that back into the rest of the process?

GINGER: First, I'd like to answer that on a human level. I think the way we all learn this is we just practice it. As we put ourselves in another person's shoes, here's the part about it is when we're really dialed into empathy, we're dialed into that feeling of that emotion that somebody has, we're sharing in that feeling. To do that effectively and even when you're presenting a solution to your persona sale situation, talking to your husband or wife, talking to your daughter, words matter. You're really do have to choose wisely and your tone of voice matters. If you're in person with them, your body language and the volume you're using. Those are some of the things that, I think will help when you're presenting or really in any situation to express that you're with them and you're with among the emotion.

Let's say that it's something you have an experienced, this VP Engineering, maybe he just had a huge failure. They did not get it right the first time. Their software broke. The money once spend on it proving that it was great, he had to spend on fixing it and starting over. Maybe that never happened to you, hopefully it hasn't but you feel the heaviness of it and you know sadness.

He’s sad, he's desperate, he's scared, he's going to lose his job, you've had those emotions. That's what you can join him in that emotion. Not pity, you poor thing. More like, "Oh, that sounds really tough. Wow, that doesn't sound like fun." That's empathy so you're there with them and weaving that into your presentation, again not just blowing it off, "Let's not have that happen again because it won't happen that way with us. Here’s our solution." That is blowing your chance to have some empathy and sit with them in that emotion for a bit before you get onto your solution. That would be one way to weave it into the presentation.

But that takes something for him to share something like that with you too because he knows you're going to counter it and say, "That's not us," but does he know you're going to share in that emotion? Like, "Hey, that didn't sound like fun. Wow. Heavy."

CHARLES: Yeah. I'm curious and this is maybe a little bit of a curve ball for you but as you come into, every business is unique. I think doing UI consulting is one unique business out of many. What has been the biggest challenge of coming into this space and trying to develop a clientele inside of it?

GINGER: The trick for me since I don't have a heavy technical background is to get away from the technical conversations. Since that's not my strength, I can bring in you guys, bring in a team when it's right, when that person is qualified. But the challenge with me is to find the business people that really want to talk about, "We had this great idea but we don't have enough of bandwidth to execute on it." I can get the idea sold internally and it was just too complicated for us to achieve.

I can get those conversations going where really, we're talking about pains, we're talking about business problems that you can approach in any business you go into. It doesn't matter what the end game is and what we're selling. It really doesn't. Everybody has these business problems. To get people to talk about these business problems is the key to make those context to get them to open up about those business problems, business pains then you can qualify and see if it's a fit for your solution.

The challenge is to initiate those conversations with people because people do want to get technical quickly and to back them up and to talk about the business first because in the end, it probably does have to get approved by somebody that really is thinking about the business pains and business problems, maybe differently than this person's thinking about it so you want to do the work in the beginning to let all the surface before getting into the technical stuff. That's been always a challenge, whether it's web design development, marketing technology or an engineering UI company like us.

CHARLES: Yeah, it's always a challenge. I think you said this at the very beginning of the podcast is you need to be speaking the language of the person that you're speaking with. It seemed so obvious but the reality is though, everybody might be speaking English or one of several human languages within each one of those human languages is literally a million different actual languages, which is carrying on the context of what those people experience in their daily lives. Sounds like what I'm hearing is that there's a specific language within this business and part of it is learning to speak parts of that language, then also be like, "I need an interpreter. I need to bring in someone to speak to this person in their language."

On the flipside, I think it's also great too. I'm not a native speaker of some of these higher level concepts and I think that our strength here is in speaking that strong technical language that other technical people can bond with immediately but when you start backing up and just talking about those higher level business concerns, it's really great also to have someone who speaks that natively. Also, that language of even higher than that of, "Let's understand each other's problems here," which is something that you're very fluent in. It is interesting to see that there really is many, many different languages within one language.

JEFFREY: I think even within the technical conversations, there are multiple languages. There are different levels of, I don't want to say understanding but different levels of comfort and familiarity with different technologies, with different stacks. A lot of the conversations we have with companies that ours is comfortable in the stack that we're comfortable in and we're presenting that to them and that's where they're coming to us in the first place is because we have that expertise and we have to translate it into, I think that they understand and that fits their needs.

GINGER: And that's something, I think you guys are really good at. I don't know if you're giving yourself enough credit there but I think you do ask really good questions about, "Tell me about the experience you want to build? What type of goals are attached to this project?" You guys asked about timeline. That’s a goal when you get launched by then. You guys asked what would you say the strengths to your team are. I've heard these questions when you're talking about requirements so you can start to assess, how complex, how much we're connected, pair program with them, help them. I think you guys do ask about goals and plans and challenges. It’s just kind of packaged up a different way.

CHARLES: Yeah, part of that is just having borne the battle scars of not asking those questions upfront, rather than gravitating through intuition.

GINGER: I think we all unfortunately or fortunately learned that way, right? "Don’t step in the puddle. Don’t step in the puddle. Oh! Did it again."

[Laughter]

CHARLES: Is there any way to learn that doesn't involve stepping in the puddle or stepping on the tack or falling out of your chair?

GINGER: I guess, if you're a baby and you don't know anything yet, you're maybe 50/50. You’ll get some of them right.

CHARLES: Yeah, it is funny. But just a brief diversion, I just remember there was a period in her life where my daughter would just randomly fall out of chair. It was out of nowhere. It wasn't like she was sitting precariously or whatever. She would just fall out. It happened a lot and I was like, "Wow, sitting in a chair is a learned skill." Anyway, it just made me think about that is that there was actually this pain-based learning process there.

GINGER: I wonder what the response was. Did the room laugh? Did the room say, "Oh, let me help you?" Maybe she was ahead of the game.

[Laughter]

CHARLES: A lot of times it involved tears, which made the laughing worse. I mean, you can't help but laugh. You can also hide it.

GINGER: Yeah. Maybe we do need to fall a few times to learn stuff.

CHARLES: Ginger, if you could summarize what your business development process looks like in a few sentences before we head out.

GINGER: I would say, take your time when you're talking to new people. Get to know them. Get to know who the person is. Get to know what their pains are before you tell them how you can help them. On the empathy side of it, I think the key to empathy is really to remember that it's really not about telling your story: matching them at every step, it's really about understanding their story.

CHARLES: All right. I really like that and I really like the process that you're building here. There you have it folks. With that, I'm Charles Lowell from The Frontside. I hope you enjoyed this episode. Thank you, Jeffrey. Thank you, Ginger and we will see you all next week.