Recent Posts

Successful Selling For The Technically Gifted: Understanding The Pilot Project

By on October 24, 2006

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?  

Continue Reading

Leaving A Startup: It's Not Me, It's You

By on October 23, 2006

In my first startup I founded, I got really lucky.  Most of the individuals I recruited were both extremely competent and extremely loyal (mostly to me, as the company didn’t have a particularly motivating mission).  As such, our attrition rates were really, really low (particularly for the time, since we were living through the Internet boom years).

But, that was an anomaly.  Now, having been involved with several more startups, I recognize that replicating my first success in hiring is unlikely.  But, I don’t want to write from the perspective of the entrepreneur – but rather, the startup employee that is faced with the difficult decision of needing/wanting to leave.  Often, startup employees are very early in their careers and may not have had to face this issue yet.  Certainly, the relationship of a startup with it’s employees is often much deeper than what it would be in a traditional big company.

Leaving A Startup:  It’s Not Me, It’s You
The title of this article is what it is because I think over half the time, the issues between a startup and it’s employees in the early stages lie with the startup.  Sure, you can have employees that are non-performers, but more often than not, it’s about the startup, and it’s founders.  Let’s face it, there are a lot of dysfunctional startups and founding teams out there.  It’s often hard to detect this early on (and even when you do, you write it off as “eccentricity” and related to the fact that they’re doing some “crazy, innovative things”.  There’s a fine line between crazy and just crazy enough.  But I digress…

Here are some quick thoughts on leaving a startup, should that situation ever arise.
  • When you first start having concerns, the basic question you should ask yourself is:  “Is the problem with this startup – or am I just not suited for the startup adventure at this time?”

  • It is important to remember that just about every early stage startup will experience “near-death” events about once a year.  If it’s a very early stage startup, and bootstrapped, it will likely experience this about once a quarter.  It’s important to separate root problems in the startup vs. growing pains that are typical of any startup.

  • Founders can be an emotional, quirky lot.  When dealing with the loss of a key employee, it can be a particularly charged situation.  My advice would be to stay calm, rational and objective.  If one of the founders is truly way, way off and does not deal with the situation professionally, it will likely just validate your decision.

  • It is important to understand the terms of your contract.  If you didn’t read it when you signed it, you should definitely read it now.  First, get a handle on the equity arrangement.  Do you have options that have vested (or will vest)?  What are the terms for these options?  When do you have to exercise them?  What’s the strike price?  What’s the fair market value of the startup?  What are the tax implications?  A lot of this often applies only if you’ve been with the company for a little while, as many vesting schedules have a “cliff” so that if you leave within the first year, no equity is vested).  Read as much as you can on the this.  Seek competent advisors.

  • Do you have another opportunity in mind already?  If so, make sure it doesn’t violate the terms of any non-competition covenant you might have with your current startup.  Most startup employees (including the founders) sign some sort of non-compete agreement that prevents people from jumping ship and working for a competitor.  The reasons for this are obvious.  Note:  You are not obligated to reveal where you are going or what your plans are (though if you have a good relationship with the team, this will often be brought up).

  • Make absolutely sure you do not “reuse” any of the intellectual property you created during your employment in your next gig.  This will be hard, as you feel a personal attachment to any code you’ve written.  This may not seem like a big deal at the time, but it can become one later.  It’s just not worth it.  Start “fresh”.  Buy a new laptop and migrate only your personal files off the old one supplied by the company.

  • It goes without saying, but I’ll say it anyways.  It’s important to try and leave on the best terms possible (without compromising on the important terms of your deal).  Startup-land is a very small land and chances are the next startup you’ll be going to will somehow know the people at this startup.  Try not to burn any bridges. 

Summary of my points:  Make sure you understand the reasons why the opportunity is not working out.  If it’s a problem you have with startups in general, you’ll likely have the same problems at the next one.  Understand your rights – and obligations based on any legal contracts.  And, keep a level head.  Leaving a company is rarely easy – and leaving a startup can often be like breaking off a personal relationship.
Continue Reading

Recommended For You


Let's Connect

And, you can find me on Google+, Twitter, and Linkedin.

Recent Posts

Chat with GrowthBot

It's a bot to help you with your marketing and grow. You can research your competitors, improve your SEO and a lot more. http:/