Javier Soltero
The First Million is Always the Hardest

Javier Soltero joined Redpoint Ventures as Entrepreneur in Residence in 2013, and is currently working on his new start-up Acompli. Prior to Redpoint, Javier was the CTO of SaaS & Application Services at VMware. He has 15+ years of experience designing and developing infrastructure management technologies.

Collapse
00:00:00
00:00:00
So a story I've told before. I'm sharing it primarily because as Tom mentioned, I've been where most of you are at. I was an accidental entrepreneur and through that process I learned a lot and hopefully I'll be able to share in as few slides as possible, how we went from 5 engineers, who had never started a company before, to building a successful company that was able to raise venture money from top-tier investors, then ultimately went through one of the most interesting successions of a merger and then, immediately after that a very successful acquisition.

So I'll tell you some concrete lessons that you all will be able to apply to what you're doing. So background on me: I'm originally from San Juan, Puerto Rico. I've been in the Bay area for about 16 years. I worked at a variety of technology companies.


My first company out here was a company called Netscape. Anybody remember Netscape? Probably you all were in like middle school, or something like that, back when Netscape was in its formative days.

So, I've been, for a little bit more than half of my career a developer - a software engineer. I studied at Carnegie Mellon. The way I came to be an entrepreneur was very interesting. I, along with a group of very talented engineers, wound up working at this start-up company called Covalent back in the early 2000's. I joined in 2001, and at Covalent our mission was to basically build a commercial version of the Apache Web server, which at the time and still is, one of the most popular or the most popular Web server out there. So, the idea was at Covalent to turn the Apache server into a Red Hat, Linux kind of business- what do we do on top of Apache to build a successful enterprise software company around it.

Along the way the company managed to raise an enormous amount of money from top-tier investors who I'll gratefully namedrop right here. So, Sequoia Capital and Menlo Ventures, thank you. Their money helped us build this awesome product. That company then folded. It folded in 2004 in part because it had been over capitalized so there was a big lesson there about being careful about what you wish for.

The company raised something like 32 or 36 million dollars. The number varies depending on who you ask. I was the chief architect there. In the latter days of Covalent I helped develop a new kind of management product that was built on a vision I had from prior experience of building large scale Web infrastructure environments for which there was really no management technology to use.

So we built this website before Covalent called BackFlip, it was a bunch of ex Netscape people. The site really never went anywhere, but the one thing I learned was that we had these "ops" people and all they knew how to do was mess with Cisco routers and cables and racking stuff and bolting things onto pieces of metal and occasionally installing Linux. In most cases they'd complain about that because they were FreeBSD people, or whatever the flavor was at the time.

So, what we learned from that experience was that we had to operate the site because the op's people didn't know anything about the actual application.

So at Covalent we ended up building the product that we wished we'd had at BlackFlip which was a distributed management product that allowed you to inventory and autodiscover everything about your environment and your applications.

It could collect every single performance counter that was available in any part of the stack from hardware, to software, to middleware, to your app. It could control it so we could start stuff discreetly from our console and do a whole range of other things.

We built that product and we're really fired up about it and we're like "Oh my God this is like the most awesome management product ever."

But then Covalent actually goes and takes it to market using a very traditional enterprise software model, after pouring $15 million dollars of their money into development and marketing, and kills it right as it was going out into customer's hands.

So, right before the company ultimately folded, we came up with this idea and we asked "What do VC's do when companies fold with the technology that their companies built?"

They don't repossess it because they don't know what to do with that kind of stuff, right? So they basically, they let it die. Like that was the outcome that we all saw. At the time, Google was about to go public (for those software and Internet historians out there). So, the way venture investors tended to think was, "We're about to make lots of money over here" or "This company is failing, let's wrap it up."

So we took advantage of that opportunity and came up with the idea of saying, "They [venture capitalists] don't want this software back and we've already sold it to 3 customers. They're gonna be pretty upset if they get burned on buying theproducts from these start-ups. "

So, I and 4 other guys went up to the Covalent board and investors and said "We'll make you a deal. We'll give you a dollar in exchange for assuming the liabilities from these 3 existing customers and you'll give us every single bit of this IP and we'll call it a day."

