James Smith - Baremetrics

This week I talk with James Smith of BugSnag, where they do application error monitoring. We talk about breaking computers as a kid, using open source as a way to get initial traction, marketing to developers, the role of data in decision making a bunch more. Hope you enjoy it!

Josh Pigford: Let’s jump in so I like to get the full story, where founders have been, how they got to where they are now, and so I guess we’ll start from there. So you’ve had your hand in a lot of different companies and OpenSource projects over the years and then most recently, before Bug Snag you were the CTO at Heyzap.

So I guess I’m curious, how did you get into computers and technology to begin with?

James: Yeah, for sure, well that’s going way back. That’s a good question.

So I think that my dad got me, I remember, one Christmas, my parents got me a computer. I think it was an IBM SX25 486 SX25 computer and basically they got it for us with a couple of games on it. I think we had Lemmings on there and a game called Micro Machines if you’ve ever played that one.

Josh: Classics.

James: Way back when I was a kid. It’s classic games, and that got me into computers in the first place, and then I broke it, and I took it apart and I put it back together again and discovered this thing called BASIC back in the day and I was like, wait, I can make this computer do things, to my dad’s horror. And I’m sure you hear this story with a lot of founders in the early, how did you get to building things.

Well, you get into building things by breaking things first.

Josh: For sure.

James: So I got this computer, I broke it, annoyed my brother because he wanted to just play Micro Machines on this computer. And then later on, I remember, I was quite fortunate in that I’m from London and we had cable internet very early on. And so we had the internet I think in ’96, which is a crazy long time ago now.

Josh: Wow, yeah.

James: And so at the time I remember, I think the main reason I got into building products rather than just breaking things and taking things apart was my friend and I used to play this game, Duke Nukem 3-D if you’ve ever played that game before.

Josh: Did it come for free on your computer or something? Or was it some free version or did you have …

James: I had the Shareware version, that there was like the first pack or whatever it was.

Josh: Yeah, yeah, right.

James: I played that to death, that was a great game.

But yeah, we figured out that you could, back in the day we were playing via modem which really ages me I guess now. You had to dial someone else’s computer up rather than going via TC/IP going through the internet as it is now. You had to dial up someone else’s phone line and then the modems would talk to each other.

The IPX player, I think it’s called on Duke Nukem and we were like, this sucks, we want to be on the internet and playing this kind of stuff. So we found this tool that pipes the IPX stuff via TC/IP and then we were like, why does nobody know about this?

So we made a little website, it was like, hey, if you want to play Duke Nukem over the internet rather than having to dial up your buddy’s modem here’s how you use it. And so loads of people, this was just a tool someone else built, it was a free tool, and so loads of people came to this website and were like, wow, this is crazy, people like this. And then I was like, wouldn’t it be cool if you could have a ladder. Wouldn’t it be cool if you could have a ranking of who’s winning the most games of Duke Nukem and I didn’t know how to do that, I just knew html back in the day, a bit of BASIC, and I was like wouldn’t it be cool if I could make this webpage update dynamically?

And again, I bet you hear this from a lot of the founders you speak with but that’s kind of what got me into building product. I was like, I want to be able to update what was on this website dynamically based on what people are inputting. It’s just simple, I think it was in Pearl back in the day. And I was like, oh, okay, that wasn’t so hard. And then once you get over that cliff, I’m sure you have that same reaction. Once you get over the cliff of, wow, I can control this, I can change this, this is something I’ve built, it unlocks in your mind, well I can probably build a lot of things now. This opens things up.

Josh: There’s a bit of a snowball affect there.

James: Exactly, yeah, it’s positive, it’s exciting. So we took that experience and just kept building ever since, and yeah, you mentioned Heyzap which is, you probably guessed from my accent I’m not from, my company is based in the Bay area, but I’m not from the Bay area.

Heyzap is the company that got me out to San Francisco, so before then I did a Math and CS degree at a college called Bath University in the UK on the west coast of England. Which is where I met my co-founder actually for Bug Zap. And then after that I did this default path of going into finance, and I went and worked for Bloomberg in London building trading platforms.

