Jonathan Schwartz from Sun has a good post about the nature of developers, and why building a relationship with them is key to creating opportunities.
One of the smartest software execs I’ve worked with had a saying, Developers don’t buy things, they join things." That’s been a pretty focusing statement for us over the years, and as we enter the new year, you should expect 2005 to be one in which we place an ever heightening focus on our dialog with the community, and the developer community in particular. And not simply maintaining the dialog we have today, but finding new constituencies, and expanding our reach. Establishing a relationship with a developer is all about starting a conversation – one that always flowers. And often into opportunity.
I totally agree with Jonathan on this. The key, however, for any small company is to do this economically and efficiently. Let me give you an example. Let’s face it-many companies selling into enterprises end up going through some "pilot" or "beta" period where a sales prospect’s developers and technologists get to use the software and deploy it on a trial basis. When I look at a sales pipeline, I always want to know who in the organization the company is selling into and why. You see, I have more often than not seen a number of early stage companies selling into enterprises but not selling high enough to the people with budget. In other words, the vendor ends up getting excited about the number of pilots in the market, many of which are with technologists who by nature like to try things and rarely end up buying. The vendor spends an inordinate amount of time reaching out to the developer or technologist to set up a pilot and then leaves with no defined criteria on when the pilot ends and how it automatically converts into a sale. The developer uses the product, sucks up lots of our resources, and moves on to the next new technology. While it is imporant to court developers and technologists in the sales process since they typically have to give the technical buy-off and can just as easily squash an opportunity, it is not a great and economical use of time to have your most expensive direct sales resources and sales engineers doing this.
Enter the web and the open source movement. Sure, "try before you buy" works if your users can download the software for free either on a trial basis, say 90 days, or if you open source a version of your product and build a real community. One of my portfolio companies is laying the foundation and groundwork to open source some of its software to help build a community and buzz around its product. We know that developers and technologists are key to the sales process. We want developers and techies to download and use the product and bang on it. However, we just want to reach them in an easier, more efficient way. Why have our most expensive sales resources do this when we can leverage the web? We want to build community around the product, gather great feedback, and land and expand our relationship with the developer. We hope this open source strategy will work as we build a relationship with the developers who ultimately will drive decision making from the bottom-up while our expensive sales reps can reach the execs with budget from the top-down. Hopefully, the two ends will meet in a selling process with less friction. We shall see. I will keep you posted as this experiment evolves.
This is a great post, Ed, and it hits on a bunch of different points. I think there is also one other “hidden” benefit of leveraging open-source for products that generally require significant pilot/trial phases. Anybody who’s been through this process as a vendor will be familiar with the “we like it but we would need it to do XYZ, so we need to spec out that project with your professional services team before we go any farther”. The beauty of open source is that this bottleneck can be reduced or even removed in some cases. Customers can experiment with extending the code base in their own branch, and if they don’t go that far, it still becomes easier for the technologists within a customer’s organization to kick the tires and get a real feeling for what it takes to extend the capabilities of the software. This can actually be quite helpful for larger price tag deals, as you then leverage this DIY model to reduce the likelihood that lower margin services work is negotiated in a bundle with license pricing. Obviously, it’s idealistic to assume that opening your codebase gets you out of these situations altogether, but it’s a potential benefit that comes “for free” alongside those you also mention.
Interesting post. What I think becomes a bit of a craft, is determining when to ramp up the expensive sales reps. From my perspective, there is probably a minimum number for each company just to get in the game (or you have to use execs that are renaissance sales guys that can sell up and down the chain until you have a grass-roots community ; you can also use these renaissance guys to figure out the optimal product form too in the early phases of the learning curve).
couldn’t resist commenting on your post… the trial trap is deadly…spot on there.. open source is good for getting a cheap distribution of code and overall feel for a solution, its deployment, and resource forecast/cost. That’s all great but turning that quickly into qualification is the art of selling and as you point out call high is key to understanding if the opportunity has ‘legs’. Then asking for dollar commitment ussually will flesh out the tire kickers and real customers.
Great post and topic! Working with people that are capable of purchasing could never be understated. One problem with this though is that many people with great titles will never admit they don’t have the authority to purchase. Continuously qualifying the purchase process is critical to sales success.
A problem I find with many early stage companies is that they have great technology, ideas, and solutions however, they often don’t fully know how to articulate their value, use, and benefits to business people. They often gravitate to “techies” because that is who they are most comfortable working with.
If positioned with a decision-maker correctly, any beta/trial is reduced to a mere validation of the benefits you offer. Selling your solution before you trial is key to maximizing your revenue in an opportunity and minimizing your exposure in a lab.
Two of the best questions you can ask a sales person are – 1) “What are the steps necessary to complete this sale?” and 2) “How do we advance this opportunity to the next step?”
Each time the first question is asked, the check-point is “If we do this, then that will happen?” If a sale can’t be mapped, it can’t be qualified and ultimately closed.
The second question is to assure your sales times is being spent on advancing the opportunity. How ever unique a market may be, all sales within that market follow a process…focusing on moving an opportunity along its path is paramount to closing the deal and intimately recognizing revenue.
A problem I find with many early stage companies is that they have great technology, ideas, and solutions however, they often don’t fully know how to articulate their value, use, and benefits to business people. They often gravitate to “techies” because that is who they are most comfortable working with