For the venture capitalists, that was the way they got to save face and say, "our company didn't go under" -- I guess today you'd call that a pivot, right, because there's a term for everything.

Now they're focused on management and it's called Hyperic. Why? Well, because all other good names were taken, right?We were convinced, at the time that we were going to ditch that name immediately. So we went off and acquired this piece of software along with these obligations from verylarge customers that thankfully I had been very involved in setting up to begin with. So these are customers that I knewwe were expecting to get zero money from, by the way. That money had already been collected by Covalent and subsequently evaporated.

We said, okay, "let's go build a different business around this." We felt our motivation, we as technologists were like, "You know what? This is unfinished business."

The thing that was messed up about this company was the go-to-market model and the way that the executive team made decisions. It wasn't the product.What did we hear from the company? This is a product in search for a market.

Now, there has been no phrase that has motivated me more than the idea of some investor saying, "Your product sucks".

It was about looking for opportunity and they were, if nothing, elated at the idea that we were taking this ridiculous piece of software off their hands. We grabbed it and set off and started our own business. Part of setting up that business and the story that I'm going to tell you today is about the decisions that we made while not knowing a single thing about a go-to-market model, how to sell products, and how to do anything other than things that seemed like the right idea at the time.

Just to finish on sort of my trajectory we built Hyperic out, built it from a bootstraped company to a venture-backed company to ultimately merge it with SpringSource in 90 days, selling it later to VMware.

I spent some time at VMware doing what occupied entrepreneurs do at large companies, which is try to be helpful and productive and interested and ultimately spent 3-1/2 years there.I learned a lot of great things which I won't cover here today. Maybe that will be the subject of another off the record Heavybit talk.

Now I am currently an EIR at Redpoint Ventures, although officially I am now CEO of a company that is just getting started. So, enough about me.

Before I walk you through the 5 stages of what we went through at Hyperic and how they might be helpful to you, I'll tell you a very quick story.Like every good entrepreneurship story I was tested very early on by the adverse forces of the market and circumstance and what have you.

I had this very interesting conversation with my dad where I called him up and he's like, "Well, how's your thing going?" and I said, "Well, it's not going good. Things are just not happening. There's no money coming in and we don't have endless amounts of money to keep going and I'm worried."

My dad, who has been an entrepreneur asked, "Do you believe in the product? Did you build a kick-ass product? Do you really think that your product is helpful?"

And I answered, "Well yeah, yeah, we built something really special and I'm really convinced about it."

He's like, "Well if you really are convinced that what you've built is awesome and can help customers, then you should stick to it. The moment you stop believing in that is when you should give up."

It sounds a little corny and campy, but the reality was that I got similar feedback from other people during that time.

I said to myself, "This is a product that solves a real problem that people have. People have already paid money for this product, so it's not like you're trying to figure out if there's really a market here. You just have to hustle and figure out how to get it into more people's hands. You need to understand theright route to making this business a success."

So that's what we did.

When all else fails, you believe in your product and its ability to help customers and that will get you through the day.

All right, so now onto the concrete parts of the lesson. The first thing we knew as 5 guyswho'd never run a company before: We had some idea of the problem that we solved, but we were convinced that whatever it was that Covalent was actually doing to take this product to market, wasn't going to work.

So we're saying, okay, "Let's go back to basics. What is it that we need to do to get this into customer's hands and get people paying?"

Well, the first thing is: Who's the right person to be talking to? Who's adopting this product? Who's influencing the decision and who's ultimately buying?

Covalent, because it was playing a fundamentally new game with old rules, was going at this backwards. They were going first to the buyer and then working their way down from the buyer, to the influencer, to the ultimate adopter -- because that's how enterprise software companies were built back in the day.

So, with them, I would parachute into an account along with a salesperson and say, "Hey, we have this awesome product, and can you please let us install it so that we can show you how awesome it is? We can have a discussion about how it might help you, and then we can maybe talk about you buying some of it."

But in the new world at Hyperic we didn't have this luxury.We didn't have any money, zero. No seed money, nothing, there was no money.

So we said, "Well okay, we can't do that. We can't fly anywhere, we have no money to go anywhere. So how do we do this?"