And I have a lot of respect for that company, I learned a lot there, quite entrepreneurial attitude at that company as well, but I was still working in finance, and finance is, no dis to anyone working in finance, but it wasn’t for me, it was a pretty soul destroying industry to work in.

A couple of old school friends of mine just got into the white combinator program. This was in, I guess, winter 2008, so December 2008, and they were building out, at the time, I think it was an embeddable widget for playing flash games on any website. The idea was, and this really dates this company as well now, because flash is completely non-existent these days.

Josh: Sure.

James: But the idea was that if you were a publication like New York Times or somewhere where you had content and you wanted to increase engagement, then the idea was you can embed a flash games widget at the bottom of your page to increase the time on site, and so I came out, I joined the company’s first employee straight out of, just graduated from the white com binary class, and then ended up building it into a decent sized company, pivoted about two or three times, as start ups tend to do, but yeah, that’s what really gave me the taste for start up life.

I’ve always been a builder, I’ve always built things in my life, but I was like, well actually what about building things for a greater good? What about building things to improve society or building things to make money as well.

Josh: Sure, sure.

James: At the fundamental level, so yeah, that’s what put me out here.

Josh: So how did you, so Heyzap, was it, so you mentioned the flash game thing. If I recall, so I used to do a bunch of design, consulting stuff, I went to school for design, and I’m 87% sure that I almost took a job at Heyzap doing UI design, so …

James: You know what? I’m going to have to look in my email inbox now. What a small world, that is crazy.

Josh: This would have been 2000 and, oh I don’t know, 9 or 10 or something like that? Maybe a little bit later than that.

James: Early, very early Heyzap then. That’s crazy.

Josh: Yeah. So yeah, small world.

So jumping back to actually to early days where you’re breaking your computers. Were your parents supportive of the breaking things apart and putting them back together and figuring out how things work, or were they kind of annoyed by that, or …

James: Yeah, my, I think they were, I wouldn’t say supportive. I think tolerant is probably a better word.

I remember my dad got really stressed out at one point. A few years later I had this, when we had a permanent internet connection because I don’t know if you remember back in the day, with dial up, if you only had one phone line …

Josh: That was it.

James: That was it, yeah, you had to toggle internet on and off, so we again, I was lucky enough to have, with the telephone service that we had, they would give you a second line for free.

So my dad was like, oh great, I can make phone calls now without having to listen to modem noises on the phone, and so we got this second line and I remember I think I was running a PHP web service and I was like, I wish I could host this myself. I don’t want to, I’m a kid, I don’t have money for hosting, but I’ve got some old parts from computers so I took a really old motherboard, some old components, installed I think red hot Debian on it and set up Apache on there and I was hosting a web server from a shoebox, literally a shoebox in a cupboard, and it was like an Ikea cupboard or something like that. I think I cut a hole in the back of the cupboard to put the cables through. And so my dad saw this and he was like, he came and basically did an oh sure, health and safety test. He was like, look, I support you building these things and I understand what you’re doing here but first off, you’re running a hot computer out of a shoebox, exactly.

And secondly, come and talk to me if you’re going to cut a hole in the back of my furniture. And I was just like, this will be cool, I’ll make this happen, I’ll build this thing.

So no, it was testing at some points.

Josh: Sure.

James: And I think if I was in his position I’d probably be a bit pissed off at that kind of stuff.

Josh: Sure.

James: But he was tolerant.

Josh: Were you into building other stuff or was it always technology, electronics based?

James: Yeah, I think, again this is probably like a product person mentality but I’ve always been into building things in general. I remember before I got into computers, I set up a little system, little server modems, I think I had an electronics kit that I got from this place called Maplan Electronics, which is kind of like a Radio Shack kind of place.

Josh: Yeah.

James: In the UK.

