Do SE's need to be rocket scientists ?
SE's are really smart, but are they like rocket scientists ? Over the weekend my YouTube feed delivered a real gem from one of my favorite channels. Many of you may be familiar with the Everyday Astronaut. Tim Dodd and his team create excellent content, and I highly recommend it if you like space information. The video that really got me excited is a recent interview with Elon Musk. Elon has become a bit of a controversial figure, and I’m certainly not a fan of everything he says and does, but this conversation about how he approaches the design process with SpaceX was very interesting.
In Tim's video, he spends quite a bit of time walking through the SpaceX facility in Boca Chica Texas and Elon shares, amongst other things, his engineering approach utilized by the SpaceX team. It got me thinking about how some of these ideas apply to presales work.
Elon outlined 5 steps used in the process of designing and developing their space technology. To aggressively summarize these 5 steps, essentially they are:
Make the requirements less dumb.
Try very hard to delete the part or process.
Simplify and optimize the design.
Accelerate cycle time.
Automate.
Now I have never been part of building a rocket, or an electric car, or a tunnel but these ideas really got my mind thinking about how we approach selling technology.
Let's start at the top. Make the requirements less dumb. Elon essentially described this step this way. The requirements are definitely dumb; it does not matter who gave them to you. He notes that it’s particularly dangerous if someone who is smart gives them the requirements, as one may not question the requirements enough. “Everyone’s wrong. No matter who you are, everyone is wrong some of the time.
Too many times when we start an engagement with a technical prospect, we tend to accept their definition of requirements as gospel right from the start. After all, most of us work with multiple industries, multiple use cases, multiple job functions - so how could we know more than the customer about a requirement ? We almost never know more about a prospect's industry than they do, but we do see a lot of people try to use the products we sell and we have a point of view about how to best evaluate it, how to best apply it to a problem, and what use cases are a good fit. So we have to engage a prospect without arrogance, but with the confidence to really help them think through their requirements and make sure they are evaluating our approach in a meaningful way to choose the right alternative. In addition, it is our job to help make sure these requirements are ultimately able to be tied to business value. At the end of the day, if the requirements are met but business value is not generated - then nobody wins.
One of the great sales leaders I recently worked with liked to use a mission statement for sales teams that says customers want to be heard by an expert who is on their side. SE's are the point of the spear on this mission. We are the experts, we have to listen, and we have to be on the side of the prospect and not just on the side of a transaction. So when we get requirements from a prospect, it is imperative that we take a partnering approach to not simply respond yes or no to a requirement, but to make sure we can talk through solving the core business problem and not just meet the stated requirement. This is a delicate dance for sure, but it is critical. If the technologist can not explain the reason for the requirement, then we need to work together to dig deeper.
The other context that I think this applies to is prospects that set up POC requirements that include capabilities that are not key to determining the right solution to their problem, but are just concerning for them. The example I always use here is LDAP integration for a platform style product. Every technologist knows that LDAP integration is always tricky, painful, and every product has to be able to do it. I have often said to a technical contact that my product will be no better or worse at LDAP than any of your other choices. I can give you references that will tell you that they were able to make it work, but it doesn't make sense to make it a decision criteria. Now, certainly this example is specific to a certain set of products, but the key is to help a prospect focus a POC on the concepts that differentiate their alternatives for solving the business problem. There may be any number of POC requirements that are really just trying to work through issues that will be needed to get to production, but not key concepts that just guide the prospect to the best alternative to solving the business problem.
I will take on the other items in the list in articles over the next couple of weeks. The other key aspect of this process that Elon describes is that the steps must happen in this order, which is really interesting and often done backwards in software sales. So check out the video if you like rockets. Tim is doing additional videos that cover more of his conversation with Elon which looks very exciting.