David Cummings on Startups

Custom Work to Win SaaS Deals

Written by

David Cummings

in

, ,

As a follow-up to Balancing Desire for Full Paying Customers with the Need for Discounting, I was asked about doing custom work to win a deal. For example, statements like “I’m very interested in your product but it has to do X before I’d buy it” are common from prospects. For Software-as-a-Service (SaaS), this is even more interesting because SaaS should be a true multi-tenant architecture where everyone uses the same product.

Here are a few thoughts on custom work to win SaaS deals:

  • Never give something without asking for something in return (e.g. sure, we’ll do 5% off our product in exchange for a case study)
  • Always debate if the custom work request is going to be applicable to 80% of the desired customers (e.g. custom work is OK if it really is going to be used by everyone else)
  • When evaluating a custom work request, get a letter of intent that the prospect will buy the product before implementing the new feature (e.g. the prospect has to show some level of commitment before engineering resources are applied)

Custom work and product enhancements often come up in a sales cycle, regardless of product type. The key is to have a gameplan and evaluate it on a case-by-case basis.

What else? What are some other thoughts on custom work to win SaaS deals?

Comments

6 responses to “Custom Work to Win SaaS Deals”

  1. mikeschinkel Avatar
    mikeschinkel

    Good rules to follow.

    Besides what you mentioned I wonder what you think of this strategy to handle custom requirements?Implement a rich and robust API and then have a professional services team that can implement custom using the API? That way the core product isn’t made more complex, and for those with the budget you can get extra revenue from professional services? And as you reach high growth you can create a program for authorized developers and give them the business so that it doesn’t distract when the business starts growing rapidly?

    Reply
    1. David Cummings Avatar
      David Cummings

      I think that’s a great idea. I like the idea of an engineering services team that solves problems for customers strictly using the product API.

      Reply
  2. Evan Davis Avatar
    Evan Davis

    If I only had a dollar for every time I heard “I’ll buy it if you can get it to do X.” Great stuff as always David.

    Evan

    Reply
  3. Josh Austin Avatar
    Josh Austin

    This was/is an important issue for our company. As a startup we don’t really have the resources to do a lot of custom work and still spend as much time building/selling our core product as we need to.

    That doesn’t change the fact that most of our customers still need custom work on top of our products. I ended up solving the problem by partnering with a software consulting firm so when a customer asks for additional features, we pass those along to the other firm.

    I guess that’s almost like having a professional services team 🙂

    Reply
  4. petereilly Avatar
    petereilly

    All good points, but in really large enterprise deals, arguing that the feature is not applicable to the larger market could easily cost you the deal; some customers will see you as inflexible and not wanting their business. I have found that 90% of the time, they are wrong about needing the feature, but telling them that you won’t do it is risky. As a software company of course, you don’t want to have to develop features that are no broadly applicable.

    Here’s an approach I developed in years of selling B2B software which has worked well:

    Estimate the development cost of each feature. Tell the customer if they want this feature(s), this is what it will cost. Most companies balk at this, but I explain that they are paying to accelerate development of the feature(s); If they want to direct my development effort, I need them to pay for this so I can afford to continue to drive other features which will continue to differentiate the product in the marketplace (this is all ultimately good for them because the more companies using my product, the better for all of them). This flies about 80% of the time. For the other 20%, you obviously need to make sure the deal is large enough to absorb the investment; if not, then you walk.

    We agree that my team gets final design approval over features and that the features are going into the core product. If it is indeed completely custom, I tell the customer that they must also pay 20% per year for me to maintain and support the feature. I had very few customers want to go down this path; this gave me much greater leverage in ensuring that the design worked for the market, not just the customer.

    Tell the customer that while they believe these are important features, we will likely learn in a pilot that there are other features that are more important. We agree to postpone any work on the custom features until completing a vanilla pilot of the product, but will reserve the development bandwidth for either the initial features or for new things we discover in pilot. I tell them that by doing this, we can avoid having to to back for more money later in the project.

    In many cases, NONE of the original requirements were developed, we were paid for development that accelerated differentiation and market acceptance of the product and the customer was happy and reference-able.

    Reply
    1. Brian Avatar
      Brian

      great stuff Peter!

      Reply

Leave a reply to Josh Austin Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

More posts