And I had a Servo kit and a bunch of wires and all that kind of stuff, and I made a little system to open and close my curtains in my bedroom. And it was like, Rue Goldberg machine level of connections and wires and cables, and yeah, I think I like the tangibility of building things. I like the fact that, I think at school I was, have you ever seen those toner robots that you can program that go left and right and straight ahead and that kind of stuff, they draw patterns.

Josh: Yeah, yeah, yeah.

James: So I forget what they’re called now but we had one of those at school and I think when you see the actions that you’re telling a machine or a system to do have tangible impacts, it kind of sparks that bug. So yeah, I’ve always been into building things.

Josh: Have you always been entrepreneurial, like obviously there’s the building side but sort of, not really the sales side, but wanting to make money from stuff, or has it always been product first?

James: Definitely product first, I think the entrepreneurial side of things I fell into.

I think that for Heyzap being the first employee there, even though I was CTO of that company and I was running the engineering team, I would go to conferences and I would go to events, so by default I ended up selling the product. And at bug Snag in particular, the customer of Bug Snag is me. Its’ technical individual contributors or technical leaders. And I’ve been in both roles.

If you’ve got a product that you’ve built and you love and you’ve built it for a particular reason to solve a particular problem, and your customer is basically the same persona as yourself, it kind of becomes a lot easier, it comes a lot more natural.

But yeah, I mean, when we started Bug Snag, Simon and I bootstrapped for the first, I think, nine months of the company. So I think that we both said that we had nine months of savings in the bank account, and I think I actually miscalculated. I think I only had six months of savings in the bank account, and San Francisco rent is not cheap.

Josh: Nope, that’s not something that you can accidentally be like, oh, I underestimated that by three months.

James: Exactly, but it … I tell you what, it kind of framed the business for us. I’m a builder, I like products and product first, but if you go to your customers and say what would you like, they will give you a different answer if you say what would you pay for, and so framing, I mean, this is your business, you know this really well but framing around what would you pay for was such an empowering experience for Simon and I because we had money ticking down. We, I think we ended up hitting profitability when we were bootstrapping with about a month to spare in savings.

And so, it was forced entrepreneurialism. I think that, it really depends on how you define entrepreneurial behavior but most of the entrepreneurs that I know that I respect are product people first and commercial people second. You have to have both, obviously but yeah, I kind of fell into it that way.

Josh: Yeah, yeah. So let’s, I guess, how did Bug Snag come about? In my head, why another application error tracker, right? What was the impetus for …

James: Exactly.

So we, Simon and I were basically frustrated. So Simon is my co-founder, we met at college. I actually hired him to run my mobile team at Heyzap, I brought him out to the States to run one of my teams at Heyzap and we were sat in a pub one day talking about building software in general. And I’d been writing software at Bloomberg in Finance and then I also did a bit of embedded software during college and then also running Heyzap as a startup, I saw the same set of problems across all of these different industries and Simon said he saw the same thing.

So out of college, Simon was a software consultant, and so he would go and solve problems at large companies like Votify which is a big telecoms company or UK Defense industry and things like that. He would fly in, solve their problems, and fly out. And a lot of the time he’d be like, why didn’t you know that this was a problem? How did it take so long to figure out that this was broken?

We were in a pub one day recounting these stories and realized every single company that has software is screwed when it’s broken, and me being a product guy, I was like, I don’t think anyone’s solving this right. And, historically if you look back to when we started the company about four years ago, there was pretty much one player in the game at the time, which was a product that used to be called Hop Toad and now is called Air Break.

I’ve got to be respectful of the industry. They were the trailblazers but they were the first attempt at this. They were like, let’s give this a try. I think it was those guys and a company called Exceptional, they ended up merging together.

Josh: Which Exceptional was basically the previous incarnation of the guys at Intercom.

James: That’s right. Yeah, the founders of intercom originally built Exceptional, that is correct. So they sold it to the Air Break guys and they merged together and they both were solving the same problem. They basically were saying, hey, rather than just digging into log files or the version 0.1 of error monitoring which is that when an error happens, email yourself, why don’t we just put it into a data base and show it on a dashboard, so that was phase one of this space.

