1/7/2024 9-minute read

When I meet with new founders, I tell nearly all of them something which really bends their worldview: go sell your product before you’ve written the first line of code. “What??? Isn’t that lying?” As an early stage company, your velocity is so much faster than any enterprise, that no, it is not, because what you are selling will be there before they can implement it.

Most founders are technical. Through some lived experience, they have discovered something that could be improved with their new technology. Engineers are trained, in school and in work experience, to be very precise and accurate. Everything they do depends on it. Horrendous bugs are often getting some minor detail wrong. Miscommunications or mismatched expectations between teams can cause major delays in development. Being up accurate and precise are critical. Unfortunately, this experience really serves them very wrongly when they find themselves suddenly in a sales role.

Sales is very hard work, and it’s usually under appreciated by technical founders. The rise of Product Led Growth (PLG) motions are, in my opinion, a reaction to founders not wanting to have to interact with customers and do the hard work of selling their product. Sales makes them uncomfortable. Just put the product out there, and it’ll sell itself right?

No. It will not. In the enterprise, the sooner you come to grips with the fact that the product does not, and will never, sell itself, the sooner you can start down the path of learning the critical skills required to sell your product.

Sales is about finding and alleviating pain. Somewhere, there is someone with money who has something they want solved. As a startup, the only reason a buyer would be interested in buying from a brand new company with no to few references is because you are solving something that is super painful for them today. If they could easily solve this problem via a relationship with an existing vendor, you can be almost certain they will choose that path. Bringing on a new vendor, especially an unproven one, is always the last resort. All the processes established by enterprises are designed to make this painful. Enterprises want as few vendors as possible, as it makes everything less risky for them.

If you have an idea for a startup, or even a prototype or early shipping version, the things you need to learn aren’t which features they need. Yes, you need that information too, but you should already know this. If you have the expertise required to find this value proposition that’s unsolved in the market, you already know what you need to build in order to solve it. This is why I hate the term Design Partner. Customers aren’t going to tell you what you need to build. You need to know this already. Customers are going to tell you, through the sales process, how important that problem is and what it is worth to them.

Since you already need to know what needs to be built, the information that’s most critical to building the right solution comes from the sales process. Is this problem acute enough that they will pay? How much will they pay? Is it urgent they solve it? Do they need it right now or can it wait a year or two? Is it worth $10,000 or $1,000,000 to them? You probably cannot command $1,000,000 right now, but you can determine whether you will be able to in the future. If you have spent a year of your life building something you cannot sell, there likely will not be enough time left to fix those problems before you run out of money. Your product and your go-to-market are inextricably linked, and you must build both together and in concert with one another.

During the early days of Cribl, we were not actually Cribl. We were building a product called diag.ai. We found a handful of interested prospects in our target market, Design Partners you might call them, and we started building product we thought would solve a critical challenge for them. However, these Design Partners were not customers. They were interested. They had time to meet with us. We would build features for them, get them to use the product. We struggled to go from using to buying. Every prospect seemed like they were a feature away from being a customer. On top of that, we were so busy building we never worked out how we would eventually build the whole part of the customer journey from making them aware of our solution, to selling them, to making them successful after they had bought. Ultimately, the problem we were solving was not acute enough to spur them to action.

This is why I tell founders to sell the product before it exists. If you have a key insight to build a solution to a problem that they cannot acquire easily today through other means, then you can sell a solution that does not yet exist. In most cases, walking in with some design prototypes, a slide deck, and a clear value proposition is enough. You can validate that the value proposition meets their needs. You can validate that they are willing to spend money on it. You can validate that it is urgent enough for them to take action now. A free solution does not require your prospect to put any skin in the game. They do not need to engage with procurement, legal, their bosses, or anything else to meet with you. Charging, even for engaging to co-develop a solution, means they have to put their reputation at stake, and they will be engaged with you throughout the process.

Selling a product that doesn’t exist can take a number of forms. As we’ve established, this makes people very nervous. It should not be deceptive. Enterprises are slow. This isn’t a criticism, it’s just a fact. Most are planning for time horizons 3, 5, 10 years out. Startups can move incredibly fast, and a prototype that can be built in 6 to 12 months is way faster than most enterprises can move, even if they were to solve the problem themselves in house. What level of solution development you need before going to sell the product varies by the difficulty of the problem to be solved. For deep infrastructure software, like a database, you might need two years of development before it can truly be used. This is probably the exception. Most ideas can go from ideation to rough solution in 6 to 12 months.

What engaging in sales processes early does though, is ensure you are truly building the right thing. Having someone paying ensures they are committed to actually getting value out of the solution. The quid pro quo is that they are going to get an exact solution to their challenge by working with the founders to get their exact needs met, and they are going to get a solution at way below market rate.

As we pivoted to Cribl, we knew we were on to something when we announced on LinkedIn what we were planning to build and we started getting prospects in our network reaching out telling us they wanted to buy it. From day one, the problem we were solving was so acute that it was clear there would be buyer interest. As a result, while for diag.ai I had spent more than a year coding, for Cribl, only one of the co-founders had time to materially contribute to the code base. We were so busy even from early days building go to market materials, slide decks, demos, online sandboxes, supporting beta users, that we didn’t have any time to create the solution itself. We went from first commit to first sale in less than six months, and we had users running the software within weeks of announcing it. It was clear from day one when we had the right value proposition figured out that we would be able to sell our software.

Our first sale was an unlimited license for $5,000. We didn’t know how to charge for it. It barely worked. If you’re not embarrassed by what you first ship, you shipped too late. From that time on, and I’ll write more about this in a future post, it was about figuring out what we could charge for it and how. We kept testing the upper limits of what the software could be sold for, and within the first year we had sold a $450,000 deal.

Working so closely with buyers allowed us to hone our messaging and positioning. We originally thought security and privacy would be the most common use cases, in particular redacting sensitive information in logs. It’s still a use case, but it turned out routing to multiple destinations and controlling data growth were the most important problems for our customers. In the first six to twelve months of selling the software, our view on the value proposition crystallized, and it’s still largely the same to this date for our Stream product.

We continued to sell in advance of product delivery for a number of years. When customers would need a particular feature, we’d be straight forward but commit to them that we’d have it by the time they deployed. In the first couple of years of development, we regularly shipped features within a couple of months from first gathering requirements, and we were able to complete meaningful commercial transactions with simple verbal guarantees we could solve the problem for that customer. As we’ve matured, and sales got further from the founders, we do this significantly less often. It is rare today that we have a need to ship a feature in a short time frame as our product is mature and the use cases are well addressed by existing functionality.

If you were to come from a company like Cribl and start your own, you’d see the world as we see it now. There’s little reason to commit to things that don’t exist. You should go to a customer with a fully baked solution. But, in the early days, this is critical, and it’s counter intuitive. Selling vaporware seems risky, and it is, but startups are inherently about taking on risk to change the market.

If you’re starting a new company, start selling immediately. If you can’t create a pithy message which gets them interested, work through the sales process to prove value, and complete transactions reliably for actual dollars, it does not matter what you have built. Working on your go-to-market motion early will impact in inextricable ways the product you are building. As a co-founder and CEO, your first priority is to ensure the company doesn’t run out of money, and priority number two is to be the head of go-to-market. Start now.

Summarized Content