We thought about it, "Well, who are we trying to help? Is it the CIO of Morgan Stanley or whatever?No, it's the sysadmin. That's the person who touches and interacts with this product and who we help, right? That's the person who is the first person we should talk to."

Okay, so it's the sysadmin. Great. Check. Next question: What are they looking for? Are they looking for a next generation Web infrastructure systems management orwhatever they were saying when we were selling Covalent's version of the product? No, they're looking for Tomcat Monitoring or Apache Management or MySQL Monitoring or EROS or whatever.

They're looking for a product to solve a specific problem. They're not looking for a general vision. They're not looking for a systems management platform. Nothing like that. They're looking because they have a problem.

They run a bunch of Apache, it's breaking. They need to monitor it. Boom. Okay great.

Where are they looking?

Keep in mind this is 2004, but where are they looking? They're going to Google.If I had a problem and I'm like a sysadmin, and I manage a Web infrastructure, I'd go to Google.

What would I do?

I'd type Tomcat Monitoring into Google. Based on the results I would make a decision about what I'm actually going to try. It gets even more nuanced than that, because we said, "Okay, they're going to go to Google, but see our buyer - this sysadmin - is the most jaded person on the entire planet.They don't trust anything they hear from software companies."

So, they don't believe anything you say. So on Google it turns out you can buy your way into placements. Our view on our target adopter was so nuanced that we knew that at least our guy or gal is smart enough to not necessarily click on ads that they believe can be gamed by buying and so forth.

So, what does that mean?

Well, it means that we need to be the #1 search result for organic search results for Tomcat Monitoring, et cetera. So for those of you with computers in front of you, you can go look up VMware Management, for example, and I believe Hyperic to this day is like the #2 search result on Google for that.

The idea was they're gonna look for something specific. They want to land on genuinely good content that speaks to how you solve that problem. It's laid out specifically with pictures and in our case, a list of every single metric event and control action that we got out of that specific product was listed. Yes, by the way, we monitor MySQL, Linux, Solaris, Oracle, all this other shit, too. But for you my friend, you're looking for Tomcat and this is what we do for Tomcat.

The next thing we want you to do is click on this bright red download button that happens to be, next to this stock photography that apparently every single company uses or used at the time, that had the most multicultural crew ever assembled inside of a data center including a woman in a dark red sweater standing next to an aging guy, and a white guy, and a skinny guy, and a fat guy. It was hilarious.

I used it, you know, in at least 7 or 8 occurrences. We recently dug up that picture for posterity because it's a classic.

The idea was, there's a button to press where you get to a download, and the shortest path between [a customer] pressing that download button and getting their hands on the software, is what we [the company] were looking for.

So guess what? We did that.

Then next thing you know, in late summer of 2004,we start getting registrations. All of a sudden there's people filling in the form and telling us who they are,and giving genuine phone numbers, and all this stuff.

I'm like "Sweet, and so what do I do?"

Well as the designated sales guy in the company I start calling people up and then I get stuck.

Basically I was calling people and realizing that they had downloaded our software, but they had not installed it, and that was a problem. Part of what we were trying to design in our sort of poor-man's go-to-market strategy was to get everybody to install the software and by the time we talked to them, they'd be delighted and ready to pay, right? Not quite.

So, I'd call these people up and I'd say "Hi, I'm Javier from Hyperic, blah blah blah "have you installed it?" "No, I haven't had a chance, or "Hey I tried it, but I couldn't get it to work."

Then I'd ask "Hey, can you please give me some time to walk you through it?" Some people did, most people didn't. Somehow it just never added up. Things got really ugly. We were basically at the end of our rope in terms of our tolerance to not make money and to endure the hardships of bootstrapping a company.

So, I started thinking "We're in really, really deep trouble." Because I had no other recourse, I got together with my other co-founders and I said "Hey, we're in really deep trouble. People are just not able to install our product so I think the only thing we can do is basically start applying our product and engineering brain to this to see if we can help solve it."

So, what do we do?

Okay, well let's start with common sense. So you're selling to the busiest, most jaded person in the world, all right?

So given that they're busy and jaded we have to basically line up and write out all the steps from the point at which they're looking for us, to the point in which our product is actually showing value. And that's an exercise, by the way, that I recommend every single person in this room actually go and do.

