Successful Selling For The Technically Gifted: Understanding The Pilot Project

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

Successful Selling For The Technically Gifted: Understanding The Pilot Project


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
  1. 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.

  1. 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.

  1. 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.

  1. 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.  

  1. 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:
  1. 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.

  1. 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?  


Posted by on Tue, Oct 24, 2006


Another factor I've found in enterprise software pilot projects is how closely the needs of the potential customer are aligned with your vision of where the software needs to go. If you give the customer a pilot that fits their needs exactly, they'll be happy, but it may be difficult to repurpose the work done for that pilot to suite other customers. If you build generic features that are only indirectly applicable to a given pilot, the customer may not be satisfied.

At least in my case, we were writing the software at the same time that we were pitching customers on pilot projects (I'd imagine this is a pretty common situation for startups). So we needed to do a fair bit of custom development to adapt the partially-completed software to the needs of a given pilot project. This meant that:

(1) Picking pilot projects based on what you can learn is important. We picked projects not just based on the enthusiasm of the client/likelihood of a sale, but also whether we felt that implementing the pilot project would tell us something valuable about the market or about the needs of other prospective customers.

(2) We avoided pilot projects where the functionality the customer wanted was too esoteric or domain-specific. By focusing on customers with fairly average requirements, much of the work we did implementing the pilot could be reused for future customers with similar needs.

posted on Tuesday, October 24, 2006 at 1:57 PM by Neilc

Good line of thought regarding "Pilot Projects", especially with respect to the material risks for startups.

Large and medium enterprises know better than to ask say IBM or SAP to undertake a "Pilot Project" on a 100% risk no cost recovery/no profit basis.

Pilot projects are a great way to sink the ship!

posted on Wednesday, October 25, 2006 at 12:39 AM by Sheamus

Following on from Neilc's comments - I agree a big risk with a pilot project is that you can end up implementing a customized, customer specific solution.

This was an experience we had in the early days with a startup I'm involved with - the end result being a lot of the business logic and work flow was hard coded into the product for this one customer, which we had to excruciatingly extract over the next year.


posted on Wednesday, October 25, 2006 at 1:11 PM by

Coming from the consumer web services side, I'm working on a web application for the financial services industry, and shaping the product and pricing model more like a consumer service - free trial, subscription. Hoping to all but bypass IT, and enable the business owners pass along the cost to their customers if they so choose. Early research indicate this should work well, but we'll see. Competitors currently do what you're referencing above which sounds nasty.

posted on Thursday, October 26, 2006 at 1:00 AM by sean malone

This is a good writeup and i can identify with this as a par to four business line is application development.

It will be great if experts providing their advise via this blog can discuss/share/advise the same practice being used services.

I am planning to offer free trials/pilots of our bpo services to gain customer confidence.

offerings are:
Recruitment process outsorucing
Design process outsourcing
Sales lead generation

to name a few...


posted on Thursday, October 26, 2006 at 11:54 AM by Amit Desai

Please review this one:

This is a good writeup and i can identify with this as one of our business line is application development.

It will be great if experts providing their advise via this blog can discuss/share/advise the same practice of pilots / free trials being used in selling services.

I am planning to offer free trials/pilots of our bpo services to gain customer confidence.

offerings are:
Recruitment process outsorucing
Design process outsourcing
Sales lead generation


posted on Thursday, October 26, 2006 at 11:58 AM by Amit Desai

With much experience on the buy side of the fence - and some experience on the sell side - this post does ring true.

One thought - The vendor should try and drive, agree and document pilot requirements and success criteria. This helps:
- set a decision benchmark which avoids the never ending pilot.
- test customer commitment because customer resources, discussions and decisions will be needed to define success criteria. A bonus for the vendor is the window into the customer mindset to assess their preparedness, commitment and to figure out who the decisions makers are.

posted on Thursday, October 26, 2006 at 4:05 PM by Andrew Lavers

In response to the comment above: "Hoping to all but bypass IT..."

Sarbanes-Oxley and privacy regulations have created an enterprise minefield for this approach. In many cases - particularly in financial services, formal, documented reviews of acquired IT products/services are required. Failure to follow these processes will trigger SOX audit flags. Be aware that the business people you deal with may not understand these requirements within their own firms so “bypassing” IT may be getting your business customer in trouble. One of the core issues with pure ASP-type services is revoking/managing entitlements when people leave the company or switch departments. If you bypass IT and do not get effective procedures established this will trigger audit flags.

posted on Thursday, October 26, 2006 at 4:19 PM by Andrew Lavers

Comments have been closed for this article.