I think that they paved the way for the servicide proactive error monitoring base, but what happened is at Heyzap we ended up building a mobile product and mobile error monitoring was terrible and the first foray for me into error monitoring as a product person was writing the agent writing the SDK which sent errors from Android applications into Air Break.

So I acutally did an OpenSource library that sent into Air Break’s API, and I got to the point where I was like, that was easy. That was the easy part, detecting and sending these errors. But the errors are presented in the wrong way, they’re grouped incorrectly, the alerting is not there. You can’t tell what the user impact was. So actually, initially we built this business because we were scratching an itch. There was nothing that was actively solving the problem in the way we thought it should be solved.

There was a couple of companies at the same time that sprung up around the time that we were building Bug Snag, Century being the main one. And yes, since then we’ve just been …

I remember day one when we set out to build the roadmap for Bug Snag, we had a two year roadmap that we wrote out and four years in now, we’ve done all that stuff but I think our roadmap is now even longer than that.

The deeper you go into this the more you realize that the problems …

Josh: Are much bigger.

James: Exactly. There’s the basics of I’ve got a small PHP app or Ruby app or whatever, and I just want to know when every crash happens, that’s the easy part. But what we’re finding is when you go into larger companies like Air BnB or Pandora, these kinds of companies, is the problems are very different in scale.

I always say this to people, it’s very easy to know that you’ve got errors, it’s very hard to actually fix them and do something about them. And so the problem space has shifted, rather than say here’s a list of all of the errors that we have, which is the easy problem, it’s now how do you focus on the errors that matter and how do you proactively deliver fixes to the most widely affected customers or widely affected bugs.

So yeah, it’s interesting how solving the same problem, even within the realm of error monitoring, the problems change inside of that space.

Josh: And I mean, I think that’s the case, I feel like the past, I don’t know, five maybe even ten years of the web and just building software has … the tools are so, the barrier to entry is so low that for a long time, everybody’s just been building stuff as fast as they can, but then what happens is, you realize that just having the data in and of itself is, well can be useful, for the most part you can’t do anything with it, right?

That’s the same way with us with Bare Metrics, it’s like we can tell you numbers all day, but so what? What are you going to do with it? And that’s the hard part.

James: You’ve nailed it. You know what, actually? This reminds me, so Simon and I, our first purchase as a company, as an Inc. incorporated business was to buy a white board off of Craig’s list so that we could write down ideas and stuff in our bedroom/office that we had. And we wrote down, I think four things on that whiteboard, and the first one on the list was answers instead of data, and this is exactly, I think there’s plenty of tools out there that’ll give you data, but that’s not helpful if you’re trying to solve problems and prioritize.

So literally, one of our founding principles was answers instead of data. Can we deliver you one step further or ten steps further than just a log file or a list of problems.

Yeah, it’s true, anyone in software is solving the same problem right now with that.

Josh: For sure. So what, obviously you guys have decided to build this application error tracker but helping people make more sense of it. What role prior to Bug Snag, I know you were pretty heavily involved with doing OpenSource stuff …

James: Yes.

Josh: So what role did all of the previous OpenSource stuff play into the success of Bug Snag?

James: That’s a great question. I think that OpenSource building library is, that’s what I used to do in OpenSource land and I still do these days is to build libraries.

And the idea was that, hey I’ve solved this problem, this problem is not a problem that’s unique to me, I’m going to clean it up, extract it, and share it with everyone else. And so a cool part of Bug Snag is our SDK, is our libraries that detect these crashes and report them and so when we set out to build Bug Snag a lot of tools out in the space that do error monitoring, especially on the mobile side which is one of our biggest growth areas at the moment, don’t share the source code for their error monitoring solution.

A couple of them out there, there’s CrashtheLinks and Aptelligent, both of them have closed source error monitoring SDKs and it didn’t even strike me to do that when we built the business. It was for me, that’s not the secret sauce, that’s not what we’re selling to our customers, we’re selling the experience of finding and fixing quicker. We’re not selling an SDK, and so yeah, by having this experience in OpenSource and building libraries, I think it taught me two things.