I mean be specific and detailed about the user steps. In our case it was [the user] goes to Google, enters Tomcat Monitoring, goes to landing page, clicks button, fills form, picks package -- I mean every single step.In our case it turned out it was 39 steps which is a shitload of steps. So, we said, "look, this has to be 3 steps."

Of course, my co-founders who had known me by then for a while were like, "Dude, you are crazy. Get out of here with this, there's no way. We can't do it."

We gave ourselves an hour. We said, "We're talking to the busiest person in the world and that person is going to give us an hour of their time and that's it. " It turns out today, sadly for all of you, that person is going to give you no more than 20 minutes.

Why? They're busy and frankly, they've heard it all. So, show don't tell, right. So out of a very, very significant hardship that we faced as a team, we didn't get on our creative marketing horse and start talking differently about what we were doing. And we didn't juice up our Google AdWord spend.

We basically went back to the product and said "Well the only knob we can turn here is to make our product easier to install," and arrived at what I wound up calling the "theory of reasonable defaults".

It's basically, Don't ask the user questions. If they find Tomcat, fucking configure it, and do whatever magic. Don't ask them what metrics they want out of this, just enable which ones you think are the right ones and they'll go and change them later.

Like there was just some fairly obvious things that we were thinking as engineers needed to be decided by every person, but the most important thing was that during that exercise cemented our view on how this process was supposed to go for our customers. And I should give due credit to my co-founders, because I wrote none of this code at the time.

Inventing things like this are part of the reason why Hyperic today is a) still called Hyperic, and b) still sold as a stand-alone product by VMware.

And that is basically the value of time. In a category of products where people told big stories, and people hated the category ,and every product that was in that category -- Hyperic, for all its warts, was still the only product in its class that would be up and running in less than 20 minutes.

The skill-set required to install Hyperic was no more advanced than the skill-set required to install Microsoft Word. I think that was a very, very important benchmark for us.

We did that and next thing you know things start actually happening and we start getting more interest from customers. We said, "Well why are they going to pay? What is it that we charge for?"

We had a number of offerings where you could run it on 3 computers and it's free or, you know, anything above that and you have to pay. I don't have the right answer for each one of you in terms of your business, but you have to have a very, very clear viewpoint on where the value is.

I'll talk a little bit about that further on in the presentation, but it's better for you to not think of the paid component like you're offering a strict list of features. In our case we wound up arriving at a list of principles that when applied to anything about how we built product or offered services, meant that you had to pay, right. I think it was performance, reliability, and scale, that were the 3 axioms upon which we built our paid offering, but I'll talk about that a little bit more later.

The last part and this is for all of you who have the unfortunate task of having to sell, even though you don't like. But as entrepreneurs eventually you will have to sell and you will have to do it especially if you're selling to IT. You'll have to get on the phone with somebody and convince of the order and at times, if you're a kind-hearted sort, it's the hardest thing ever.

People will string you along endlessly until you say, "You know what, time to pay."

And they'll answer, "Oh, I was gonna use the free version. Good bye."

And if you don't have the balls to do that, well then you shouldn't be in this game because frankly the buyer, that same jaded and busy customer is also the cheapest person you will ever meet in your life.They love free. They'll take you for everything you've got. So keep that in mind.

Okay, the next thing that happened is we started getting calls from companies who wanted to OEM our product and OEM for those of you who don't know is basically people wanting to license our product and redistribute it as part of their own offering.

Now initially when I was first approached by JBoss at the time, who was just taking off as the sort of open source Java application server of choice, I was really uncomfortable with this because we were a 5 person bootstrapped operation that was just getting theirdirect sales act going. The prospect of licensing our technology and having somebody else sell it it was very uncomfortable.

It felt like I was giving away the keys to the store. There was really no way that I ended up being able to get comfortable with the idea that no matter how much money we were going to make potentially that it was the right deal to make.

Frankly, I didn't have the blue shirted, khaki wearing, beady guy on our team to go and putz around with these guys and arm wrestle over term sheets and all this other bullshit.

It was just me, and frankly doing the wrong deal at that stage for us would have meant basically selling the company without knowing it.

