Stuart shares insights from his experience at Basho, where he learned that sales and DevRel operate with different goals and processes.
He introduces key sales frameworks that help reps qualify deals, navigate objections, and structure conversations with customers. By understanding these approaches, DevRel teams can collaborate more effectively, offering valuable insights while staying focused on their own role.
Stuart: Thanks for having me. So yeah, I worked with Matthew at Basho and I stole this from Rex Engine. It's an interesting blog actually that touches on sales and platform evangelism. And I basically tried to do this when I worked with Matthew. I thought a technical evangelist or developer relations person or an advocate or whatever was the same as a pre-sales, technical pre-sales consultant or a sales consultant. And that caused some friction to say the least. And I think what I learned was that obviously pre-sales is something entirely different, and I don't need to tell you about that. But I think what you may find in your organisations is a similar sort of idiotic approach, like the one that I took in trying to put sales or business development from a sales point of view together with developer relations.
So I'm hoping in the next two slides that what I'll do is help you understand at least what your sales guy is trying to do. If you find yourself in a meeting with the salesperson, maybe this will give you a little bit of insight into what the sales guy's thinking during that meeting. And maybe then the friction that you feel on your side of the relationship might be a little easier to deal with.
So this is a framework from an American company that does sales training called Value Selling Associates, and it's really getting a lot of traction. Most technology, sales organisations that I've encountered in the last five years are actually training with these guys. So this is a framework you might see in your own companies. It's pretty simple. It's designed to help a salesperson identify gaps in their understanding of their customer and understanding of the opportunity that they have in their sales pipeline, in their sales forecast. You as DevRel people can probably contribute a lot of information to this template that would really help your salespeople. And I think that would be something really valuable that you could do actually at the same time is not allowing them to confuse you with the pre-sales guy. So what we're looking for here essentially is to understand what the customer's issue is or what the customer's trying to achieve and value selling associates talk about something called a differentiated vision match.
A differentiated vision match is an agreement between a vendor and a customer about what that customer is trying to achieve. And crucially why that vendor's widget is sufficiently differentiated from its competitors that that vendor is the only vendor for that customer's solution. Okay? So if a differentiated vision match is a very important part of sales qualification. And so what a salesperson is trying to do really through the course of a sales campaign is fill in this template, develop a level of understanding that he can hand on heart, swear to his company that he's giving an accurate sales forecast because he fully understands the opportunities in his pipeline. He fully understands the differentiated vision match with each of his prospects. And so there are a number of components of this, understanding the customer's actual problem, having an agreement about what a solution should look like. And then crucially, this bottom left corner, which is often overlooked in sales.
And it might actually be a little bit frustrating for you as well on your side if you're asked by salesperson to get involved with the particular company. It's why is this of value to the potential customer? That's really what that bottom left corner is about. Don't tell me this is about high availability or it's about a wonderful user experience really commercially, why does the customer's business care? How does this either decrease costs or increase sales or both? And then down to the bottom right hand corner, which really you might be able to actually help a lot, I think in a sales cycle in this bottom right hand corner. Firstly, who has the power on the customer side in a particular opportunity? The power to say yes and actually sign a purchase order and do a deal with your company, but also who has the power to say no for whatever reason?
And there are so many reasons that a potential customer might say no that a salesperson won't really get access to. But if you as a developer advocate or engaged with a particular company and salesperson's trying to do a deal, you probably know the religious, let's call it hangups and biases of the different people from a technical point of view at that given company. So you could really, really help with this power, this understanding of where the power lies in a given company. And then finally, and this, I think this is important for you to know, is the final piece of this is a close plan. Do we have an agreed set of steps with specific deadlines against each step that must be achieved in order for the customer to sign a deal? Or if we do A, B and C, if we do A, B and C together with the customer, the customer will give us the purchase order.
At the end of the day, this is an area where your sales reps might try to drag you in. We need to do this bit of integration with our product. We need to develop this widget. We need to improve our API. We need better documentation. We need, we need, we need before the customer will give us a deal. And you may find limited resources in a company you're pulled into that. I think it's fair enough for you to say to your rep, what's the close plan here?
I want to really understand how I fit into it. What are we really trying to achieve? What's the solution look like and what's the customer problem? Because you want to have a good understanding of what you're being asked to help deliver. And it can be really frustrating, I think, as a techie to be asked to do a specific task and not have the context of that task explained.
But your reps should have this and you should be able to ask them for it and contribute to it. So this is the first framework. This is a framework from a UK company called Leadership Development Limited. And they also do really good sales training. And I've used them loads of times and this helps a little bit better understand what's going on inside the sales person's head if you get stuck in a meeting with them and a customer. So the structure is simple. It's listen, you have two ears in one mouth. So listen more than you talk, understand what the customer is trying to say to you.
Secondly ask, which is ask questions to probe a little deeper into what you're hearing from a customer. Confirm, explain to the customer what you think you've just heard.
Skipping a little bit match, say to the customer, Hey, you know that problem you have, we have a solution for that problem. Ask the customer, do you agree I have a solution for your problem? Does it sound like this is a fit? And then close the sale. Okay. And then there's these two awkward steps in the middle. The PO in Lac Mac pre-close is where your sales rep is saying, if we can do A, B, and C, will you give us an order? It's a little test in the sales cycle to see where the customer's head is at.
Are they ready to commit? And o order of importance? Get the customer to say, I've asked you for a hundred things because we really want to boil the ocean here. They never say that really, but they always give you a lot of problems. You get the customer to just say, here are the most important issues that I'd really like you to deal with in this order.
And you hopefully as a vendor will be able to pick off some of the high priority issues during this process. The sales rep is doing really specific things in the beginning L in Ack, the rep is just trying to ask open questions to let the customer talk at that stage. And I should say this could take place over many meetings or one. Okay. See, it's hard for you to know necessarily which meeting he's dragged you into or she has dragged you into sometimes. But in the beginning, listen, and that's about asking open questions and letting customer talk. If you are in a meeting with a sales rep and you jump in during this L phase, you're frustrating the sales rep because that is the period of the sales cycle where the customer should be speaking a ask. That is absolutely where if you're in the meeting, you should help ask the intelligent questions because nothing will get a prospect going.
Nothing will get a prospect to talk than intelligent questions. And sometimes the rep isn't necessarily the right person to ask the intelligent questions during a confirmed phase where a rep is explaining to a customer he thinks the problem is and the solution is and so on. Again, that's time for you to really not say anything.
When the rep especially gets to the pre-close and asks the customer, if we do A, B, and C, will you give us the order? He'll always leave. Or really awkward silence, right? Because you want somebody to speak, right? But it's not the person on the vendor side that needs to speak at that point. That really is there on purpose. And no matter how awkward you feel in a meeting, always think first I would ask, is there a possibility that the rep saying nothing on purpose and they do not want me to contribute here? This is to try to create some tension that causes the customer to speak and give a response.
I think if you understand this sort of process, this is definitely what's going on in every sales rep's head, not always very well articulated. And in a meeting can get really awkward and you can end up maybe doing the wrong thing.
And then you get negative feedback and you think, well, why the hell are you giving, I'm a developer relations guy was even in your bloody meeting, you shouldn't have had me there in the first place. And only way, you haven't given me the full context of what it was that we were there to achieve. So how could I do anything helpful? Okay, so at Basho it wasn't never really that bad. That wasn't good, it was successful, but there were tensions. And I think if we had understood each other's process, each other's roles a little better, then everybody maybe would've had a little bit more enjoyment at work and there would've been less disagreement.