Number one it helped me understand the value of doing that, right? So people can see behind the curtain when you build things in open source land. So for example, in our Android library that detects crashes on Android applications, I think it was I probably can’t say the company name, one of our big customers on consumer mobile side, they evaluated all the competitors and they said, hey we went with you because you have all these opensource libraries because we want to contribute to them and we want to see what you’re building under the hood.

For me that was just a default, that is how I operate. And it was really, really empowering to see that our customers thought the same thing. I think the second thing is there’s no cheat codes, there’s no source cuts when you’re working in the Opensource. You’re working in the open, and so you have to think about, does this library feel appropriate to the community I am building for.

You might have a guiding set of principles for error monitoring libraries, but the one that you build for Ruby probably has to feel a little bit different to the one you built for Android, probably has to feel a little bit different from the one you built for Python. And if you build the OpenSource way and you share all of that code and that interface with your customers, you can’t hide.

Python community is a good example here, so there’s this concept of being pythonic which people take pride in the python community. I agree with this as well, it’s my background. I came from the python community a while ago. That is if your code is written in a pythonic way, software developers are more likely to have respect for your library and therefor adopt it into their code base.

So yeah, I think they are kind of the main things that I took from my open source background. I also think that building libraries for me, and building SDK’s is very much like building a product. You’re building, it’s a user experience. A library is just a set of user interfaces, it just so happens that they’re functions and classes rather than visual interfaces. So I think that gave me a healthy respect for product building as well.

Josh: Do you feel like the previous open source work helps you get initial customers or is kind of irrelevant?

James: It kind of depends so I tend to work in whatever language that I’m working in at the moment, so I had two big open source projects, one or two JavaScript plugins that are very dated these days but query based and one big Android library that I built which was HDP Cline in Android.

And the thing is for Bug Snag, because we’re cross platform, we support error monitoring in pretty much any platform, mobile, desktop browser, whatever you’re using. Having expertise in Android land meant that I was able to talk a little bit at Android conferences but that was it, really. It didn’t give me any credibility in any of the other platforms.

But I do remember I think, when we went to Air BnB for the first time to show them the product, they’re one of our customers, one of the guys there was like, ah, I used to use your http library, and it’s kind of funny because when you write opensource software I feel like you’re just doing it behind the keyboard and yeah, you might have a lot of stars on GetHub, or people forking your product on GetHub, but meeting someone in real life who has used your product before is such a different experience, it’s kind of exciting.

Yeah, I think in that situation it did give me a little bit more credibility. But not for any of the other platforms, I wish it did.

Josh: I got you. So there’s obviously an abundance of developer tools, just in general, just error logging or anything like that, but there’s basically an infinite number of tools at a developers disposal, so as a developer yourself, how do you keep from both I guess getting overwhelmed by the tools at your disposal, and also not get distracted, like, this random tool is going to solve all my problems.

How do you keep yourself focused on only using the tools that really make a big difference?

James: That’s a really good question. I talk about this a lot with my team. I don’t know if this comes with age, because I’ve been coding for a really long time now and tool selection has been part of my job for a really long time but I’ve gone very, very pragmatic these days. I think that, it used to be, the way I learned how to build software in the first place is that I would try all of the latest and greatest new software and I’d build tons of side projects and play around with it.

Literally, just yesterday, I was playing around with a tool called Roll Up which is a JavaScript bundling system that is sort of fighting with Web Pack at the moment. And just on little side project that I was playing around with, but when it comes to building and choosing tools for work, for Bug Snag, for a day to day, very much err on the side of being a pragmatist, so honestly these days I don’t have a lot of say in the tool selection. That’s normally my co-founder or the engineering teams. But if anyone asked me for advice on this I’ll say, what’s the thing that’s the most popular tool or the tool that is stable, yet trending up.