So I was very confused about this and it really tormented me for a long time. So I'll spare you the torment and I'll give you some clues as to why or why not you should do this.

So, why should you do an OEM?

Well, you're a small company. You can't get everywhere that you want to get toso if you can, use OEM distribution and this is different than resellers. No one in here should be contemplating resellers, in my opinion, because no one can sell your shit until you figure out how to sell your own shit basically.

So in terms of an OEM if you have a potential partner or licensor who can get your product to places that you know you can't get to, that's a good sign.

The second thing is you're going to get paid for the privilege. So as a company that's bootstrapping, it turns out that when we ultimately did do our deal with JBoss after much harassment and negotiation. And we were paid very well for it and ultimately it got us a higher profile as a company.

Now Hyperic was a package software product. It's different and a lot of you guys are doing developer services. We can talk a little about that in the Q&A. I'm curious if any of you have entertained the possibility of OEM'ing or doing licensing deals?

Regardless, the idea of doingoutsourced distribution or licensing is something powerful.

Why shouldn't you do an OEM?

Well if your product isn't suitable for it. Namely, if you can't divide your product up in such a way that you can license part of it to someone and still retain enough value on your own to proceed with your own plan, then you shouldn't do it.

That's when you're giving away the store, right.

Then secondly as I already mentioned, if you don't know how to sell the product, then you don't want to have somebody else try to sell it for you. The chances of them being successful are slim to none. For OEM's in this case, you should assume by all accounts, that the answer is no.

So, good guideline: If you can't put yourself in the shoes of the potential licensor and see with very, very strict clarity how they would package and sell that product successfully to their customer, then don't work with them.

You need to understand both sides of that deal. You can't just think, "Okay, I'm gonna get paid and the absolute sunny day scenario of this deal is going to be worth to me 2 million dollars." You can't just let them do whatever they're gonna do, wish them good luck and expect a check every quarter.

That's a sure fire way of getting royally screwed in this business.

Another good guideline: This isn't worth doing unless you expect to see 15 to 30% of your revenue or your bookings or whatever from this source.

If it's going to be incremental and you can't see a way for an OEM deal to turn into a significant contributor of revenue in cash to your business, then don't bother. They're hard. They're not autopilot-able things. They're certainly not things that are implicitly successful, they're hard. If you do them right like we did, and it ended up even years later, our OEM and indirect distribution turned out to be about 30% of our business.

It was really, really helpful.

So anyways, some good observations on how to add new gears in the distribution leverage of OEM. The third thing. Okay, so the wheels are turning. Maybe you have some OEM. So if your product is getting out there one way to overcome the jaded and sort of skeptical nature of your buyer, is association marketing.

One of the observations that I came up with was that every small business wants to pretend like they're big in some way.Every mom and pop IT shop thinks that they roll like Google does. So the idea is that you land a customer that is a name brand customer,and you use thatas leverage. You help customers see the way they operate and the way that you would help them be more like the name brand customer.

That's a very powerful story to tell, and we did that very successfully with a number of high profile clients. It's tricky because they're clients that are often very expensive and they take more out of you than you get in terms of your revenue. But if you manage them correctly and if you pick very few of them (ideally one), then at least for every customer you get after that, you can say "Yes, you could see how we did this for Google ".

The last bit on this is the land and expanse element of this. The people talk about starting with a small toehold and growing your presence in an account. But don't assume that happens on autopilot.It takes just as much, if not more effort, than it does to land a new customer. Part of the reason is that unless your product is bloody miraculous, it's gonna take effort for the customer to see enough success in order for other people to really be wired up to advocate.

So you need to think very carefully about how you achieve that and how you build your internal champions and so forth.

It's a really important component and later on when we grew up as a business, we had two vectors of new business.


  1. We had new-new business which was new business from new accounts, and;
  2. New business from existing customers and we had different strategies to deal with both.
Step 4, this is probably the most interesting bit that I'm gonna share with you today - Tuning the machine. I looked at everything we did. It was like we were assembling an engine and it was the most fucked up engine you can imagine, honestly.

