Customer Mirage: Risks of Signing A Large Company As Your First Customer

Imagine you’re in a hot, dry desert and desperate for water. You’ve been walking all day and the thought of drinking nice, cool water makes you ecstatic. Suddenly, you see it! A pool of water in the distance. You hurry towards it, running as fast as your legs will carry you. But when you arrive, all you find is sand. Damn sand!

You’ve just experienced a mirage. And this is exactly what it feels like when you’re looking for that first customer and close a whale. You’re desperate for validation and revenue. If only you could get that big name-brand customer, investors would be tripping over themselves to give you money! TechCrunch would write about you! The cash would be rolling in and all your worries would be over!

After weeks or more likely, months of emails, calls, negotiation, and nervous waiting, you finally land a deal with a WHALE, a well known publicly traded company. Not just any deal – this deal starts with $100k+ in revenue and has the potential to bring in much, much more. This is the inflection point right? It’s all #winning and *crushing it* from here!

Unfortunately it usually doesn’t work like that. If your first customer is a large company, the deal is more likely to be a mirage than the start of a winning streak.

Why The Likely Outcome Is You Become A Dev Shop For Your Enterprise Customer

Your Product Is Not Ready For Prime Time

There’s that old phrase from Reid Hoffman: “If you are not embarrassed by the first version of your product, you’ve launched too late.” Your early product is going to be a fraction of its true potential, which is fine for early adopter customers. And maybe that’s good enough for a large company but it likely isn’t. The large customer is going to have all sorts of requests – some essential to the functionality of the product, others which are more cosmetic. Assuming you’re a typical lean early stage team, making the changes the enterprise wants can be a hamster wheel: spinning in place just to service this one customer at the cost of future growth.

Large Companies Have Complex Needs and Requirements

If people refer to individual departments within large companies as “fiefdoms”, what does that make the entire company? Every large company is its own country, complete with its own history, regulations, and culture. And I can guarantee that every company has some bizarre (from the outside) bureaucratic rules for new vendors. Companies sometimes waive these requirements for pilot projects but once you start working closely on a scale-up plan, there will be hoops to jump through and changes to be made. These changes might involve custom integrations, new workflows, or other completely unique features that don’t scale beyond this single customer.

The biggest risk here is you spend a ton of time and money developing a product that has a market size of one, the definition of a dev shop. So much for your high-flying startup ambitions.

High Expectations For Service

A company paying $250,000+ for a software product expects to get some service, rightly so. But do you have a service team or protocols in place? If you don’t, you could be in for a rude awakening with a cancellation or a lot of late nights, working through product changes and service tickets. And once again, these changes will probably only be relevant for this single customer, not your wider market.

How To Avoid Becoming An Enterprise Dev Shop

While there are infinite paths to building a company, if you recognize that your company could fall into the enterprise development shop trap, there are two things you can do:

Focus on Small and Medium Size Businesses (SMBs) Initially

Building a product for smaller customers initially may seem like the slower path to revenue. But building your product for a market, rather than an individual customer, is what will lead to growth and scalability later on.

And remember, just because these are SMBs doesn’t mean you can’t interact with them and sell directly. Doing things that don’t scale isn’t just acceptable in the early days, it’s essential.

For example: if you have a product that will be used by specialist doctors, such as an OB/GYN, you can try selling that product to a large hospital system (very difficult) or to an individual practice (much easier). Opting for the individual practice is the better move, even though it has less revenue potential in the long term.

Ruthless Product Road Map Discipline

This is the tougher strategy for the simple reason that human beings are terrible at saying no to money. And this strategy involves telling your large enterprise customer the most dreaded two letter word when they ask for a product change: NO.

What comes after those two words might be a decision not to move beyond a pilot or a complete cancellation. But hopefully the customer is understanding and respects your decision to stick to the product roadmap.

This doesn’t mean you ignore the feedback. But you treat it like you would any product feedback. It goes into your backlog and you make decisions on priority the way you would any other feature request.

Ultimately, this comes down to discipline. Can you avoid the siren call of your large customer’s feature requests and instead, build your product for the entire market? Few can but the risk is clear. Janette Barnard said it better than I can:

Final Thoughts

As anyone who has been around my site or read my book knows, I frequently advocate startups working with large companies. But there is a difference between working with a large company on your terms and working with a large company as a desperate vendor. Avoiding the trap of becoming a one customer dev shop takes clear vision and above all, discipline.

To learn more about how to work with large companies to unlock growth, check out The Startup Gold Mine: How to Tap the Hidden Innovation Agendas of Large Companies to Fund and Grow Your Business.