So when we picked a JavaScript framework for our dashboard. It wasn’t like, let’s pick the coolest new JavaScript framework. It was like, what’s the best supported, are there big companies using it? Is the tool chain quality, high quality? All that kind of stuff.

So yeah, all of this leads to what’s pragmatism these days, but I think that’s the way to do it. I think if you play around with the bleeding edge on side projects, but then stick to the pragmatic approach for production, if that makes sense. I think you can end up with the best of both worlds, and I think that that’s true of libraries as well as tools and services that you’re using.

I mean, one of the things that my co-founder and I talk about all the time is how do we choose software? And a lot of the time it’s by reputation. Word of mouth, I don’t think is a sustainable billion dollar business model, but you know what? It gets you great customers and I pick software by what people are talking about on Twitter or in Slack groups that I’m in. So that for me is another aspect.

Pragmatism plus social proof, I guess.

Josh: Yeah, I think it’s easy, especially when you’re earlier days of building a company, or if you’re say a first time entrepreneur or something like that. The feeling or the assumption that the next tool is going to somehow solve some big problem for you, when most of the time, tools themselves just optimize some given habit or workflow, right? They rarely actually change things in a big way.

Like if you’re not already …

James: Exactly, exactly, yeah. It’s, even I remember when we did a lot of work, we use a lot of elastic search at Bug Snag, and elastic search came out with a new version and we were like, “Look at the change log, this is gonna really fundamentally change the way that we build things”. It didn’t.

Josh: Right.

James: It’s the same, it’s the same piece of software. It does the same stuff. You build the value on top of the tools, I think is the maxim. The tools are the glue layer, yeah, you can reduce friction as you say, and you can get rid of some of the repetitive tasks, but yeah, I think you build value on top of tools.

Josh: Well, and I assume with you guys, if somebody shows up and they haven’t been doing any kind of error tracking or they have nothing in place for consistently improving their product, they probably aren’t going to be a really successful customer because that’s not something that they’ve been doing to begin with.

James: Yeah, it’s, do you know what, it’s actually, when we started this business, we wouldn’t even talk to people who hadn’t used some kind of error monitoring before.

Josh: Yeah,

James: But more often than not it’s the, that’s where we’re building a lot of value for the business. So if you’re a very small app, a very small shop that has a few errors being thrown here and there, then Bug Snag’s great but how much better is it than some kind of basic error monitoring, or emailing yourself every time a crash happens.

It’s better but is it going to provide a lot more value?

What happens is these days, especially on the client side on mobile on the browser monitoring and JavaScript monitoring, is that people know that they have a pain point but they don’t know how to solve it. I actually think that I talked to another founder recently about this.

When you first build a business that is solving a very specific problem, you assume that your market is going to be people that understand the problem. And after you gain maturity a little bit, it turns out, at least in our business, the bigger business, the billion dollar business is in people who know that there is a pain but they don’t understand that error monitoring for example is the way to solve it, and so we end up talking to a lot of people especially at conferences or events or meet ups and that kind of stuff who are like, we hear complaints from our customers that the app is broken and we just don’t know how.

And it’ll be very easy for me to think that everybody builds software in the same way that I build software and that you understand that error monitoring is an essential part of your business, and essential part of your stack but in reality, I think that probably 90% of the software teams out there know that there’s a pain point but really want help in understanding how the best way to solve that is.

So that’s been a really transformative understanding for me over the past few years is that assuming that everybody knows that they need a tool like this probably would have gotten us to a 50 million business but actually the bigger problem is hey, my stuff’s broken and I don’t know why. And I don’t know how to solve it.

Josh: So how do you approach that from the perspective of helping people know how to fix the problem that they don’t know … they can’t pinpoint, they don’t know how to verbalize what it is, they just know, hey there’s this bigger problem. But how do you come in and say, yeah, this error tracking or logging or surfacing problem that your customers are having … how do you educate them on that being the solution?

James: Yeah, good question. So really it’s around pain. I think that it depends who we’re talking to in the organization but really, they know that the pain exists, right? At the worst case, you’re going to be getting tweets or angry emails from your customers saying this is broken. So that’s never, as a software team or a product team, that’s never a good feeling, hearing customers complaining.