It was an engine that we were assembling from all kinds of scavenged parts and guesswork and whatever, but it ultimately did start turning like an engine and it was moving, and money was coming in and it was working.

So the next question became pricing.

So on pricing. Pricing is a really, really complicated and often troubling thing. There's 2 approaches you can take.


  1. What I call scattered plot, which is basically when you don't know what the right price for your product is, so you just do your best to keep it within some boundaries and see where things land. There's some strong advantages to thisbecause in an early stage company you just don't know, right. You'll know later because as people become more familiar with the product and as you know a little bit more about what it is that's worth selling inside of your offering today, you'll be able to calibrate that over time and do some intelligence on that.
  2. The second approach is discipline, which means you're gonna be absolute hardliners on this, there's only one price. That is very courageous. Anybody here doing like sort of discipline pricing? You have one price and it's non-negotiable.
So for scattered plot, acknowledge your pricing strategy and guide yourself and whoever is doing your selling to say here's the boundaries. We're gonna spend our firstx-number of months or year, getting deals within this band and then we'll figure it out.

For discipline pricingm you're gonna have to have the courage to hang up the phone and be like "The price is x," and our friend, the jaded, cheap, disbelieving, busy, friendly IT buyer is gonna say, "Well you know, there's always a deal, and why don't you have published pricing?"

IT wants to have it both ways.They want published pricing because they demand that you tell them upfront. Some buyers, a lot of them, are going to say "I don't trust any vendor that doesn't put the prices on their Website, but then when you say "Well that's the price. You saw it on our Website." they're gonna say, "No, that's not the price. The price is what is today the 29th? What is the price on the 31st?"

Right, and they're gonna do all that kind of BS which in a disciplined pricing model you have to be courageous enough to say, "the price is the same on the first of the month as it is on the 31st of the month."

I commend you if you're able to do that. That is very, very, very, very hard. It's hard for VMware and Cisco as it is hard for, you know, all of the small companies that are gathered here today.

More importantly, you need to understand this machine.I'm like, "Okay so what are the pieces of this engine and how do I effect change? What are the knobs?"

You're first spending a lot of time just assembling an engine that runs and then next thing you know, you're in a position to say "I'm gonna tune certain parts. I might upgrade certain parts."

That's sort of how we looked at it. So in order to do that I'll share with you the construct that I arrived at in order to explain to the company and our investors how money actually arrived at Hyperic.

I called it "the diamond" and there's variations of this. I mean you hear a lot of people talking about the funnel purely from a sales lead perspective, but that is a very myopic view on how someone goes from being a prospect to being a customer.

This is a lot more about being in an open source company as we were, or in a company where there is a free product and then a paid product. It's about how the dynamics work between how people move and self-qualify themselves through that process.

So how does this work? Okay, well at Hyperic the first thing that we wanted people to decide when they showed up at our Website, was whether they'd have an open source relationship with us or are you going to have a commercial relationship with us?

Unlike some other companies like MySQL who had had a dual identity. There was a dot-org sort of open source site and a dot-com commercial site. Hyperic had really only one site. So the expectation was that somebody was going to show up at our storefront and make a decision.

So the important thing there is, you want to make sure they make the right decision. You also want to make sure they make a decision.

So, there's a decision that says, "I'm an open source user, I have no intention of talking to a salesperson. I am kicking tires. I don't know if I like you yet." So those people are going to go down the left hand side and the action, the measurable event of that, is a download of our open source product.

On the other hand, we had a download of the commercial product. Now the important thing about the right side of this diamond was because we were a commercial open source product in an established, predominantly proprietary or traditional enterprise softwood category -- there were plenty of people who showed up at our doorstep evaluating us against commercial proprietary vendors who charged a shitload of money.

We didn't want to indulge the cheapness of that prospective buyer, nor did we want to miss out on the opportunity of showing them what the full weight and power of our sales team, our sales engineers, our product organization, and all that were.

We wanted to make sure that if you're showing up at our doorstep with cash in hand,that your ass is going down the right side of that diamond for sure.

That would result in a commercial download and so off we go.

The next step in an open source download event was the actual installation of our open source product and this we knew because our product phoned home.

This again, this is biased I suspect a lot of you have models that don't necessarily apply directly to this, but this is kind of how you should think about it.

