Editor’s Note: Each week Maynard Webb, former CEO of LiveOps and the former COO of eBay, will offer candid, practical, and sometimes surprising advice to entrepreneurs and founders. To submit a question, write to Webb at email@example.com.
Q. We’d love to have a marquee name as a customer. How do we become “enterprise ready”?
-CTO and Founder of an early stage technology company
Don’t expect this to be a short process. Early stage companies typically don’t target big enterprises immediately. And you don’t need to. Most companies don’t start with $50 million deals when they are small, they evolve to be able to serve big companies.
Understand that this is an amazing opportunity that can be transformational for your company, but it comes with complexity. And it’s slow going.
It’s great if a big company is interested in your product or service, but they may well still likely dip a toe in the water first. Most often you will start out with a proof of concept and then pilot and work together to ensure you are enterprise ready. A big company like Walmart or Fidelity will work with small companies, but they will start in a small division rather than deploy your technology throughout the whole enterprise until they know that the parade of horribles that could happen won’t happen.
In order to address the specifics of how to become ready to serve a big enterprise, we talked to Jeremy King, who was willing to offer his advice even while he was transitioning from being the chief technology officer of Walmart to starting his new position as head of engineering at Pinterest. (Congrats, Jeremy!) We collaborated on this to-do list.
Think about what it will take to become “enterprise ready.” This is a daunting task. What the customer thinks is enterprise ready and what you think is enterprise ready is different. Anticipate the few questions that the enterprise will eventually ask. “You don’t necessarily have to be enterprise ready, you should just understand and be honest with what your limitations are,” says Jeremy. “I’m often saying ‘this looks good, what happens when we roll it out to 4000 stores, or to 1,000 or 100,000 users?’ You’d be surprised how often I get head scratching.”
Put yourself in their shoes. Like small companies, big companies have troubles too. One of the problems is proliferation of solutions. Most large companies have 10 reporting systems, 5 learning management systems, Slack/Jabber/messenger/email. If you are a department-level solution, do what all the sales books suggest, and find a business champion and have them fight the IT fight. If you are a technical solution, find a technical champion (they are there in every company).
Don’t think you can rely on PR, but if you delight people you can get references. Most large companies don’t want their name thrown around by a bunch of startups, in fact most prohibit public PR and logo sharing. If you are in it for that, it’s time to think of a new strategy. Most large companies will discuss you externally in small groups and CTOs often pick up the phone and ask, “What do you think of x company” or “What have you seen that solves this problem?” Note: Most CIOs/CTOs have a tight network.
Get endorsements from technology leaders that CIOs admire and respect. Jeremy says that he’s often critical of endorsements of the consulting companies because their skillset varies so widely, and often they recommend the most generic solution. However, depending on your product area, this can be a good way to introduce your product to several companies if you can find the right experts in the firm. It is fair argument that most of the mid/large IT organizations use these endorsements heavily so it’s hard to ignore. And, when many CTOs meet these analysts, they ask who they see as up and coming.
Let tech drive the meetings. As Jeremy says, “I always tell sales teams that if the sales team shows up then they better not talk too much.” Know your audience, most tech teams want to get a 3-minute overview and get into the architecture/examples. Less PowerPoint, more code, more demos.
Build trust by doubling down on responsiveness. Don’t bite off too many Proof of Concepts at first; instead focus on being responsive. Jeremy says that as a CTO he’s done several deals with companies based on the fact that he trusted them more to be there when there was a problem. That’s because there are always going to be problems—the onus is on you to prove that you have the systems and processes and experience to fix them fast.
Show you can scale. Obviously, you should do some scale tests on your systems. Add a billion records or 100,000 users and see where it breaks. Again, it’s okay to know where your limitations are. We’ve both experienced what happened when a startup gets tied up with a large demanding customer and their “requirements” take you off of your own roadmap for a while. Instead, remember that it’s more important to stick to your vision and bring them along. You are likely trying to solve the problem in a different way than they are.
Be prepared for regulatory approvals. If you are in this space where you are touching sensitive data, then you already know you are going to have to deal with this. The Proof of Concept approach with a staging environment or test data is a good approach; then get ready to go through the gauntlet—there’s no getting around it.
Are you willing to make the long-term investment to take it from pilot to PoC to full enterprise? Remember this takes time and effort and you might do better selling to mid-market and scaling faster with people who have fewer demands.
However, if you are successful in establishing a beachhead in the Enterprise, you will definitely set yourself up for durable growth!