So at the most visceral side of things, when your customers complain you feel bad about things, so there’s that pain baked in already, but what we’re seeing more often than not is actually tangible outputs from that pain, so this, we started off this conversation by talking about how it’s never been easy to build software these days and customers have a choice these days, so what happens is when you are evaluating products …

One of our customers, I can’t say the name because they’ll be pissed off if I say it, but when they started using Bug Snag, they started using the product because they had a one star rating on the app store, the iTunes app store, and they were like, this sucks, this is embarrassing, people think that we’re a crappy product and so that was their tangible reason for getting error monitoring in place was that they were being rated in public on what the quality of their software.

This is becoming more and more prevalent these days with all of these different tools like Product Hunt or Stack Shed that allow you to compare apples to apples products and if people are saying well this one is crashing or this one is slow you’re not going to go with that product.

So rather than just having this word of mouth factor there’s almost like a tangible output of your product is crap, this is the quality rating of your product, and that, we can educate on how you can get from crap to good and that’s our job, helping people seeing that there is a path to solving this but actually the pain point is just, it’s already there in the minds of product teams.

Josh: So what’s been a key part of success for Bug Snag. Has there been any one thing that’s really changed the growth for you guys? Or two things, three things?

James: Yeah, I mean, one I think the focus is important. I think that we’ve always focused on the product experience, right? I think it would be very easy to continue adding new platforms that we support or adding jump when our customers say build this feature, but I think that having a holistic end to end product experience has been the thing that’s kept us going at a steady growth rate.

In terms of inflection points, we built, I think it was about 18 months ago. We changed the way that we modeled our data in order to allow people to filter and hone in on which errors matter the most, so we built this whole new dashboard. We call it dashboard 2 internally.

We built this whole new dashboard that allows you to better highlight the worst problems, and I think that’s been the biggest inflection point for us because like I said earlier, the problem of understanding which errors are happening in your low volume ruby on rails application is that I think we do a pretty good job of that but when you get into the problem space of I’m a client side or consumer application and I’m getting tens of millions of crash reports per day or hundreds of millions of crash reports per day, it becomes rather a signal to noise problem rather than a let’s just have a list of errors problem.

So we built this new dashboard and I think it was around about a year ago we started getting this good word of mouth in the consumer space. This is around about the time that Air BnB started using us, Pandora started using us and everyone was like, yeah, cool, error monitoring is a thing, but when I’ve got a hundred million errors a day and I’ve got a hundred developers working on this problem, how can I actually solve these problems?

So we made this big dashboard change and I think that that’s had quite a big impact on the business. It’s allowed us to not only solve problems for individual contributors and small dev teams but also move up market to the larger dev teams.

Josh: So was there a time, at the inverse of that, so you’ve had this good growth and there’s been a few things that have been these inflection points for you, but was there a time that you thought Bug Snag wouldn’t make it?

James: I think that the interesting thing about startups is in the SAS business, when you’re revenue generating SAS business, and this is the stuff that you talk about all the time and we talk about all the time as founders, is I feel like we could always make it. There’s always a way to keep going as a business. I think that we set high expectations for ourselves as a company, and sometimes we’re like, we’re not hitting those expectations, or we want to grow faster than we’re growing right now, and so the good news about being a revenue generating SAS business is that I think we’ve always been in a healthy financial state but the question is more how can we accelerate the business without burning through our money.

This is the, finding that sweet spot of growth, right? Finding the sweet spot of acceleration, I think, is the hard part. And I’ll tell you what the hardest thing is, people always ask me and I’m sure they ask you the same. What are the hardest things in the business?

I’ve always said hiring and pricing, and hiring being at the beginning of the company especially being British founders in the Bay area, we didn’t have a network to hire from, and so finding people to join the team was very difficult.

