As regular readers of OnStartups will know, my first startup was an enterprise software company. We sold high-end solutions for high-end prices, to high-end clients in the financial services industry As part of my role as CEO, I was relatively deeply involved in the sales process for virtually all of the large deals that the company did. So, despite the fact that I’m a technologist and not a sales professional, I learned a few things along the way.
Although many software startups these days are focused on consumer Internet and other sectors of the market, I’m guessing that there are still a fair number of you that are building applications for enterprises. For those of you that are, then the topic of the “pilot project” (or model office or onsite trial or some other term) will likely come up.
For purposes of this article, a pilot project will mean when the client gets to use your software (often installed on their premises) so that they can get a feel for whether it will work for them and whether they want to license it. This seems like a reasonable enough request – particularly given the magnitude of the purchase. But, there are some points to consider when asked to do this.
Understanding The Pilot Project
- High Cost: If you have a complex enterprise software product, getting it working at a customer’s premises is not always easy and often comes at considerable cost. Your largest cost in a software startup is your people – and competent people that can help a client configure your software will likely be one of your scarcest resources. In the very early days, this might be the CEO or CTO (basically, you). If your software were a hosted service, or completely “client-configurable”, this is not as big an issue. But, this is often not the case for enterprise software companies.
- No Purchasing Power: Often the pilot project is either requested (or managed) by a department head or division head or something like that. The person interested in your product is likely somehow directly related to the unit or group that will benefit from it. Unfortunately, this does not necessarily mean they have the authority to make a purchasing decision. Normally, this is not an issue. However, the “pilot project” sometimes simply defers to the actual decision to a later date. Often, it turns out that the answer is “no” for reasons that have nothing to do with what was learned during the pilot/trial period. Basically, these issues could have (and should have) been explored prior to making the investment in a pilot project. Examples include: “We don’t buy from startups”, or “Your product runs on WebSphere and we’re a WebLogic shop”. Or, “We don’t have a budget for this and the next cycle doesn’t begin for another 9 months”. End result: No sale.
- Insufficient Client Resources: As a corollary to #1, most pilot projects require some amount of client commitment to make the project successful. Unfortunately, you can’t really control the resources that the client submits. Often, as a result of #2 (i.e. this is an unapproved project in the first place), harnessing resources is near impossible. So, often what happens is that you spend the time/money to get the product installed and configured. However, the client resources needed to really test and evaluate the software never come together. The pilot period elapses and it is determined by the client that they didn’t really see the value they were expecting End result: No sale.
- The Never-Ending Pilot: Most pilot projects have some defined time period during which both parties agree to work together and evaluate the software. Could be 30-90 days (or even longer, based on complexity). However, as the time period elapses, you may find that the client hasn’t quite gotten around to evaluating yet (likely due to the reasons already described). Now, at this point, your costs are already sunk. As such, there’s really no reason to pull the software out if it’s only going to take a couple of more weeks. There’s generally nothing wrong with this. Most enterprise customers are not going to simply use your software for free and be getting value and simply extending the pilot project. That’s an edge case. But, here’s the real issue; If nothing has changed (no purchase approval, no client resources, etc.) there is little reason to believe that another two weeks is really going to help.
- Software Acceptance Period: Interestingly, even after a successful pilot project, the final agreement with the client will have some sort of “acceptance period”. This is a period of time that is defined in the final license agreement that the client has to determine if the product is “acceptable”. Based on who writes the agreement, this can manifest itself in any number of ways. Often, it’s a different group of people making sure software is “acceptable” than ran the initial pilot. Such is life in the big city.
So, what are my words of advice on this? As I said, I’m not an expert, but I’d advise three things:
- Make sure you understand what you will need to invest in any given pilot project. One of the worst things you can do is to commit to a pilot project and then not have the resources on your end to see it through. In these situations, you are basically spending money to decrease the chances you’ll ever get a deal.
- Try to understand the purchasing process, timeline and parties involved. When possible, try and find the cheapest way to get to the “no” you’ll ultimately get to anyways. (This may sound contrarian, because it is). I’ve seen too software startups die trying to sell to that one big client. Sure, persistence pays often pays off in the long run – but in the short-run, you need to meet payroll.
Biggest piece of advice: Where possible, try and make the acceptance period the pilot project. This basically suggests that you actually close the deal with the client. You do this by reducing client risk by way of the acceptance period (given them enough “outs” should the software not work or do what they need). This is risky too, but much less risky than the pilot project for one simple reason: You have inertia working for you instead of against you. Once an actual contract is signed, things do start to happen. Clients do commit resources and now it is their responsibility to kick you out within the defined time period or the software is considered “accepted”. I can count on the fingers of one hand (with four fingers left over) where we signed a license agreement and had the software not be accepted.
For those of you in the enterprise software business, what are your thoughts? Does any of this resonate? Have you had that nightmare pilot project that never seems to end?