They [customers] start using your product and then we have some sense that they registered and have actually activated it. They've gone through an event that tells us that they're actually using it in some way.

On the commercial side it was a little bit different because right after the download and the registration,you'd get a phone call and that would qualify you and find out if you were actually serious. It found out if there was an active project, who you were, who were the other competitors, et cetera, et cetera, et cetera.

So actually, in fact, I mislabeled that.

There's sales lead and then there's sort of the notion of a qualified opportunity which is really the next bit. The difference between a lead and an opportunity is basically not only do we know that you're actively looking, but we feel like we have a chance in actually winning the business and we're on your shortlist of potential purposes.

In every part of this there are numbers. So for those that are sort of disconnected from the notion of bullshit go-to-market planning and metrics, it's very easy.

Up here 100 people showed up on our Website. 33 of those people would make a decision to either go one way or the other. That's pretty good. That means 1 out of every 3 people would take an action on our site.

From a Website conversion perspective for this kind of product, we felt pretty good about that. And then you'd have a certain number of downloads and those downloads would result in installs. Now the degradation of this and the delta between the number of downloads and the number of heartbeats that we got on a given day, told us something about whether our product truly was as easy-to-install as we thought it was.

It turns out, as we learned immediately after we put this process in place, that a huge percentage of these downloads were Windows. But then, a very small percentage of these installs were Windows. That told us there were some real issues with our Windows installer. We fixed that.

This conversion or this sort of percentage actually increased tremendously.

Similarly, the delta between commercial downloads and sales leads tells you when you are actually luring the right people. Maybe they're looking for a product, they think your product is the right one, but it turns out it's not. In the sales lead to qualified opportunities then, you're more into measuring whether your salespeople are actually navigating the account correctly and are taking customers through a process that gets them more excited about buying stuff.

In the last vector, we came to the conclusion that it was very difficult, if not impossible, to directly monetize our open source product.

We played with it and realized that the cheap, jaded buyer need to be on the right side of this diamond. Anything over here and they're sort of predisposed to avoid paying for anything. But what we did notice was there was a significant number of things that became qualified opportunities instantly.

More than 3/4 of our qualified opportunities were actual open source users.Why is that important?Well, the whole reason we did this was because we wanted to create a self assisted POC, an evaluation process that involved no interaction between Hyperic and the prospect until it was prudent to actually talk about a commercial engagement and money.

It costs you money to have people basically bullshitting with those that are not going to buy. So if you have sales people, marketing people, any professional other than product people engaging with prospects that are of the wrong kind, you're wasting money.

These designs, these kinds of businesses, and I think this translates very well to the sort of SaaS and cloud-based models of today, are fail fast businesses. You should spend no time directly engaging and courting those early-stage free offering customers.

You should build a business model, a company, and a product that guides people through that process no matter how long it takes because you can't force this to happen.

So ultimately as we looked at this diamond, we saw 3 very important functions of the company that could be held accountable to each part of this recipe.


  1. Up here this was all about marketing. How are you bringing people to the site? Is it SEO? Is it PR? Is it events? Is it? Whatever it is, whatever program spend you're doing, comes in up here. The decision to go one way or the other that's the decision around copy. It's a decision around Website structure, landing pages, A/B testing, all that fun stuff. Marketing could be held accountable. If we ran a program that said this month or this quarter we want way more downloads of our new open source product, marketing has the knobs to actually turn further in that direction. To put it in context of a smaller company all of these things are things you can effect on your own. You don't need a full marketing team like what we had when we figured this all out. By understanding the mechanics of the machine, you will do a lot better at trying to effect change and it will feel a lot less like you're just trying to throw darts to get more money and more leads. It's just much more concrete.
  2. Product: Similarly, any drop off between the download event and either an install or a sales lead, was a function of whether the product was actually doing what it was supposed to do. So if it was an installer issue, or there were quality issues in a release, you'd see those manifest themselves very quickly in that process. In fact, when we looked at the time when we put this together, we had an initiative. So this was called "Project Diamond" and we had this initiative about trying to effect the supportability of certain sized environments. So there's a separate graph that I'm not showing, where we distribute the number of nodes of our software with self-supported customers that require no interaction from us on the one side and basically occasionally file a support ticket, but they don't need hand holding pre or post sales.And to the right of that line I expect there are high-touch customers. Being able to move that line and making our product better and more self sufficient in higher scaled customers, ultimately was a function that was expressed in the way these numbers actually worked. These are the kinds of initiatives that as you grow up and become a bigger company, you can give people a rallying cry, a measurable rallying cry that allows them to get better.
  3. Lastly, with sales: I think with the various conversion events in between here, turns out were actually good at Hyperic. So for things that wound up herem I think we won something in the order of over half of any opportunity that we were actually actively engaged in. Now if you trace that number all the way back to here that doesn't mean that we were super crushing it. But at least we knew that by the time that somebody got here, the chances of us actually winning were very good. I encourage you to use some kind of construct like this to basically understand your engine and understand how it's all put together, in order to then be able to effect change on it.