That kind of changes these days and that is, especially when I’m growing my exec team or my managers I’m like, how do I find people who buy into our philosophy and our vision as a business, but then on the pricing side I think that the closest we’ve ever got to being like, ut oh this is scary is when we went through a couple of pricing iterations, so when we started off the business we priced on an all you can eat model. We basically said you can have as much data, as many crash reports as you like, and we basically charged for the number of developers that were using the product.

So we changed our pricing model to double down on that at one point and it just didn’t feel right, and it didn’t work. It didn’t align with the value that we were providing. And so I think that, I don’t know, this seems to be the number one thing that comes up when I’m talking to other founders is that pricing you never get right, and I feel like that’s a freeing thing to understand. I think if I, as a software developer, I always feel like there’s a right answer to a problem and then you can refactor something so well that it’s the perfect answer, but when it comes to pricing, I read a good article, and this is your business as well so you can speak to this.

I feel like it’s very freeing when you understand that you’ll never get the pricing model perfect, and it’s an iterative experience rather than a this is the right answer experience.

But yeah, I think to come back to your question there, I never really thought that we weren’t going to make it, I sometimes felt like we’d made decisions that slowed down the growth of the business and especially around pricing. That’s one of those key areas.

Josh: It’s one of those things, like it’s a necessary part of it, right? Because if you didn’t’ try it then you wouldn’t know that it didn’t work and if you don’t know then you’ve potentially missed out on something that could have been a great thing, right?

James: Right, but it’s terrifying because pricing is such a, it’s still today, pricing is such an essential anchor to your business that, I want to change things, and …

Josh: Well and it makes people really emotional … yeah, sorry go ahead.

James: Exactly, exactly and do you remember Zen Desk actually a couple of years ago, they made a pricing change and didn’t grandfather people and that was this huge uproar around that, it was kind of crazy.

Josh: Yep. So wrapping things up here, what’s the future hold for Bug Snag, so you guys have a few thousand customers now? Three or four?

James: Yeah, we’re coming up to four thousand paying organizations using the product now.

Josh: So what’s the product look like for the next four thousand customers?

James: That’s a good question. I think the way we’ve got things set up right now is that we’ve done a really, really good job of telling engineers and engineering managers what’s broken and what the worst problems are and how to fix them. That’s our core of our business and I think that what we hear more and more from our customers is help us understand trends and patterns, help my CTO understand the state of the business. Or expanding things out to the other areas of the product team. One of the examples here is we had this customer who had a pilot program that they were working on, and I think it was a seven figure deal that they were working on and their dashboard broke during this pilot program, and the sales engineer and the salesperson didn’t know the dashboard broke and then they lost the sale.

So even a sales engineer or a sales rep in the company, if you’re a software business, everybody in the business cares about if the software is working or not. But the view that we’re presenting right now in our dashboards, which is here’s the list of errors and here’s the worst errors and here’s how to fix them, is not necessarily the right view to show to your sales team, or your customer support reps or even your CEO or your CTO.

So taking that core data that we’ve been collecting and highlighting and displaying it in ways that are more appropriate for the rest of the product organization. So this is almost a layering problem. I think not the really tough problems around data collection and crash detection and the underlying problems I think we’ve done a good job of solving, but making that data more accessible to the rest of your organization.

If you’re a business that’s built around software then everybody should care if it’s working or not and if you’re delivering a high quality.

So that’s kind of where we’re going.

Josh: Do you feel like that you’re just getting started? You’ve been doing it for a few years but at the same time, the problems, you still have a really big problem to solve, right?

James: Yeah, I say this all the time, I feel like this is not something where you’re like, it’s a solved problem now, we fixed it.

Josh: Right.

James: Every time you go deeper you uncover more and more problems and I think that the core aim, the core thing that we’re trying to solve is every time we go deeper we realize how we can do better, and how we can make it even a better experience for our customers and so that’s the most exciting thing, that’s what gets me out of bed in the morning. Is that there’s so many problems to solve, and so yeah, I wonder if this is true for every business but it certainly is true for our business.

Josh: There we have it, James Smith of Bug Snag.