Everybody is selling something.
For software engineers this can translate to selling products directly to customers on the front lines or selling new product feature ideas internally within an organization. In either case, sales in some form cannot be avoided. As such, software engineers can benefit greatly from observing and avoiding the more impactful and common mistakes other developers have made in the past, and learning what they should have done instead.
When we went through Y-Combinator during the winter of 2014 and were just starting PipelineDB, one of the things that surprised me most about the other founders in our YC batch, who were mostly technical, was their bewilderment at the prospect of selling. Here were some of the most brilliant minds I’d ever met, building things ranging from self driving cars to aerial imagery analytics platforms for agriculture, and the aspect of their startups that seemed to cause them the most anxiety was sales.
And then it occurred to me that it wasn’t because sales is prohibitively complex or difficult that these genius technical minds were baffled by it. It was simply a situation where they didn’t know what they didn’t know. Ambiguity is inherently stressful.
This post aims to help software engineers bridge the gap between conceptualizing valuable software products and winning deals by observing three significant mistakes developers commonly make when approaching sales. We’ll frame these mistakes in a positive light, more as opportunities for progress than as liabilities, focusing on solutions in each instance.
Each of these mistakes is fairly unintuitive, so it’s not surprising that any salesperson, including software engineers, would make any of them.
The biggest mistake I see developers make is assuming that they are building something that people both want and will pay a meaningful amount of money for. Many engineering teams spend a great deal of time and money building products that people either don’t actually want, or want but aren’t willing to pay enough money for, such that the company building the product can establish a feasible business model. Both of these issues can be resolved simply by talking to potential customers before the product is ever built and asking strategic questions, a step which many developers fail to take.
Ironically, the amount of work required to talk to potential customers and prove demand for a potential product is almost exactly the same as the amount of work required to sell an existing product. So, the sales work we’re talking about here has to be done at some point, regardless. One benefit of doing this sales work in advance of building the product is that if you’re right about the extent to which people want what you’re building, you’ll be lining up customers for sales as soon as the product is ready and learning more about what features people need and will pay for in the process. If you’re wrong, you’ll save time and money by not building something people don’t want.
Plus, if you’re a startup looking to raise money and haven’t built the product yet, or are working at a company and looking to win internal support for the development of a new product or feature, there is no better ammunition for pitching investors or internal champions than hard, documented customer demand. This documented customer demand will carry weight only if it demonstrates a propensity, or better yet, a contractual obligation, to pay a meaningful amount of money for whatever you’re building.
Strategically engaging with and selling to potential customers before you build your product is a far superior strategy than building a product and then taking it to customers and trying to sell it, so do yourself a gigantic favor and check your assumptions before you start building and test your hypothesis about both people’s interest and willingness to pay for what you want to build, before you build it. No amount of salesmanship will enable you to make up for building the wrong product.
So how do we accomplish this? Below is a quick overview of the steps required to find and engage potential customers, along with a couple of helpful tools and strategies to help you get the job done.
Clearly articulate your hypothesis about what you’re building. What is the product? Who wants this? Why do they want it? What will they pay for it? How do you know they’ll pay that much? How many potential customers exist? Be as concise as possible with your answers to these questions. The simpler the response, the better. Without a well thought through hypothesis you’ll have nothing to test or measure against.
Create a list of companies (or users) that you think fit your hypothesis in a spreadsheet or simple CRM (customer relationship management) tool like Streak, a lightweight CRM offered as a Gmail plugin. This CRM will be your data management platform for all customer interaction and can be used to organize your target list of companies, monitor your sales progress, document customer conversations and feedback, and ultimately measure your sales results.
The most common way to organize a CRM is by grouping companies you’re targeting by the stage of the conversation that each company is in with you. I’d suggest using (“lead”, “reached out”, “active contact”, “demo/free trial”, “closed/won”, “closed/lost”, and “future interest”) or some close variant, as your stage names. It is imperative to have and use a well organized CRM of some sort, even if it’s just a simple spreadsheet.
Find relevant contacts at each company on your target list and document their names, titles, and contact information in your CRM. You can use LinkedIn's search feature to find employees who work at each company you’re targeting, along with their titles and oftentimes descriptions of their roles. You can also browse the “about us” section of the websites of the companies you’re targeting and conduct basic Google searches to find the names and titles of employees you want to talk to. Try to identify a handful of relevant contacts at each company. Having multiple points of entry for each company increases your chances of successfully setting up a meeting with that company, which should be your goal.
You can use tools like Linkedin’s Sales Navigator Gmail plugin (was called Rapportive) to help you find contact info for the folks on your list. If you don’t connect with the right contact initially, ask the person you do connect with who they would suggest you talk to and if they’d be willing to make a quick email introduction to that person. I’m always surprised at people’s willingness to be helpful when I’m direct, sincere, and respectful of their time. And work your own personal network. The best introductions are warm intros from people you already know, so leverage your network as much as possible.
Reach out to each of the contacts you found. In my experience, the optimal strategy is to write concise and highly personalized outreach emails to each contact explaining who you are, why you’re reaching out, and why they should care. Conclude by asking if they would be open to a brief introductory conversation with you to learn more about your product and how it might help them. The goal is to get them on the phone to discuss your product and test your hypothesis from step one.
Effective selling requires a thoughtful strategy, rigorous effort, and tenacity. There is obviously more to sales than can be articulated in this post alone, but this high-level framework for finding and engaging potential customers is something that software engineers can use to get sales conversations started and generate the type of crucial customer feedback discussed above, before building. Be scrappy and creative in how you find and engage contacts, but make sure that you don’t stop until you have a significant amount of clear feedback that either proves or disproves your hypothesis. And don’t be afraid to iterate on your hypothesis and pivot your product strategy or business model. Iteration is a normal and expected part of a successful product development process, so let go of any attachment you have to what you think people want, and build what they tell you they actually want and will pay for instead.
The second biggest mistake I see developers make in the sales process is entering into sales conversations with potential customers and proceeding to immediately talk about product features and perceived benefits for the customer, without taking advantage of the opportunity to ask strategic, open-ended questions, and then listen intently. The responses that customers give to thoughtful, open-ended questions inform how customers think about their problems, needs, budgets, timeline, decision making process, fears, alternative options to your product, and the extent to which they perceive that your product solves their problem.
When it comes to sales, it does not matter what you think about your product. It only matters what customers think about your product. In order to win customers you must set aside your own thinking and get into the mind of your customer. The best way to do this is by asking good questions, and then listening carefully and taking notes. Open-ended questions like:
are particularly effective sales questions because they offer the sales prospect an opportunity to respond with a large volume of unbiased feedback to each of your questions. The goal is to get sales prospects talking about their thought process so that you can understand their perspective, needs, and motives. Without this information you are essentially flying blind in the sales process and likely inundating sales prospects with information that may or may not be relevant. With this information you can deliver a concise, tactical proposal about how your product would add value for them, or determine that your solution actually isn’t a good fit for them and save both you and the prospect time by disqualifying them and moving on to another sales conversation that is likely a better fit.
Many engineers I've talked to report experiencing social anxiety and a sense of discomfort during sales conversations. This is especially true when it's time to ask sales prospects some of the harder questions surrounding their willingness to pay for your product, budgets, next steps, and getting all of the decision makers on their end involved and taking action. The natural human response to this type of discomfort is to react somehow, oftentimes by talking unnecessarily, which is a tactical mistake. The optimal approach to sales is to ask the kind of strategic, open-ended questions mentioned above, then wait. Listen. Let the silence linger longer than you're comfortable with, so that the sales prospect can consider your question, experience their own emotions, and then respond. Get comfortable being uncomfortable.
Asking good questions is the key to sales. This key can be used to unlock the door to the customer’s thought process. Once the door is open, valuable information can be passed from the customer to you, enabling you to deliver value to the customer. And by delivering value, you will earn revenue.
Software engineers, especially those who are emotionally attached to the value propositions they assume their products’ deliver, have a tendency to mistake interest for demand. If you’re building a product that delivers any incremental value, you’ll likely be able to win the interest of potential users, but that does not mean that you have created enough incremental value for customers to make them willing to pay you a meaningful amount of money for your product. The delta between enthusiasm and willingness to pay is the difference between interest and demand.
What typically happens is that customer prospects will express some level of enthusiasm about a product during a sales call, or even go as far to articulate that they want and would use the product in question. This response from the customer is then interpreted as proof that customers want to buy the product. Software engineers in this situation have a tendency to assume that their sales work is now done and that the only remaining step is to deliver the product and collect their cash. This is incorrect.
More investigation must be conducted to determine whether or not the customer is willing to pay for the product, and if so, how much they are willing to pay. The acronym “BANT” (budget, authority, need, timeline), which was developed by IBM salespeople for qualifying sales leads, is a useful checklist for determining whether not a sales prospect has demonstrated demand for your product. If you can determine that a customer truly:
then you have successfully bridged the gap between interest and demand. Once you have determined that a sales lead has met these criteria, ask them if they’d be willing to sign an agreement to purchase your product at a specific price if it meets a certain set of requirements. The ideal situation for you is to have as many signed, legally binding customer contracts as possible, as early on in the product development process as as possible. You may not be able to get these, but you should try. Even getting customers to sign non-binding “letters of intent” to purchase your product, ideally at a set price, is valuable and can be used to build your case to any relevant parties. You must push customers to agree to as much as possible. Without doing this, you will not have a good sense for the extent to which demand for your product exists.
Don’t fall into the trap of mistaking people’s enthusiasm and language around how much they want and will use your product for real demand that satisfies your business hypothesis. It’s possible to waste an infinite amount of time chasing unqualified leads, or worse, mistaking interest for demand and building the wrong product entirely.
The majority of software products and companies that fail do so because they neglect to perform the kind of thorough customer development work described above. The process of strategically engaging customers and transforming their feedback into valuable software products is the best way to ensure that you build something that delivers enough value to these customers for them to be willing to pay you a meaningful amount of money in return.
This iterative process of talking to customers and building what they need and will pay for is not only an exercise to be conducted before building products, but should also serve as a continuous feedback loop between customers and developers. Don’t deny yourself the opportunity to harvest mission-critical information needed to build game changing software products that support successful business models, simply by neglecting to engage the very people you’re aiming to help.
Talk to your customers, build what they want and will pay for, and iterate relentlessly.