December 29, 2015
Ep. #10, Programming Languages
In this episode of To Be Continuous, Paul and Edith talk about programming languages and why they continue to evolve.
Thanks so much for coming tonight to listen to me speak. I appreciate it. I wasn't at Engine Yard for 10 years. I'm not that old. I was there for five, but I have been in startups for quite a bit of time.
I think I was trying to count for this talk. I was there 24 years in startups, so I've done about 11 startups. I've had a number of different exits, some good, some not so good, but right now, I am running Sales and Business Development in channels at Qubole.
The way to say the company's name is "Qubole." Because nobody can say it, they call it "Qu-bole-ee," "Quebble."
I wanted to talk to you tonight a little bit about early-stage sales, how to address the new market, when to build a sales team, how to build a channel, or when to build a channel if you build a channel.
I'm happy to take you through some of the lessons that we learned, not only at Engine Yard, but at Netscape and at Qubole. When I joined Qubole, we had great pipeline of over 100 prospects. They've been there about 15 months, and when I got there, I was handed a prospect line and told to go close a bunch of customers.
What I saw was most of them were totally unqualified and were not going to close. What we were doing is we were going out to see our customers, and we were just presenting with proposals.
We would go and do a presentation and give a proposal, put them on a pipeline and say, "Okay, they're going to close." But most of our early customers, the 20 that we had when I joined were brought to us by tapping our board and tapping our founders, which is usually what happens when you're focused on enterprise sales.
The company itself thought they were going to sell big data as a service over the internet with a credit card. That didn't happen. People didn't buy our product that way. And so, when I came in, I took a look at the deals that we had closed and looked at the proposals, and I started to build some structure around what we had built.
The first thing we did was we went out to learn a bunch of new things. I think before you act, you have to understand the environment that you're in.
The first thing we did was, I got lucky enough because I'm pretty connected in the Valley, and called a bunch of people who I knew to ask customers who did not buy if they would talk to me. And they did.
What I heard was interesting. I heard that we were running after deals that we didn't have a good product fit for. One of the prospects said to me, "I am not your customer." And that was the most valuable thing that I could ever do, because he told me who my customer was by elimination.
He said, "I don't have a cloud environment. I don't have a lot of data, and I have a unicorn, a Hadoop engineer. I only run Hadoop once a day."
So, for us that was not a good target. We started to look at how we could target and look for a repeatable problem that we could solve with the technology that we had and we came up with five qualifying questions.
Let me talk a little bit about using qualification, because qualification, I think, is the heart of sales.
If you can build a qualification methodology that's simple and easy to remember, and you can flip it on its head to have it as your value proposition, I think you can start to expand your business very rapidly.
And so, what we did was we said, "What is the battlefield that we actually play on, and how can we beat our competitors?"
When I joined Qubole, I was stunned by how competitive the environment was. We were mushed together with a whole bunch of different technologies in the press, and we actually didn't compete against many of them. Many of them were in our ecosystem, but they weren't a direct competitor to us. But we didn't even know that.
When we came in, we wanted to figure out who our customer was by process of elimination. I get this all the time. People call me up, and they're like, "Hey, I'd like you to come to my startup, and I'd like you to just close 10 customers." I'm like, "Okay..."
When you talk about the flags, the red flags of companies I won't work with, it's like, "Just close 10 customers." Doesn't make any sense. And the reason it doesn't make any sense is that it assumes that you know all of these things. It assumes that you built a flywheel.
You know who your customer is. You know what your message is. You know what you're value proposition is. You have the messaging done, and you can talk to a customer about why they should buy your product. Most times, none of those things are there.
So, early-stage sales, when you first get in, regardless of how big the team is, even at Engine Yard we had a team of five when I joined, and we were selling managed services. We had a data center. We weren't selling cloud, and we came in, and we were selling inside sales with a bunch of outside salespeople. And that just didn't seem right.
We were closing deals over the phone, but I was paying very expensive talent to go out and close these deals.
What you need to do is figure out how to experiment to build a sales process.
What we did is we went out and we said, "How do I build a flywheel? Who's in the process?" One of the things I tell my team is, if you're selling to one person, you're going to lose.
I only know this because I went out personally, and I closed two or three deals in the first quarter that I was there, because I wanted to know what it took. Who did I sell to? What resonated? Who was the competition in the deal? What was the price points? What was the messaging, and how did I get the customer to agree to buy? And how long did it take?
You've got to assume that you can cut that process down over time, so basically, you want to measure everything. And that's the biggest thing I did. I sat down and built a pipeline. I looked at the current pipeline of 100 deals, cut them all out, created a qualification process, and then measured every step along the way before I hired the first sales guy.
The first sales guy that I hired came out of the BI space. I got really lucky with him, because he was a pro. And what he did, which was interesting, is that he looked at our current customer base, and he started to segment it by verticals and see where we were getting the most traction. For us, it was ad tech.
We identified all the ecosystem influencers in a sale and then we tried to repeat it.
If I were to build a sales flywheel, or tell you to build a sales flywheel, it's to know how your customers buy.
You measure everything. You build a sales framework, but you don't have to be married to it.
When I first built a framework, I said, "Okay, we're going to have four steps, and it's going to be generate interest. It's going to be technical review. We're going to do proof of concept, and then we're going to close."
The guys came back to me, and they're like, "It doesn't work that way, Marce." Basically, the proof of concept takes a lot longer.Basically, we need to go and the technical review has to go to two or three different divisions. We have a legal, and we have security that have to be in there.
So we created a longer process. We created a longer framework from that. It was all about experimentation. And then what we did was look for repeatable patterns. What I told my team was, we basically needed to test for the target customer.
We thought initially, "Okay, we're going to go after the mid-market." We thought that's where we're going to go, and we're going to do all our messaging to mid-market, but really what we found was by building a targeted qualification process, and ours was called COMSA.
So it was, "Do you have a cloud? Are you willing to put your data in an object store?" Because a lot of people will buy a cloud that they'll test. "Do you have massive amounts of data? Is it structured and unstructured? Do you have a need for ad hoc querying?"
If you answer yes to three of those, I'll engage. If it's no to the first three, we walk away. We say it's not a deal. It's not for us. We're not going to engage.
What it does for my competitors is, it boxes them out. I've built a playing field that says, "I am a cloud environment. I'm going to get people who want to play in this environment, and I have a product that was built from the cloud up."
We turn that on its head, and that became our value proposition.
What I did was, I go in COMSA, all my guys were like, "COMSA, COMSA, COMSA." That is our qualification mechanism to find a customer. Then we know if we get them in a proof of concept, our product is so good that, basically, we're going to win it.
The issue that we have is the value proposition is the opposite of COMSA. The value of what we do is we offer ad hoc query for massive amounts of data, that are structured and unstructured, that allow you to distribute it across the cloud with all the value elasticity of using the cloud. So, make it very easy for people to remember and to go to market with.
Most of us went into sales because we couldn't do math. So basically, what we did by building this defensible battlefield is that we positioned our competition outside the battlefield. We did it both at Engine Yard and we did it at Qubole.
When you engage with the customer, and you've got a target that's so narrowly defined, you can win. Because other people have to come into your battlefield to fight you.
Is your battlefield big enough for you to compete? Is it going to grow? And my bad, after being at Engine Yard for five years and watching Amazon just kill the market, was say, "Yeah, everybody's going to put their data in the cloud, and so this is a battlefield that's going to get bigger and bigger and bigger."
I think our competitors, at least the ones that have raised lots of money, were building things on PRAM, which I wasn't competing against, because it's just not something I can win.
What we want is repeatable model. We've grown 350% in a year, and one of the reasons we did is we were really targeted in our message. We were really targeted in our customers. We know how to win.
I mostly spend my time now hiring and training. I go out and talk to customers. I'll be on the road tomorrow, but I spend a lot of time hiring new people, getting them in, teaching them the process, getting them through, and then building out, finding more customers and getting more wins.
I also got lucky when I first talked to our customers. My first customer I met was in New York, and he was talking about the product, and he was saying his experience with the product. He looked at me and said, "I used the product, and I found the new love of my life." And I was like, "Okay, I went to the right place. This is awesome."
The products determine what markets you can go to, and sales can only sell in front of products for so long.
I have been in companies where the product wasn't working or it wasn't built. I've had to go out and help the company build the product by getting in front of the products, by going to a customer saying, "Do you have this problem? And if you have this problem, we're looking at solving it this way. Would you be interested in working with us in a beta position?" Convincing them to come into the process with us.
You have to be really careful about that, because if you are building a sales team that's very monetary-focused, what you don't want to do is have them go running at a big deal, bring it in and crush the company.
You have to be circumspect about who you engage with and when you engage that. Establish a proof of concept, highlight your value propositon.
This is interesting. Our proof of concept is two weeks. Nobody does big data in two weeks. That establishes our value. I tell people I can run. I can roll out 400 notes in four minutes. So, if you want to test our product, we test it in two weeks.
My competitors are telling you it's six months, and so what happens there is I engage the value.
I present the value of my company by the way I engage the sales model.
You should think about the products that you're building, and if you're building a model that takes sales effort and takes salespeople, inside or outside, you should think about the value of what you have and see if you can present it in a way that highlights that value.
That's what we did at Qubole, and that's kind of why we're in the position we are, and we're growing quickly.
Also qualify out your competition. Somebody in this audience told me they thought they were competitors. I don't consider them competitors, because I target one competitor at a time. Because I can't fight everybody. And when I got to Qubole, I didn't even know who my competitors were.
You know, we are lucky at Engine Yard. We had one competitor which was Heroku. We had some DIY, but it was mostly Heroku. So we could all target against each other and go after our market.
In this market itself I looked for the guys that couldn't get into the cloud and couldn't get into the cloud easy. And so I could win there, and I could replace their stuff.
I have two types of sales. One that's a replacement sale that's really easy for me to forecast, because the way we sell is a usage-based model. So you put your credit card in, or you ask us to bill you.
We charge you cents per hour, so you pay for when you push buttons. So I want my customers to push buttons. I want them to make queries.
We targeted where they couldn't win to get a groundswell of customers. So I have a competitive replacement, but I also have new applications, and those are really interesting. Those are people who are taking data, and they're building it into their products, and they're going to market with our product as part of that.
That's really interesting. I can't forecast it, though. You asked me what my biggest problem right now is, like, how do I forecast that business? I don't know how to tell you if those products are going to get picked up in the market and if people are going to push their buttons.
We've offered some value in data sharing so our customers are now presenting our products to their customers, and I can't forecast that either, so that's another problem to solve. But the qualification is really important.
We had a company called Brightware, I think, and they used to go in and say, "Automate everything. Automate all the email, every email you're getting, you want to automate."
We didn't have an automation engine, so we would go and say, "You know, our competitors will tell you to automate everything, but we think that's braindead. And here's why, because you want to know what your customers are saying to you, and then you want to figure out the things that they're saying that's valuable and take those out and automate the ones that aren't."
Well, we didn't have an automation engine, so we weren't going to win with that. What I did was I basically planted a landmine and said, "It's braindead to do that." So when my competitor would go in a room and say, "Automate it," I use their words and it looks like a sales cycle to the customer.
So we went out and dropped bombs. We learned what our customers were telling us, the questions they were asking about.The different objections they were giving us to our product were really telling us about the competitors and what the competitors were saying about us.
Once I figured that out, I knew I could figure out what my entry point is. So, if someone is saying "black box" or an "open-source sky," "Who cares about open-source?"
I don't sell to developers right now. I sell to VPs. They care about bringing new products to market. Developers care about open source, so where am I going to go? It's very interesting. You need to be very thoughtful about your market entry, and the qualification of this allows you to do that.
When you set up, you want to make sure that you set up your competitors in a way that's a little unfair, but in a way that's smart.
Use your sales model as a way to disrupt your competition if you can.
I see a lot of people who are doing lean, agile sales models where people can try your product. The big difference from when I started in sales, years ago, and today, is that my customers, by the time I talk to them, they're 40% down the path. They've been on our site. They know who I am. They know what the product does. They've looked at the competitors.
They've probably done a trial, and so, by the time they engage with me, it's about, "Do I trust you? Does you products do what you say it's going to do? Can I test it? How easy are you to work with?" All of those things are part of the qualification process that they use for you. So we figure out a repeatable process.
Now, what do you do? I think that there are specific skills that a salesperson has that you need to have. You have to be good on your feet. You have to present. You don't have to like people, but you have to be able to talk to them.
You have to generate interest for your product. You have to be able to determine whether or not somebody has a real need, and you have to qualify and talk about features, advantages and benefits, or pass it to a sales associate or a solutions architect to do that.
But also negotiate and close. In the early stages, you also need other things that very much align like a product manager. You have to have really good pattern recognition. So when you see a product, and you see a new opportunity that you can come back and bring that to the company, or a new way to sell, create an environment where people share, and they're really transparent about what they do is super important.
You have to be experimental. I think the one thing about this, that I love about my job, is I experiment all the time.
I'm experimenting right now. I'm experimenting with inside sales, and I have a couple of people that I want to see if I can sell over the phone. I'm not sure we can. We're going to try.
You want to be experimental about how you go to market, what channels you use. Can you work with people who are competitors, and can you position yourself in the market better?
Getting feedback to engineering is really important, that means you have to build trust with them. You have to understand that what you do might be magic in their eyes, and what they do is magic in your eyes. But there's a process involved, and you can't box a company into a corner.
You have to be very creative about closing. At a deal, while I was in India a couple of weeks ago, I fall all over the table. We got really creative about how we could get the thing done, and what I found in the process was, we probably weren't talking to as many people in the company that we needed to, but we went to a partner, and they helped us out. We got the thing closed.
Getting creative around closing is something that you have to get involved in.
Now, I have a group of really senior guys working on the outside for me. I'm probably not going to have to hire the same caliber of people in the next stage of the company because we have a repeatable process. We have a lot of customers. We've got a great word-of-mouth, and we've got a super product.
So now I just have to take that flywheel and make it work. If I can do it in the lowest cost possible, I will. But getting to that point, I needed to do a lot of pattern recognition, a lot of experimentation.
Okay, round channels. You probably hate this answer, but it really is an "it depends" answer to "When do you use a channel?" At Engine Yard, when we decided to use inside sales, we brought in a bunch of non-technical people who were calling people up asking if they wanted to use Ruby on Rails, which doesn't make any sense at all, and it became really clear that our customers were developers. They hate salespeople. Hiring a bunch of salespeople to sell to developers didn't make any sense.
Let's hire developers, or let's hire some geeks. And we did, and we call them "Play Agents of Non-Destructive Assimilation," or PANDAs. It was an entry point in the company. You had to help our customers buy, not sell them.
You had to help our customers buy before you could go into other areas of the company, and we ended up with this great group of PANDAs, these young kids who had computer science degrees at great schools, who came in and basically worked with our customers to start using our product.
I wouldn't do that at Qubole. I don't need to do that. It wouldn't build that same structure, but direct-sales people are warranted when the product is sold to more than one person per acceptance. If they only need one person, I can do this over the web. If it's a repeatable thing, I can do it inside sales.
If your messaging is really complex, we have to sell the two or three people understanding what Qubole does: SaaS application, it's in the big-data space on the cloud; it's pretty complex technology, but it's a really easy simple product to use.
Then when you need to do some evangelisms, you don't really need direct salespeople, if everybody knows what big data is and everybody knows what the cloud is, you need someone to go after and start telling the market.
The last thing is you need it when the competition is high, because if the competition is really high, and you're going into a disruptive market, you should have somebody who can tell you very creative solutions on how to do that.
Channels work when you have a repeatable process.
I started really early in channels at Qubole because I was taking a lesson I had at Engine Yard, which was the Ruby devs, the guys who are running the communities for Ruby and for PHB, were basically the guys who were starting systems integrations companies, and they were the ones who could bring us into larger deals.
We started a systems integration program. We also built an ecosystem. We started to do that in Qubole because I needed breadth. I needed people to be able to say our name. I needed people to talk about what we had, and I knew there was an ecosystem of services around our product that you could build.
When you need an aggregation engine like we did at Engine Yard, I couldn't go out and find where the Ruby projects were. But I could find the pivotals, the other companies that were out there, and work with them.
Then when you want to expand your reach and your market, you want to get into a new market you're not in. You can get other partners to bring you into those markets.
The last one is, obviously, when you open a new market. I think that's sort of the lessons learned. There's an exception for all of these rules, and so I wouldn't take this as The Bible. I would say this is a framework you can work off of.
Sometimes you want to do channels earlier. Sometimes you want to have a channels-only model, because what you offer is an API that connects to all kinds of systems. It just depends on what your product is good at and what you can claim as a victory.
When I look at this, I think the one thing I never do is build in front of myself. That means I don't come in and say, "I need seven sales guys, and I'm going to go hire them. Let's get them out on the street. Let's see how many fail. Let's see how many win, and then let's build another seven."
Usually in any company I've been in, I go out and I get involved in the sales process and understand what it is and try to understand what the repeatable patterns are before I build. It really is hard to do, because you've been doing a lot of things, and you're juggling a lot of balls because you're not building a big organization to help you do these things. Especially if you come from a big organization, and you go to a smaller one, what ends up happening is that you really drop some balls, and so you have to focus on the A's.
I never work on B's. I have an A-B priority, and B's just don't get done until I've done the A's.
I tell people that I'm not there yet. I'm not focused on that at this point. When I get there, I'll tell you, when it becomes a problem, I'll focus on it. That focus allows you to stretch yourself a little bit, but when it gets to be a problem, you've got to build. But you build behind yourself.
I think experimenting constantly, I mean, it sounds stupid, but being experimental, it is part of Qubole's culture. This is what we do. We do it with engineers. We do it with product. We do it with partnerships, and we do it with salespeople.
We're like,"Let's try this experiment. Let's hire this guy for a couple of months and see if it works." Because if we can recognize something that works, and we can experiment on it, we can always move back.
We're very agile. Technical sales is really hard because you have to hire technical people to sell, and technical people don't like to sell, normally. So you have to condense your messages to an audience that can sell or to piece parts of the sales process and get them smarter over time.
Have a COMSA, condense the messages to soundbites, repeat.
I learned this a couple of years ago, that I have to say things three times for anybody to actually hear me, I thought it was just with my kids, but in an organization, I say it three times, and then they're like, "Oh yeah, I didn't think about that." And then when I hear my words coming out of my customers' mouth, I know I won.
When I hear my words coming out of the other parts of the organization or my sales guys, I tell them, don't try to win a battle.
Just try to get your words to come out of other peoples' mouths. When you hear your words back at you, you know you won.
And then building a sales model, it's really easy to understand and learn. It's a really hard thing to do. It's like building a product that's easy to use on the web. You know how hard that is. It's super hard. So building a sales model that's easy to learn and is repeatable is really hard as well.
I'm a believer in building a battlefield and picking an enemy. I can judge myself against how I'm winning in them. If you're in a new market, I think that's very hard to do. So this is not applicable for that, but when you're in a market that's really crowded and really competitive, you pick one.
You can't pick six, or you're going to die. So you pick one. You figure out how they're positioning themselves. Hopefully, you pick a big enough enemy where people notice. You start to win, you start to repeat that, and you claim that victory. You go repeat that victory to everybody, and people start to believe their own words.
One of the things that I did here, because our product is not complex itself, but the space is a little new, people are building data platforms, I found salespeople that had a technical degree, that had moved from one area so they could understand.
You could do an architectural drawing, and they wouldn't look at you like, "What's a database?" They knew where things fit, they knew when you talked about a distribution, what that was.
I think you might want to test for some specific knowledge around how far they could take a sales approach.
Like, what's your price point of your product? Okay, so it's decent. So it's worth a sales cycle. It's not like, "I'm going to put my credit card in." Do you know what your sales cycle is? How long it takes you to close? One month is fast. If you can do it in one month, that's great beause you could close a lot of business in 12 months.
My advice would be to experiment. How many salespeople do you have now? And what are their backgrounds?
One of the things about platforms or technical platforms that's tough is you do need technical people to sell it. It depends on who your customer is, what the entry point is, and how complex it is.
I know for us, we have a very heavy solutions architect piece, because the technical questions that people ask, they're really deep. So I try to get the sales guys all the way through to a demo, and then at the demo or a proof of concept is when we interject my solutions architects.
My solutions architects rock. They're super smart, and our engineering team, if I can show all of them to the customer, they're going to buy. And so I use that as part of the sales cycle, but we limit their time into the proof of concept.
You might want to look at that. I mean, I don't know your business very well, but I would experiment with different types. I wouldn't go hire a whole bunch of people. I would go get someone to be successful and close a bunch of deals. If you're closing it in a month, find out if you can do it in two weeks.
Then I would say if you can close it in a month, then you probably want to look at a flywheel that's a lot faster. Can you do it over the phone, or do you need to go visit someone?
Having someone understand your product and be a product expert, they may not have to be technical, but they probably should talk about, "Here's how customer X used it. Here's the value that they saw."
Then, when they get to the proof of concept, if there's a proof of concept or there's just a trial, if part of the sales cycle is that you have to generate interest, you have to have some sort of connectivity.
You're a developer, and you need to have someone who understands Ruby code. Then you're going to have to get a technical person to sell. The issue is, most of my sales guys are pretty technical. Just because of the nature of the product. It always comes down to the product drives what kind of salesperson you need, and what's cool about what you're doing is, you have a really short sales cycle.
To me, for 36K, if you can do in in three months, that's awesome from the get-go because you are a small startup. That's really good. Our first couple of deals took a long time, and our brand names, the ones that we have that are big customers on our website, they took a really long time because we were nobody, and nobody could even say our name.
I would try to codify all of the steps associated with customer engagement, because that'll allow you to take non-technical people and put them in a process, because salespeople understand process.
I never believe that anybody is the center of the universe, especially in a startup. You have to claim victories, and you have to have some, I guess not arrogance, but some confidence. You have to say, "We're the best. The world's leading..."
We see that all the time with people. They're like, "We're the world's leading X, right? And a lot of times, they don't even know what X is.
The reason you pick enemies is it gives you a space to play. When I was at Connor, we didn't know what we had. What we really did was we automated email messages that went to websites. And it became customer success and customer CRM.
We didn't call it CRM; we called it enterprise email management. We called it customer email management. We called it all kinds of things. We kept trying to label it, because we didn't have a competitor. When we got a competitor, it allowed us to frame what we did.
So that's why I say that. It focuses the sales team. I'm in a really comptetitive market right now, so I don't know if it's a whole bunch of kids on a soccer field chasing one ball and the market hasn't happened yet, but I think it has. I think with one of our competitors went public, and it opened up the doors, and we started to see a lot of business.
I think at one point, people were kicking tires around with solutions. Some of that is just where you are in the market. If you have a brand new disruptive technology that nobody else has there, and you can't pick an enemy, you've got to just educate people.
But I'm also super competitive, you guys. I'm a runner, and I try to do athletics stuff. I don't know if I can call myself an athlete, but I think in those terms. A lot of salespeople do. So it's more of a sales mantra.
I don't think if you ask any of our engineers if we had an enemy they'd tell you no. "Oh, we don't have any enemies. We have only friends." But from a sales perspective, we look at it as, "How do I charge that? Hell, how do I motivate it to go do really hard things?" And then I can also divide who's my friend and who's my enemy in the ecosystem with partners.
I can say, "These are the guys I need to do, and how do I build a market map around partner ecosystems?"
It's really hard. There's a couple of ways to do it. The early-stage startup is you get a bunch of people around a room, and they're like, "We need to go sell a million dollars of something." And they haven't picked the price point, and you don't know whether there are repeatable processes. So you hire a couple of early salespeople, and you say, "I'll give you a percentage of sales."
Most companies in their early stages will do a big percentage, because it's really hard to do, and they haven't built a repeatable process. That's a bit of an art. With us, because we have a pay-as-you-go model, I only pay the guys based on billings.
If they can book a deal that's got a minimum commitment associated with it, I'll pay them on that. Because that gives me forecasteable revenue, and it's very valuable to the company.
But when I look at the structure, it's really about what you want to try to do. The rule of thumb is, about 70% of your salespeople are going to make their number for the year. I talked to a really smart gentleman on Friday who was like, "Look, there are companies, I can't mention them, but there are companies that are public that you guys all know and you probably use their products, that overpay their sales guys because it's all about growth."
And so when you're in a growth effort, you want to keep the quotas low and allow for people to make some money, so that they bring in their friends and you can hire faster. There's a little bit of an art there. The cost of sales issue always comes up, and it's really about which market you're entering.
At Engine Yard we had a really high cost of sales when I joined because of the way we were going to market, and we changed that. We reduced that dramatically. And it helped. But did it hurt our growth? I don't think so in that market. I think if I were to try to do that at Qubole now, it would hurt a lot of our growth.
Here's the ugly truth; it's very important for us. I did marketing for Engine Yard, so I'm not a marketing expert at all, and I worked with a few of the analysts. It seems to me to be a kind of a game. You want them to position you in the upper right-hand quadrant, and you want them to even think about you and talk about you and know what you're doing so you have this education process to do.
At the same time, they can be great friends. If they think what you have is cool, they can introduce you to new customers, which happened to us just recently. They put us into an enterprise process that we would have never been introduced to in a Midwest company.
We were so different than everybody else when we went through the RFP process, which we had never been through, that we made the cut. So we were shocked, actually. But it came from one of the analysts, and the analysts are important, so you have to put some money away to play.
But you have to make sure that you use the right analysts at the right time and the growth of your company. We used the smaller analysts for a long period of time when I was at Engine Yard. You know, the 451s, the ones that are very much adapted to the startup world and can help us get to the next stage.
At some point, you've got to say, "Now I've got to fund a pool of money to get to a Gardner or a Forrester," and some of these other guys who are going to go talk about us and give them an open door to how you're selling, and who you are, so that they can compare you against other companies and position you in the marketplace.
What gets tricky is when they start positioning you in the wrong space. Then you have to really pay attention.
They're super important to me. We got into this web world, and conferences became more important.
In the world of Engine Yard, conferences were it, man. This is where all the public speaking was done. It was where we could meet people who were interested, because we were looking for a particular type of customer.
Cloud conferences for us are huge. Amazon's a huge partner for us, and their reinvent was an enormous opportunity for us. Same with Microsoft and Google's conferences. We don't do developer conferences per se. We do big data conferences.
Some of the conferences are built by my competitors, and in those it felt, at least last year, not so much this year, like inside baseball. It was like all of us talking to all of us. I was seeing people who used to work for me or working for my competitor. It didn't feel like a real market yet, with customers showing up, and I think that's shifting.
I think they're super important to get your name and brand out, especially if you have a community, or if you're focused on community and building community. That's where you start.
I have a friend who's doing a really cool thing with cold climate, and Brian started with the Ruby community. He went down there, he got a boom, he started pushing it, and then he went from that to PHP, and he got himself a brand name in the Ruby community. He moved sideways and I think he's done a really good job.
It's a good starting place, and it's cheap. You can start doing this stuff. I wouldn't get the biggest booth at event, but being there and having some sort of presence makes sense.
What, red flags for not joining a company? I'm an engineering bigot. I married an engineer, so I like engineers, and I have an affinity for them and people who build products. I think it's really cool. So that's my framework right there. I wanted a technical product. I wanted to work with engineers. So I always look for that.
From a red flag perspective, here's what I look at. If I talk to parts of the team, let's say I'm going interviewing, and I'm just meeting the engineering team. I'm meeting the product team, and maybe the marketing team, and if they're not aligned in their messages to me about what they need to do next, then I'm worried.
If they think they know what sales is, we just need more gas and go, then I'm worried. It's a red flag. If they don't value sales, and I've seen this, I've gone into companies that had a hundred people and you walk in and every executive I talked to was like, "Yeah, well, you know, we know how to sell. We just need the right sales guy."
You know, sales gets shot first, and the problem with hiring the wrong guy and then shooting him is that it wounds the company.
Because it is the point on the arrow. So I look for that. Does the product work? Do the customers talk about the product? Is there good word-of-mouth on it? Is there a market? That's so hard to determine.
That's the big part of the experiment on startups, if you get the right product in a growing market, you just explode. Is there a market, or is it just Gardner talking about this market that's supposed to be $14 billion in the next three years? And then it's 14 the next three years. I see a lot of that.
It's really about the team. I'm very happy where I am right now because the team is amazing. We're all pulling the sled in the same direction. We're very transparent. It's part of the culture. People come in to interview, and I know I always tell people too much, but that's who we are.
So, I look for those things. If that doesn't happen, and people are building kingdoms in political environments, they are no fun. Nobody likes them.
It was a small market. Ruby was, which is where we first started playing, and we have two theses: one was that the cloud was going to be big, and the other was that Ruby was going to be big.
Ruby didn't happen as much as the great community, I love the people there. But from an Engine Yard perspective, we weren't able to get as much money out of that community. So that's part of it.
Everybody's going to go into massive markets. That's where the play is, becoming the first mover. Advantage is important, but it doesn't mean you win. You can go out and get every enterprise customer out there, plant a flag and have no one to use your product in the enterprise.
Someone could come around in the bottom up and take over. I mean, if you look at what happened with Heroku and Engine Yard, I know those guys, they did a brilliant thing in that they had a multi-teneted product that allowed for people to do trials for free. And they played that card, and we didn't have that. I couldn't do a trial for free for almost two years.
So I hired PANDAs that helped people try to use our product and pay for it , and I took 25 dollars from them. And so their market approach allowed them to expand faster, and I was blocked out of that market approach based on technology. That's why I asked the product question. Because it's always down to the product as your market entry. What can you do?
I don't know the answer to that, I mean, I think about it in terms of how many soft drinks can I drink, I get a lot of different kind of drinks.
You know, I think it comes down to your defining the market. I don't know that I have enough experience to answer that piece of it. I think probably my colleague at Qubole in marketing could talk about that all day long. I think I know the mechanics of marketing without really knowing the strategy.
You're hopeful when you start a company. You go to a company that you have a large enough market where you can take a piece of it really qucikly. And then the question is, can you grow it to become a big company? A lot of people don't even want to do that. We're focused on trying to get that done. It's really hard.
I said to my boss the other day, we were coming out of a partner meeting, and I said, "How do you stay so calm?" He's a CEO, and he said, "If I don't, the whole thing falls apart." I think that's part of it.
You don't know going in if the market is going to be there or if there's a spark. We didn't know data was going to show up with a spark. And then it becomes a positioning thing. It's about customer acquisition, so we we support Spark and Hive and Presto now.
We didn't start there. We didn't know platform as a service, this amorphous thing that everybody was talking about was going to dissipate, and people were not going to talk about platform as a service any more. Now they're starting to again, but I don't think you know.
Thanks, you guys. I really appreciate it.