And then the last bit is the subject of scaling. And this I have the least amount of content on from a bullet perspective. People think the next step after you've raised seed capital and after you've kind of established yourself as a business, is to "scale the business". A lot of that involves the scaling of your sales model and scaling of your ability to make revenue.

The debate about when you should hire a sales leader is one that is kind of hard to answer and depends on a case by case basis.

My personal advice: The reason why I waited to hire a sales leader, is the same reason why I'm writing code for our new project.I want to be able to know how hard something is, before someone can come and bullshit me about it. And it's the honest truth.

Sales people, sales leaders in particular, will show up and dazzle you. You might think, "Okay, here's the keys. You have a number, here's your bag, I'll check in with you a couple of times from here until the end of the quarter."

And that's the wrong move. You need to feel as the entrepreneur, direct ownership of making that number.

At Hyperic it was such a big deal that every engineer, every support rep, every person who worked at our company knew what our revenue target was, our bookings target was for that quarter.

Most companies actually don't do it this way, but because I came into the whole process sort of obsessed about it, and because it was such an integral part of our success as a bootstrap venture, I remember distinctly being in all-hands meetings and havingQA people come up to me and say "Jav, how's the quarter looking? Are we going to make the number?"

That is a good sign because when you look at things in terms of that diamond people knew what they could effect and feel ownership over the financial success of the company.

You don't want to ever create a situation where there's a separation and the product guy says, "I'm just a product guy building product, and the sales people well if they didn't make the number well then they suck. "

I worked at plenty of start-ups that operated that way, they all failed, all of them. In terms of how you go and make this case to VC's, well the best way having sat inside of a venture firm for the last 4-5 months is to be able to speak from experience.

So unless you know and unless you have some opinions and grounded facts about what it takes for people to actually spend money and pay you for stuff,then there's really no point in going to a VC and saying "I want you to give me money so that I can go and then hire somebody to go help me answer that question."

They're not going to go for it. I mean they might, but they probably suck as VC's.

And then the last thing I encourage you all to think about in the event that you are the founder or CEO, is that your role will change, so in the best case scenario you will evolve a lot in terms of your responsibilities and the things that you're most focused on.

You should be conscious of that and not be sort of a passenger on this journey. You should decide who you're going to be, how you're going to stay involved, what you'll need to compliment your skill-set in order to make this company successful. You should as, "What do I really want to stay involved with? What do I not give a shit about?"

A good example of this is with my good friend Martin Mickos, the CEO of MySQL and his thoughts on facilities.

He didn't give a shit about facilities, so much so, that one day I went to visit him in his office and I noticed that he was in a different office, and I said "Oh, you moved."

And he said, "Really? I don't know I just came here."

I asked, "You're not in charge of deciding the office is on the 7th floor instead of the 6th floor."

And he answered, "I have other people worry about that. I don't worry about that at all."

So knowing what you care about and what you don't care about, is really important.

Some people care about facilities. I didn't care about facilities. I blame Martin for that. And that's it. Thank you for listening.



Want developer focused content in your inbox?

Join our mailing list to receive the latest Library updates. After subscribing, tell us your preferences to receive only the email you want.

Thanks for subscribing, check your inbox to confirm and choose preferences!

You've been here a while...

Are you learning something? Share it with your friends!