October 25, 2016
Dev Tools Digest – Oct. 25
In this Dev Tools Digest, check out a new open-source tool from Keen IO for cohort analysis, learn how to "Dockerize" any app the right way,...
Read more about this presentation at David's site forEntrepreneurs.
Welcome everybody. It's a huge pleasure for me to be here and thanks to Dana and the Heavybit crowd for setting this up. So my hope is that at the end of this evening I might have given you one creative idea that might help you unblock your funnel in some way or another. So let me start by giving you something which I think is somewhat useful. I tend to think there's one key question that in every board meeting is the question that's on my mind as the top question to ask.
That is when are we going run out of money? And at the time that we do run out of money, what are the milestone that we need to have reached so that we can actually successfully raise capital again. And I think that is the most important question that kind of drives everything. Because once you start figuring out, " okay we have to achieve these milestones here", it brings everything into focus for a company.
So I like to think of a three phase model as being really helpful in this, because as an investor these three phases are what determine what level of risk or de-risking you've done. And the first one's very well known and very well written about which is a search of product market fit. I think the second one is less written about and to me it's what I want to talk about a lot this evening. And that is how do you build a repeatable, scalable and profitable sales process.
And then once you have that, if it is truly repeatable and truly scalable and truly profitable, what you should do is pour money into that thing and just go like crazy and scale the business. And clearly what I'm trying to get across here is that
Your risk curve dramatically drops as you go through these three phases.
So hopefully what I help you with this evening may be to get you to further along the lines towards a repeatable and scalable and profitable machine. So there's an interesting question that I love to start with here, which is, why the hell do we need a sales process? Who invented this damn thing? And can we get rid of it completely? Because I would love to get rid of it. It's just a pain in the ass.
So let's imagine a scenario where we've got a brand new database that is usable for amazing sets of things that none of the current ones do and on the website here that you arrive at it, it says, "we can do transaction processing and we can do business intelligence and queries and we can do it at the speed of the light and we scale up infinitely and we've got infinitely perfect response times". So you read all that and it says "$10,000 buy now".
Let me ask you a question. Why would you not buy now? Can any of you kind of help me out here a little bit and tell me some of the things that occur in your mind immediately. "I'm not going hit that damn button". Why? Why not?
It may be too expensive, or you may not believe me. Or you may just want to try it first. So what we've got here is that it doesn't work and the reason why is that there are a bunch of questions you guys have. Is this going to integrate with my existing software? Does it really, truly work? Is this a safe company to buy from? And then there are a bunch of other things too. I might have a buying process. I might have to go and get approval and find budget for this thing as well.
So those are effectively factors that we need to take into consideration on the buyers side when we stick up our buying process here.
So what we typically do when we figure out, "hey, we can't sell them on this thing in five seconds flat" is we invent a sales process to split this whole thing up into a few stages.
And a classic one that I'll bet many of you are using here is you have a website. And at the website you encourage them to go into a free trial and then after they've done the free trial you hope they're going hit the purchase button then. Because they'll have answered at least some of the questions that we're talking about here, which is does this thing actually work and is it value for money.
So ultimately with that sales process, we end up with a funnel and the reason for the funnel is that people don't flow perfectly through. They might hit your website but they might sign up for the free trial. If they sign up for the free trial, not all of them purchase.
And what I've been doing for many years in my life is studying funnels. I'm absolutely passionate about them and I love understanding why they don't work and why they do work. And what I've found is something kind of interesting here, which is that blockage points are the most immediate place to focus when I start talking to a new company. What is not working well in their funnel? What would they like to have working better?
And I discovered something kind of interesting here which is
A lot of these blockage points are caused because the company created a vendor-centric sales process of how they thought things should work. And I believe these fail because you want the customer to do something in one of your steps that they're not motivated to do.
And so what I want to help maybe do this evening is give you some thoughts on how to get expert at sitting inside your buyer's head and understand why they're reacting the way they are to what you are asking them to do. And let me give you an example here. One of the fun things that happened to me this evening is that Ben Sabrin who some of you might possibly know is the first sales guy at JBoss, arrived this evening and walked into the room.
And for me I haven't seen Ben in many, many years, but he's going be very valuable in terms of verifying that this story's actually true for you. So I got to know JBoss as one of the early investors. This was really early in open-source. You have to remember this is back in 2003 before there was any such thing as a big open-source business. There's only one company succeeding that was really Red Hat. And there was MySQL and JBoss were trying. JBoss was 11 people in a two-roomed building office and they were making about 50,000 a year selling mostly training and documentation.
Ben was the key sales guy there who had cracked this thing and they had this new idea about how they could sell something much more expensive. So I was excited by the company because they had five million people that had downloaded of the product. And so the very first question I asked him was, "terrific, this is amazing, let's get the email addresses out and let's start thinking about how we're going connect with and contact these people". And they said, "well, we've got a small problem here. We don't really have any email addresses for anybody except the people who signed up for training".
So we asked, "why is that the case?" And they said, "well we tried asking for an email address but it dropped our download rate by a factor of 10, so we had to take it out". So what basically I like to do, and I think this is a really kind of nice, systematic way of working, is
At any blockage point, get inside of your customer's head and think to yourself, "what's stopping them from doing this"?
In this case here, is there friction involved? Well, it's not much friction to type your email address in. But there are concerns nobody wants to get spammed. So there's a lot of reluctance to do that. So you either redesign the step to avoid that friction or those concerns. Or alternatively, you can look for a motivation that's powerful enough to actually pull them through the friction, that's strong in terms of what benefit they'll get out of the thing.
And what we did there was, we looked around and we realized that they were making 27,000 of their 50,000 monthly out of this documentation sale, and everybody really valued that. And as Ben will attest, it took a little bit of time before they agreed to stop selling that and give that away free. But that became the motivation that we used to actually get the email addresses and that switched on 10,000 leads a month of flow and that created the impetus for the company to hit 65 million in ARR in two and a half years after that point in time.
So it was like a killer unlock there. And what's really fun is that, and it's such a shame I don't have it in the deck here, but Ben will tell you that we have the photographs of the whiteboard where we ran through the whole buyer process. And we have literally for every step in the buyer process, what are the buyer concerns? What's the buyer friction? And we did this back in 2003.
So this methodology has been around for a while and worked well there. So let's take a look at what I'm recommending that you guys think about doing here, which is creating a buyer-centric funnel as opposed to a funnel that's constructed the way you would like things to work. And the starting point for that is to understand the buyer's journey. And you guys have probably all heard this, but I want to give you a cool illustration of this.
So imagine your partner has asked you to come to the station to pick him up and you've arrived there 45 minutes early and you're now stuck with some time on your hands. So what do you do? You go into a store. Let's say a clothing store and you're wandering around. The very first thing that happens to you is a salesperson comes up and says, "can I help you?" And you're kind of a little taken aback by that.
And you say "no, I'm just browsing, thank you very much", and they go away for about five minutes and then they see you heading over to the sweater section, they come back and they attack you again. "I see you're interested in sweaters. There's this new collection that just came in from this designer and I think this one here would look really good on you". How do you guys feel about that salesperson in that moment there?
Is there anybody who wants to raise their hand that likes that particular salesperson in that situation? So nobody's raised their hand. So let me give you a different example. You're going to black tie wedding. You're a male. I'm afraid it's a male example here. You don't have a black tie. You are in a hurry. You run in to Nordstrom, desperately trying to figure out where the hell are the damn black ties. You can't find the section where the black ties are. You're looking like crazy to find a damn salesperson. There's no salesperson around.
Why in the second example, are you unhappy because you can't find a salesperson and in the first example, you're just so irritated that there is a salesperson there? Well the answer is that you're at different stages of your buyer's journey. There is an awareness phase which is where you were when you walked into that clothing store. You really hadn't made up your mind that you actually wanted to buy something at all.
You're just starting to become aware that there might be some interesting sweater or something like that. And in the second example you are way down the line. You are really close to purchase and you desperately wanted the full information there. So one of the classic mistakes that I see companies make is that particularly when they've paid salespeople to join the company, those salespeople get uber-excited about the fact that their job is to sell.
So when anybody turns up on the website, they pounce on that person. They're like that aggressive salesperson that hits them when you walked into that clothing store and they're just annoying your customers. They could not be driving them more berserk and upsetting them more with that behavior. So one of the first things to be thinking about here is recognizing that different people need different treatment depending on where they are in that buying cycle.
And there's another interesting thing about the buying cycle. And that is that there are actually triggers that cause people to go from just being interested in something to actually considering to buy it. So I put a couple of sort of simple triggers up there that everybody has. If you're moving house, you're going need movers, you're going need insurance for your new place, et cetera. But in the development environment, sometimes triggers are things like you're starting a new project. You've gotta pick a new frameworks, et cetera. Or you've had a major problem with bugs on a multi-stack system and you need a system that'll help you debug those.
Or you need something that's going help you track down performance issues because your app's running really slow. So those are triggers that cause you to enter a buying cycle. And I believe
It's really valuable for you to ask yourself "what is the buying cycle trigger for my product"?
And understand it. Because it helps you with two things. The first thing is it allows you to target people better. So you can actually try and find people that have already gone through that trigger. And you might be searching for certain things. The other valuable thing though, is sometimes you can actually cause the trigger to happen. And I did have one example. I pulled it out of here but I'll quickly mention it to you, that one of my portfolio companies is HubSpot. You guys might be aware of them.
HubSpot had this thing that was amazing called the Website Grader. And it had a score at the end. And when you got a low score, that score acted as a trigger. You knew that if your boss found out that your website's SEO was terrible, you'd be in trouble. So you immediately wanted to find out how you could solve that problem. So that's a cool way of showing how you can actually create a trigger by understanding what's going on in you're buyer's head there.
I don't want you guys to read this slide, because it's a potential followup thing here for you. But what I recommend is that you build a buyer persona and I know it's been talked about here before. These are some questions that I find really helpful. Like "what does the boss expect of this person? What results are they judged on as to whether they've done a good job or not done a good job?" And these are things that will help you understand what motivations you can use to actually pull this person through your cycle by understanding what they care about.
It's different to what you care about and it's that understanding of the mismatch between what you care about and they care about that's kind of the art of doing this well. So when you've done it, next thing is to figure out how do they buy? And if you don't know this, may I recommend that you form a small advisory group and you don't actually have to bring them all together in a group, but individually talk to your buyers and say "tell me about what does it take to get a purchase done in your company? Do you have to go and get budget approval? Do you have to deal with IT to get their sign off? Do you have to get an approval from the security folks? Does this thing have to be passed as compliance by your audit committee?"
And know all of the factors that they're going use to make this decision and how they go through their process. And I just drew a very simple series of steps here. So a common thing that the buyer's going do is they're going create a shortlist of vendors and they're going have to probably produce an ROI. And what we've seen is that people are terrible at producing an ROI.
So now you want to look at your process and kind of map it against this and see how well does what we're trying to do match what they want to do? And you may add some steps to that that are actually required to help them with their journey. So it'll really help them if you actually head-on address the competitive issue and show them why you're actually better than all of the people that are going end up on their shortlist.
It'll also help them if you can produce an ROI tool that'll automatically spit out a presentation that they can use with their boss that they will save them a lot of time and give them this immediate benefit from that. So kind of a worthwhile thought there. And if they have special decision making criteria like for example, a common thing is, " is this product secure? And it has to be compliant with a particular thing that is required for a Sarbanes-Oxley rating."
Find a way to maybe get a third party to come in and do a security order on your firm and write a white paper on it, so that they don't have to worry about that, they just say, "oh, God, these guys they've really proven that they're actually secure".
So you're mitigating all these questions in advance by knowing how they go through their buying cycle.
Now one thing that I think is fascinating here, is that all of you guys, as I understand it, sell through developers. And for my mind, one of the key things to understand about them as a persona is that they're typically not the buyer. And I think sometimes that can get confused. So if I look at just a couple of key characteristics, to me, developers, and many of you are actually developers, you guys hate spending money.
You're not fundamentally interested in writing large, $20,000, $100,000 dollar checks. You love stuff that's free and you love stuff that's open-source. So that are a couple of key things. There are some other characteristics that are less important that I just threw up there. But one that I think is important is at the very bottom of this, which is developers have an enormous amount of power in their organizations.
Because they are so hard to hire, what they decide to choose to go into the stack does get kind of forced on the rest of the organization. So a very powerful person there. So I think of developers as a wonderful channel to get to your actual buyer who has the money and who writes the big checks.
One of the things that I've seen as a common mistake here is that people accidentally figure out that they should be trying to monetize the developer and focus in on trying to get cash while they're in that development phase.
To my mind that's a huge mistake. What I think you want to be doing is getting as much market share and ubiquity as possible and help your channel remove every point of friction possible for them and recognize that you've gotta help them sell whoever is the buyer. They're actually going do that selling for you. So that's one sort of very minor thing then. And in the JBoss case, we have this great situation there where all of those five million people in the early days, they were really fundamentally developers who were using the tool because it was a quicker way to develop apps.
But the actual interesting thing was that eventually, when an app got into production, we ran into this totally different persona, totally different characteristics, who was the head of operations. And they focused on up time, low latency. So quick user response time, compliance, data concerns that they had, like privacy, et cetera. But the most interesting characteristic about them is that they wanted to throat to choke if this thing went and wrong at two o'clock in the morning on a Saturday.
They wanted to know that there was somebody there that would help them out. And they were never going put this thing into production if they didn't have that throat. And they wouldn't accept putting something into production if they hadn't paid for it, so that's a fascinating discovery. So this thing that was being given away free all of a sudden we would never be successful unless we charged money for it.
Because that's what our buyer wanted us to do. So we suddenly said, and you know, thanks to Ben here for the person who was originally smart enough to figure this out. Let's charge them a lot of money for this. And it was the thing that triggered the key success there. So interesting kind of thing to note there. Now what's happened and I think is exciting for people in this room here is, we found an amazingly clever new way to sell.
And that is essentially using open-source or freemium products to let our buyer comfortably do the selling to themselves, which is how they want things to work. They don't really like the salesperson in their living room at all. They'd much prefer the comfort of being able to test something out before they buy it. And so these are a really powerful strategies, particularly if you do a free product because you can then get the kind of viral adoption that JBoss got with the five million users that they had there.
So what I think is fascinating is that when you do this you need to recognize that you've now suddenly made due a product into your salesperson. And that starts to pose a few questions for us, which is, well wait a second. What does a salesperson do to close a deal? And how are we going get our product to do the same work that that salesperson used to do. And the answer to that is there's this really crucial thing that you want to be targeting, which is the wow moment. And you want to then be thinking about, "okay, how do I get my product to get that buyer to that wow moment as quickly as possible, and with as little friction as possible."
So let's start by defining what is a wow moment. And there are two types of wow moments. I mean there may be more here, but I think of a mini-wow moment as being, the developer got something really cool that they were taken by surprise and they put a big smile on their face and they said wow, that was great. But it wasn't enough to get then to buy the thing yet.
It was just a cool motivator to keep going and get to something further. And then I think the full wow is really worth understanding and that your buyer's going tell you is when have they seen enough proof that this thing is truly going meet their needs and is actually great enough value for money that they're not going ask the question if $10,000 is too much money for it at all.
So understanding that is a great starting point here. What do you have to get to there with the wow moment. So now we're going look at time to wow. How many steps are there? And I really recommend one of the most fun things that I've had happen to me is that every time I walk into a company, I believe I've been able to successfully improve their funnel. And the way I do it is really simple. I ask them to draw their funnel steps on the white board.
And it's shocking how few people can actually do it. They have disagreement, they all are certain that they know exactly what they are. But as they start writing them up, their brains start firing and they come up with the idea of how to fix their funnel. I'm not their genius at all. I just simply made them do the brainstorming work that they weren't doing previously.
And the diagram is the key to that.
So by writing down the steps here and looking at things like, where is your greatest friction, you can get some interesting breakthroughs.
So what we're wanting to do here is remove steps and remove friction. How many of you guys know of GraphQL and the company Meteor that has produced this new product Apollo? If you do know just raise your hands for me. So quite a lot of people don't by the sound of it. So GraphQL is this cool thing that Facebook came out with that is a really powerful way to get data into your client side without you having to write code. You can just write a declarative statement and put it next door to React component and all the data will be fetched for you.
All the hard work will be done for you. So let's look at the journey that happens here. Start by looking at what is the wow moment that's needed to get somebody to buy into deploying GraphQL, which is how Apollo will make their money. Well the mini wow moment is when a frontend developer realizes "holy cow, I can write my frontend way quicker by just writing these declarative statements here to get the data that I need and just the data that I need into my frontend".
Because those rest APIs that my damn backend guys have given me, they are not at all well matched to what I need. They're giving way too much data and bad response times, et cetera. So that's a mini wow moment, but the real key wow moment here is when is the CTO able to see that they can expose their data via GraphQL and access it in three different types of clients. Web, iOS and Android.
And really quickly build new frontend applications around that. So let me quickly take you through the buyer's journey here. So imagine you're a React frontend developer. The first thing they have to overcome is validate that it's really easy for you to connect your component to GraphQL. Turns out that's very simple to do. You just have to show them how few lines of code there is and many people now believe that GraphQL is easy on the frontend.
However, there's a very big perception right now that it's a big problem for Apollo to overcome, which is everybody thinks it's really hard to build a GraphQL server on the back end that delivers that data. And the frontend guys are not in charge of the backend. That's a different group of people and there's a big problem in your buying cycle if the person you're trying to work with has to go and deal with another person.
That's a lot of friction when you've got to go and involve another person in the trial. So ultimately the really interesting thing here is that the trial is a lot of friction here. And let me take you through why there's so much friction in the trial. The trial involves three hard steps. First one is you've got a set up a GraphQL server which takes a lot of code, and I'll show you why in a second.
The second thing is, if you want to connect an iOS app to that service, you've got to deploy it in some kind of a web environment. It could be Heroku or whatever. Then you're going create your component, which is easy to do. And then last you've got to find a way to demo React and React Native in iOS and Android as well as web, to really kill the power of what this thing can do in terms of creating new apps.
So let me take you through the friction in just the first two steps there. If you were a developer and you wanted to set up a new service, I'm not asking you to read these things, but there are a lot of steps here. This is just really painful and a lot of friction and a lot of time involved here. So I have to take my hat off to somebody who's in this room. Sashka, where are you?
He's behind the table and put your hand up again so everybody can see you. Because he is the genius who came up with this particular breakthrough that I'm going demo to you. And I hope I don't butcher his demo, because I am not the guy who's really an expert at this. So I want to show you what he did to remove all of those steps. So I'm going click on the first URL here. And what this URL does is it takes me to Launchpad.
And Launchpad is effectively like an online code editor where Sashka has pre-setup for you a sample, very simple, a GraphQL service. And in a GraphQL service, it turns that there are two simple things that you've got to do. You've got to construct the schema, which is what you want your data to look like. And then you've got to create resolvers that when their called actually deliver the answers to that particular question.
So you can see that this thing is live and running. So when I hit the go button on this code, here is the definition of the schema, which has one variable in it, which is the string. "Hello". Here's the resolver which returns hello world. And let me show you the cool thing about what Sashka's done here is that if I instead of world there I type in "Heavybit", as soon as I stop typing, I didn't hit return, the right-hand side recognizes that this thing has changed. It redeploys it, reruns it.
And bingo, we're off to the races and we've got "Hello Heavybit" appearing. So this is amazing.
We wrote a GraphQL service and it's deployed and it's available to us and we can hit the save button at the bottom and actually deploy that thing and turn it into a live running URL that is available to us.
So let me show you what again, happened when this got taken into a customer situation. One of the customers that they're working with is Ticketmaster. And the real key here for Ticketmaster was, it's not really interesting to see a little thing that says "Hello Heavybit", right? You're not going buy something because of that. You need to see your own data. So what was Sashka was able to do in front of the audience live, there were actually a list of the artists and then the events that they're doing in the schema.
And then it's the resolver, and here's the really important thing though is that with a tiny line of code Sashka was able to call the Ticketmaster event. And here's the actual line. Return fetch. And this a public URL that these guys have available. And so the answer to that, once we, let's just run this query quickly and you'll see that it will go and get a list of events for some specific favorite artists that he had hard coded.
One of them was Kansas which is an old rock band. I don't know why Sashka is interested in Kansas, but nevertheless he seems to have some strange musical tastes, and so you'll see that it returns a list of things and one of the fun things there is, it's got an image and if I'm capable of copying, which is going be slightly hard for me to do from here. Hopefully I've got the right text there.
Let's copy that and paste that into another tab here. We should see the image of this band called Kansas who are pretty old now. They've touring for like 30 years or something like that. So this is one of the results that he got out of the Ticketmaster API. So now we've got written in a matter of minutes here and deployed with a live URL a GraphQL service that connects to their data.
Now we need to finish that off by going one further step. So now when I type in that particular URL this takes me to an expo tool called Snack that some of you might be familiar with. It allows me to test React and React Native components. And again, I think the key thing was when this was shown to the Ticketmaster team and the CTO the buy-in was literally 100%.
They had hit the wow moment. So what was important in that, was number one recognizing that if your product's going be a salesperson, you have to really understand what things it's got to demonstrate to get that full wow moment for the buyer. And then analyze how much work it is for your buyer to get to the full wow moment and then redesign it to remove as many steps as possible in the process.
So one question that I think is really interesting is that many times people give the buyer a product, but there's no guidance for how to get from where they start. And so, you know, this is just a walk me screen but that's a product that you can add into yours that sometimes will guide them. But think about guiding them through the steps as well, because otherwise they may randomly never get to where you want them to get to.
And then another question that I've seen go wrong here is that you may have different buyer types who are going to evaluate your product and they may have different versions of what wow means to them. And that's the case, for example, with one of my other portfolio companies is CloudBees that have the Jenkins product. There are different people who care about different things there, so they have a different process to go through.
Another thing I've found really helpful is almost everybody traditionally has gone through a sign-up before you can do the trial. That's kind of a gatekeeper thing, give us your email. I think
It's a really good idea to give them the "wow moment" first before you ask for the email address.
So that is much more buyer friendly in terms of way of working. And here's another clever trick that I've seen work which is, are you guys familiar with Clearbit at all? It's a really cool data service.
So I work with that company doing one of these sessions here. And we came up with a recognition that their people doing a test of Clearbit need to see the way it works with SalesForce.com and they ran into a huge problem because nobody would give them the SalesForce.com login credentials. They didn't have the rights to do that. So they couldn't do this demo. They were getting blocked on that point. And the second thing they needed to do to make a sale was they needed to show how good their coverage was.
So if you got 10,000 contacts, how many of those 10,000 does Clearbit actually have interesting information to enrich on? So what we thought of, was a cool idea, was put in a Chrome extension. People are very happy to drop in a Chrome extension. It's not a particularly difficult or worrisome step. And via the Chrome extension, they were able to intercept the salesforce.com screen, add in the tab simulating how it would look if they were actually fully served up the product, and demonstrate precisely what value that data would add to any record in salesforce.
And then they could also run a report on a bunch of contacts. Bring up maybe 500 contacts and then instantaneously give you a rating of how many of those, what percentage, 30% did Clearbit have cover on. So I realize that's not a developer illustration, so I try to think of how maybe that might apply here. And Dana told me that there had been some company that had gotten blocked because they show off their cool AWS management tool, because people wouldn't give them the credentials to login to AWS.
So maybe here again this might be an interesting trick that you can use to get around some of those kinds of problems. One other thing that I showed in the demo of the Apollo thing, was where you have a situation where there's a dependency on somebody else. That's a big problem. So in their case, the frontend developer is typically getting blocked because they have to talk to the backend developer to get something done.
That's not good. You want to try to find a way to eliminate that step if you can, because in this particular case, these backend developers are perfectly comfortable with the Rest stuff that they've done, and they're not interested at all in helping. And they're busy. So you're into a long time frame before that gets resolved. So at the end of all of this to kind of summarize here. What I typically end up doing is finding a way to identify where's the worst blockage point in everybody's funnel, and then working on that.
And I apply this kind of biocentric thinking and I'm generally able to find a breakthrough way to solve that problem with people and it's been very, very successful for me over, you know, umpteen dozen years. As I mentioned, the JBoss thing was 13 years ago. Ah, it was 14 years ago, and I've been doing it at lots of other places since. And then what happens is,
As soon as you solve one blockage point it moves somewhere else.
So you're always playing whack-a-mole knocking from one place to the next in doing that. So what you need to have is a team and the way things work today, I've found, typically is broken. So people have their head of sales, the head of marketing, the head of product, and these people do not get together to talk about the funnel. Maybe you are lucky and you've got a really good CEO entrepreneur who's actually a very good growth hacker mentality that's kind of encompassing in how to bring all these together.
But what I recommend you need to do is create a funnel team that meets regularly, could be once every two weeks, it could be once a month or so. And break down the silos. You've got to bring your product people in, because they're the most powerful people who can break this funnel problems down. They have the greatest value to contribute. To give things to your buyers there. And that team, the next trick that I've mentioned to you that's worked so well for me is just to diagram stuff.
The moment you put that diagram up there and start talking about where is the blockage point in this funnel, all the creative juices starts flowing.
And I've not had to, you know, as I say, I've created these breakthroughs. It's not me who created the breakthroughs, it was the people sitting in the room once I put the diagram up there that created the ideas there. So one final thought for you, this is just a kind of philosophy of mine personally is
I like to think of a customer as being like a bank account. If I'm going work with them, before I ask them to do anything for me, I feel like I need to deliver value to them first.
And so make a deposit with your customer before you make a withdrawal and I think you'll find that's an incredibly successful way to get your relationship with them off to a great start then. So that's all I wanted to cover today and hopefully one idea, if I'm successful in getting one single idea to have helped you guys, that would be great. But thank you so much for listening.
To my mind, the risk with free and open-source as well is that you have to come up with two great products. Your free product has to be fantastic to get any level of adoption and virality. And then you have a big challenge which you've now got to come up with a second great product as well. And there's a possible alternative, which is that you can use a rate limiter.
So Dropbox is a perfect example of that. You get two gigs for free and then you hit the trigger point where you get pushed into for pay but it's only one product. But I think a lot of companies go wrong because they are in this battle where they're constantly worrying about how do de-feature my free product so it doesn't cannibalize my for-pay product. And they end up with kind of a half and half where the free product isn't good enough to really be successful, doesn't get virality and gets, you know even if it's open source you'll find your community starts competing against your for pay product with you.
And then I think if you can figure out how to put enough in there, the second challenge for you is how you come up with something truly compelling that is truly strong enough to get them to actually pay out money after they've become for free. I think one of the big lessons at JBoss was that don't expect everybody to buy. We only got, I think in the end, probably 5% conversion, and not while we were there, when we got 65 million we were probably only like one and a half percent or two.
And we were very happy with that because we were growing like crazy and we didn't need the rest of them to convert. We had to recognize that some people were there. They were doing a brilliant job for us of telling everybody else about our product. So don't try to convert everybody. Just recognize that some are qualified to convert. So that's a few thoughts on the subject. Hopefully useful.
First of all, I think you want to collect as many people's contact information as you possibly can do. So even though they're not going buy from you, it is very good for you to be able to have a dialog with them, to tell them about the new version or tell them about an event that you're holding. Because they're your viral salespeople, effectively helping you get your message out and taking the place of traditionally expensive marketing for you.
So once you've got them in there, now you've got this huge problem. 10,000 leads a month. How many marketers are in this room that have ever had to deal with 10,000 leads a month? So you know what I'm talking about. That's a big problem, right? You can't hand your salespeople 10,000 leads and expect them to call those. The salespeople cost a fortune, so your second question was really, really valid here.
I had nearly invested in Eloqua. And this is way before Marketo and HubSpot and all these other products came out. And one of the things that I was able to do was help introduce the Eloqua guys to JBoss and we built, I think, the world's very first lead scoring system. Eloqua didn't even know about lead scoring. We talked them into it, because we were the first company that actually had this huge problem of needing to qualify.
And so that was really a simple technique in those days. These days you can buy much more sophisticated software that actually does really artificial intelligence-based lead scoring, to help you determine which buyers are really qualified. And those are the ones that you pass through to your sales organization. And you get better and smarter and smarter about it. So a visit to the pricing page or a hands up request to have a salesperson call me, those are like the best indicators that they score high. But there are other indicators that you can use there as well.
What is that buyer's journey for your particular product? So I think in the case of Apollo, the most important step was that they had to get the developer to go and get in front of the CTO. We're still early in pioneering this whole thing, but the art is to get your developer prepped with the demo that they can take to their CTO, that you know is going knock the CTO's socks off. That happens to be the specific sales process, buying process as well, that works for Apollo.
But in the case of Trello, I don't know the product well enough to comment, but it's quite possible that the very first thing that they needed to do is proliferate that product and get multiple users, because without multiple users there's no real benefit to a tool like that. So that's the first step, and then the second thing is that you have a salesperson recognize in the database, that the lead scoring thing is really high on this company, because they've got 150 people using it.
So the salesperson perhaps calls in here or maybe calls into one of their champion users and says, tell me about who's the person who would actually make a buying decision and help me with an intro to them, and you maybe help that person, give them the presentation that they need to make to that person with the checkbook to, to get there.
Yeah, I think the thing that I've been thinking during these questions is, for us, what we do is, we treat the people who get excited about the technology and the people who are making the purchase as separate targets, like separate people to convince? And so we're trying really hard not to run into a problem where we have to decide like, "okay, we have to have a broken open-source thing and then a really great paid thing, because we just have two totally different things".
One of which is designed to get developers excited and then other stuff which is designed to help you convince your CTO to buy things, and then a third thing, which is the thing that they actually buy. So we don't lose anything by making the open-source technology better, it just gets people more excited. And then the thing that they end up buying in the end is just a different product entirely.
Yeah, I mean I think that it's a big challenge for anybody who's doing open-sources. You really want to be thinking about ideally one of these tiered schemes, where they automatically trip a point and then it's really not open-source and free. It's a freemium type of a thing. Or alternatively, a very different product that doesn't in any way compete with, that offers a truly different value.
And one possible way to test for that though, is to actually say, look, our free support is limited to a particular type, which is all electronic, no phone, and certain hours of the day, and if you want email support and actually to be able to talk to somebody in certain response times, well we've got different tiering of the pricing of the product. And that was one of the options.
You know, one of the big challenges at JBoss was that certain customers, the main base price was only $10,000 a year, but we had certain customers, GE in particular, I think, was the first one who paid us over a million dollars. How the hell do you get the pricing to scale from 10K up to a million dollars? So we had a huge issue of how to create scalable pricing axes, so that when GE walked in the door we could crank that price up for them.
So one of the axes was, while you got two hour support seven days a week. And you have named individuals and all sorts of fancy things that we came up with and we were inventing all sorts of stuff to create million dollar price points out of that 10K skew there.
I will tell you one key thing about pricing though, which is if any of you have read my blog on SaaS Metrics and how to deal with churn, you may not be at that stage in your company yet where this matters for you.
But I will tell you that it's absolutely crucial that you find a way to have pricing that allows you to expand your customers, because you will get some customers who churn. There's no possible way of avoiding that. But you can get whet I call negative churn. A negative churn happens, let's say you've got 20 customers at the beginning of the year and only 10 left at the end of the year. Negative churn happens with the 10 who are left who will have expanded their usage more than the dollars that you lost from the 10 that walked out the door.
And so it's really crucial to have variable pricing. We got this completely wrong at HubSpot in the early days. We had one fixed price for everything and we had no expansion revenue. And we had quite high churn because they sold to SNBs.
So this was one of the biggest discoveries there a long time back was, we had to come up with these variable pricing axes to create that automatic growth in the customer base. So that's one thing I can tell you about pricing that's super-important in a recurring revenue model.
One of my other portfolio companies is called Salsify. And what they do, is they sit between brands and e-commerce retailers and they deal with the product information that's needed to make a decent listing on the e-commerce side. And it turns out it's a real pain in the backside. The brands don't have a good system for tracking and building that information.
And then they find that when you go to Amazon, Amazon wants it in their format. When you go to Target, they want it in a totally different format. When you go to Walmart, totally different format. So Salsify wants to sit on both sides and automatically help you move information. So you can bring your products really quickly into a new retailer which leads to straightaway sales.
Update them with new product information, et cetera. So they created a free trial and it didn't work at all well. And the reason was, this is a very complex product and they had no guidance in it. So that a buyer arrived in this thing and wow it's complicated user interface and nothing to tell them what to do. And the worst part was that even if they did get help with knowing what to do, the product was useless because it had no information, no product information in it.
And this is one of the worst problems with free trials is that there's no data in the trial to actually use the darn thing. So what they first thought of is, okay we can put some sample data and they can around with that. But as we found out with Sashka doing this demo with Ticketmaster, it does not create a wow moment until Ticketmaster sees their data going up there.
So what they then figured out is, "hey wait a second, these guys have their information from other retailers. We can scrape it. It's not going be in great shape, but let's at least prepopulate this thing by scraping a whole bunch of websites and having it available". So as you walk into the product, your product info is in there. Not great, so immediately you're reacting with pain and there's a trigger to buy their product.
Sheez we need to fix this, this image is terrible, that description's wrong, that thing's wrongly categorized. So then it turns out that still wasn't a wow moment. Because then you just kind of know that the product's able to do stuff. The first thing it does is if it can publish one of your existing channels, that's sort of interesting. But when it publishes to a brand new channel that you've never had you're products in before, that's a wow moment, because that creates sales.
So that kind of turned out to be an interesting challenge because they needed to get people who actually have the ability to accept that data and it turned out there was one easy one that they could hit and that was Google. Google's not a true channel but they have this product search thing that they were trying to build and they built an API that Salsify knew exactly how to publish to.
And they could prove that if you put your product into Google you would get better search hits and you would immediately increase sales.
So they delivered to you your data in this product with the ability to hit that button to publish straight to Google, that was a new channel that you weren't in previously. And bang, that was an example of a really cool wow moment that got sales immediately for a customer.
So it's any one, I mean I haved so many stories of these successes that we've had using this technique here, that I could kind of go for ages telling you about them.
To my mind I think one of the best things you can do as a startup company is focus, even though in the long run you know you may want to not be focused, but the very starting points. If it's possible, if you have both enterprise and SNB I would not recommend to any start up to try to tackle both of those at the same time. I think generally speaking, the risks you run are that your messaging that you need for the one and the product that you need for the one are actually different to the other.
And you're better off picking one to focus on first. But in certain circumstances, like possibly the one you're describing, you don't have that option. You have to deal with two different people. And I think you really want to take the trouble to find out exactly what each persona cares about. You know use that question set that I flipped through quickly because it was just so full of dense questions on it to learn who they are, what they care about.
Build a group of them into like your buyer consulting. That's the wrong word for it, but partners that are willing to be your customer advisory board. Meet with them regularly and ask them the question. What's on your mind? What things matter to you? What does your boss expect of you these days? What reports do you use to do your job and show to your boss? And just that separate tackling of each one of them and building this separate process of how they buy, what things matter in their lives.
And then when you have your website, you unfortunately need to try to find a way to get them to get them to self identify when they arrive on the website. So you ask them are you a CTO? You know, interested to finding out how you can get the best technical thing? Or are you the business mind who really wants to see, you know, what's the financial returns on this thing and what are other customers saying about their usage on it?
So you have different paths that you plot out for how they navigate through your website. And it's unlikely that, for example, the business mind's going ever look at the trial. They may look at the end part of the product but they won't necessarily do the trial. This other person who's perhaps your champion will do that demo. But no shortcuts than that. Than doing both buyer journeys there. Thank you.