443: Airbrake with Göran Sandahl

Hello UK Giant Robots listeners! Our next event allows you to hear from and connect with both Founders and Investors on all things Fundraising. The event will be 1 part panel discussion and 1 part breakout sessions. We hope you can make it! Register today at: tbot.io/fundraising-uk Göran Sandahl is Director of Growth at Airbrake LogicMonitor, frictionless error monitoring and performance insights for your entire app stack. Victoria talks to Göran about having a product-led growth engine, how Airbrake can help developers identify and solve errors and bugs in applications, and developing a product geared towards a specific segment of the market. Airbrake Follow Airbrake on Twitter, GitHub, Facebook, YouTube, or LinkedIn. Follow Göran on Twitter or LinkedIn. Follow thoughtbot on Twitter or LinkedIn. Become a Sponsor of Giant Robots! Transcript: VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Göran Sandahl, Director of Growth at Airbrake LogicMonitor, frictionless error monitoring and performance insights for your entire app stack. Göran, thank you for joining us. GÖRAN: Thanks for having me. VICTORIA: Wonderful. So just tell me a little bit more about Airbrake and how it all got started. GÖRAN: So Airbrake is, as you said, an error and performance monitoring tool. It was actually, funnily enough, started as a side-project within thoughtbot. So it's a little bit full circle here joining this podcast here. But I'm a recent addition to Airbrake, so I don't know the details of the time when they started over ten years ago. So talking about Airbrake and the journey since then, lots of things have happened with Airbrake. It has gone through multiple acquisitions since then, both from industry players on the infrastructure side to various venture capital investors buying the company. And now Airbrake is owned by LogicMonitor, who bought Airbrake somewhat like a year ago. And it focuses exclusively on the developer audience for LogicMonitor. And I lead growth, so I work with our growth team. We have a product-led growth engine. So we don't do a lot of traditional sales or anything like that, so a lot of it is word of mouth. And this is something that drew me to Airbrake was its strong kind of grassroots movement in Ruby and other web and application languages. So that's what I know about Airbrake's early days, which isn't a lot. VICTORIA: Right. It was the very first exception monitoring service in the world. And we grew it to have three people working full time on it. And then, like what you said, it was sold to someone else who went on to continue to grow it. And it has been through several acquisitions. And from your perspective today, where is this service originally called Hoptoad [laughs], and then now it's Airbrake? And what kind of scale are you seeing? What are your customers like today? GÖRAN: Obviously, I don't know exactly how the product looked like back then. But a lot of it, I think, has stayed the same. It focuses on simple error monitoring, simple performance monitoring, and simple deployment tracking. So it's pretty much the same focus I believe in the product. This is what makes it stand out still today. We can talk about observability, and happy to do that. This is my third company that I've been working for as a monitoring company, so I know fairly a bit about it. Airbrake today is heavily focused on...we focus on what we call lean dev teams. We focus on the teams that try to move a little bit quicker, maybe than what they may, doesn't necessarily have the backup of an ops team or a DevOps team. So we really focus on building a product that is fully self-service that you can get started within a minute on your own. So that implies good UX, good documentation, and also that we can meet our users where they are. So we're focusing today on things like community building and those things for supporting our users. So we have lots of customers, really good brand names. First and foremost, super interesting stories from many of our customers who navigate that art of building product quickly. VICTORIA: That's great. I like that you phrased it as your user experience, which is your development teams, right? And do you have more of a perspective around the developer experience and how to capture that and really create something that's useful when you're delivering in those high-velocity environments? GÖRAN: As I said, I've been working for three monitoring companies. The first one I founded was 12 years ago. We built a product that we tried to coin the market called algorithmic monitoring, that later turned into something called AIOps. Yeah, there are a lot of buzzwords around that, applying AI to identifying problems in software. We were really early on that. One thing that we learned from that journey...we ended up selling that company to LogicMonitor, which is why I'm eventually here. What we learned then is that you can have a really good monitoring product, but ultimately, the people that fix the problem that gets discovered is the most important person for a monitoring tool to get into true effectiveness. So when I came across Airbrake, when they were acquired by LogicMonitor, and I had the opportunity to join, that's what drove me to decide to join. It's really that simplicity in terms of I think there are two schools, right? Either you promote a tool that all your software engineers should use, and you try to build centralized, structured processes around that. You make the template thing and things like that so that everybody can get up and running really quickly with monitoring. Or you take the approach of something like Airbrake, where it's built to be easy. If you know the language, if you know the code, then you know how to basically instrument it. And these features are simple enough to get going on your own. So that's the path that Airbrake is on. So it's built to be simple from the gate, so to speak. Now, Airbrake and monitoring and observability is a complicated problem when you have software issues. They're not always easy to diagnose or get to the root cause of. So there's a lot of struggle for users to unwind the bugs and actually fix them. But we try to do the best to provide enough context so they can take the next step. VICTORIA: And maybe you have an example or something to illustrate how that tool can help developers identify and solve those errors and bugs in the application. GÖRAN: All software has issues, right? There are bugs in all kinds of software. I've always been fascinated with something called latent bugs, or dark death is another framing of it, which is essentially the bugs that are hidden in your code. And when we have an outage, something triggers that bug to happen, but that bug was there. So if we think about it like that, that all of our software, all the code we run, all the commits we do is probably adding a lot of value, but they're also adding fragility or potential for problems, then you need to be really good at identifying when those bugs get activated. And sometimes, actually in, the majority of times...so that's why you need error monitoring, right? Just the ability to see that there is an error, there's a new error in production or in our staging environment, or wherever it might be. So that's error monitoring. It turns out about 80% of outages are self-inflicted in a way. They're caused by the changes when we build software or when we reconfigure things. And 80% that means that you need to be able to track changes really well. So you need to understand how and when changes happen so you can understand if what you did worked or didn't, so that's why we have deployment tracking, to be able to correlate those errors with the release, the commit, the line of code you added to the codebase. And then, of course, performance monitoring which is the ability to see where you have bottlenecks, which is not maybe bugs but where you have poor performance or poor experience for users. And it could be in a shopping cart checkout job. It could also be a scheduled cron job that's supposed to clean up stuff that is late. It could be just a rendering time of something that is longer than usual, and you just want to be aware of it. So that is kind of performance monitoring. So those are the three main focuses for us as a product. We like to believe that it is easy to get going within a couple of minutes. And that's what we're kind of focusing on providing. VICTORIA: Yeah, that makes a lot of sense to me. And your tool is able to just spin up quickly, be able to quickly get that insight into what's happening as you're deploying code and as you're pushing changes to production. Do you call that all observability? Or, in your mind, what is observability? And what are the really key things that you think that all developers should be watching? GÖRAN: That is a good question. Part of what fascinates me about the Airbrake userbase and what I've got to learn about Ruby and some of those languages which were a little bit foreign to me as a backend engineer, like an algorithm junkie, so to speak...so what fascinates me is how little monitoring is typically done by many teams that's working on web applications. So coming from the infrastructure monitoring side, that's where this term observability grew. And you have these metrics, logs, and traces kind of triad. And every web application, every web browser has had tracing built in the developer console or the web browser. So some of these tools that are available now to infrastructure monitoring teams in the form of observability have been available to web developers for quite some time, so I don't necessarily think observability is a term that explains a lot for applications and web developers. But for infrastructure, more infrastructure-oriented teams where you have lots of microservices and things like that, we needed a term to explain the full range of capabilities we needed. But I'm not so sure we need the similar amount of complexity because there is a lot of complexity in those tools and lots of data. But I'm not so sure we need the same complexity when speaking about monitoring on slightly more lightweight applications and web apps. That said, we're starting to mimic a lot of the architectural paradigms of the infrastructure, such as microservices, in terms of micro frontends. So a lot of that complexity is entering into the web as well. So, who knows? [laughs] MIDROLL AD: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. VICTORIA: So the customer or clients for Airbrake are developers who are doing web applications and need that kind of just the information they need [chuckles] to be able to make sure their changes to code is not affecting the production and that your product is trending towards observability practices that might be a little overmatch to what you will need. GÖRAN: Yeah, that is what we're focusing on. But when you have a lot of customers and a lot of users, there's always this exotic, for us, exotic use cases. So I'm 100% sure there are really large customers that are using us in a more traditional DevOps fashion and not on web apps. I mean, we have support for most of the languages from Go to Python to .NET to Ruby. So there's nothing keeping Go developers from adopting something like Airbrake. But we do know that we're particularly strong within JavaScript and Ruby, and I think that speaks for the experience that it's easy to get going, et cetera, rather than something like Grafana or another more traditional observability tool that's a little bit out of reach maybe for the web or application developer. VICTORIA: So when you're developing your product towards this specific segment of the market, what other differences do you notice between who you're targeting or who you're expecting your customer to be versus the wider range of people you could be marketing this towards? GÖRAN: So I think everybody wants to go after the developer and the needs of the developer. This is, so to speak, trendy nowadays. And it's obvious because so much of the value and innovation happening is done [chuckles] in the editor. So it's natural that a lot of the focus is being placed there. We're focusing on where we're strong, and I think that's the best way to do it unless the market is small. And I see application development growing for the foreseeable future. I think we're seeing trends of things like no-code, or low-code, or whatever we choose to call it. The infrastructure is being abstracted more and more. So from that perspective, I think we have a good strategy for providing that simplicity that users come to expect when building modern apps today. We're pairing with other kinds of innovations on how you build code, basically from things like Vercel to Webflow to whatever it might be, right? VICTORIA: Right. And do you find that collaborative approach is more effective in business-to-business sales for this type of client? GÖRAN: We're very focused on this just try it kind of approach, so that's how we do most of our direct communications with our users. So we want to let the app speak for itself. And we believe that once usage happens, then additional needs will happen or will arise that we can maybe serve in other ways. So we do have a free tier, free forever free tier, so you can use Airbrake pretty much forever but in a small scale. And then, like normal, when you start adding colleagues or lots of errors and lots of projects, then you need to upgrade to a paid plan. And we're also launching some new tiers here in the foreseeable future as well. VICTORIA: Oh, tell me more about that. GÖRAN: As teams mature...I don't know if that's the right word, but at some point, a lot of these teams may want a little bit more structure when they do monitoring. So I mentioned that we're pretty much self-service, completely self-service. But at some point, when you start using a product a lot, you start to integrate it into your core processes. So new things start to matter, things like who did that change? Who reconfigured that? Who logged in the last time? Has anybody seen that thing? But also to things like payment things. The different issues that can arise change, right? VICTORIA: Mm-hmm. GÖRAN: So we're launching a pro tier in the future that will cater to a little bit more of the needs of the team that has grown into maybe having a manager that asks questions about how things are set up, et cetera, but also, where you can control teams and people a little bit better, where you can also control your costs a little bit. So one of the features is on-demand billing. So the more errors you pay on your tier...you can produce up to a certain set of errors and performance events, and if you go above that, you pay an on-demand fee. And there are some protections built in for that if you're on the pro plan and things like that. So it's about catering to growing needs of a little bit larger teams but still the team that wants to move fast. VICTORIA: Right. And I believe you said that you have plans to communicate and engage with the community, and that probably helps you understand some of those needs. And so what kind of plans do you have coming up that you'd like to share? GÖRAN: So one of the things we know is with all the Airbrake use, we probably have a lot of fans out there, but we might not have been the best to actually tap into that and serve that community. So we want to really invest in understanding, getting to know that community, and serving that in the best way we can. So we will see exactly which form that will take. But it starts with the basics, opening up a Slack community that we can allow users to join and ask questions or maybe hopefully get value out of their peers without talking to us maybe. But we can also serve them in various ways with support, et cetera. So it will start pretty basic, but I think it's a pretty standard playbook nowadays. But for us, it's really about we're genuinely...we think our users are awesome, and we would love to be able to share their stories and connect them with other peers. So I think that's the driving motivation. And then, of course, we have some data that also shows that it is a good investment in itself, that the stories our customers tell are much better than the stories we tell. So yeah, we're excited about that for sure. And it's connected to this bottoms up motion from where Airbrake grew from, that it grew as a solution that served the community really well. And we want to go back to those roots and be the best tool for that kind of user. VICTORIA: Oh, I love that. It sounds like a really great, full-circle journey for the product. And is there anything else you want to share about entrepreneurship and starting up products like this? What advice would you give to someone who had developed this type of product that served the community well and wanted to turn it into a product and a business? GÖRAN: So I think the community building is relatively new for us, so I'm not sure the advice there is so valuable. But in terms of entrepreneurship, I think this is one of the more important decisions you make as an entrepreneur or founder is how will you grow demand for your product and how will you distribute the product? And how will you ultimately monetize the product? And there are so many different ways. And depending on what your growth expectations are, you might be asked to go in one direction or another one. And my advice would be to really find product-market fit and that I think happens best by staying close to the end users, and then you can look at strategies for monetization, including direct sales or channel or, as Airbrake does, product-led freemium basically. But reach product-market fit first so you can decide with knowing how your product dynamics and adoption dynamics works, and let that influence the kind of strategy for the business strategy basically rather than the other way around. VICTORIA: Right. That makes sense. And then, if your product is geared towards developers, they're just like any other users. And you have to reach them and get their feedback and understand how the product fits into the market. GÖRAN: Yeah, exactly. VICTORIA: Yeah. Great. All right. Do you have any questions for me at this time? GÖRAN: Not really. It was a pleasure being on the podcast. I'm a fan so hope you can cover up my errors there. [laughter] VICTORIA: I think that if you want to go back and remove, we totally can. But are there any other major takeaways you want people to walk away with about Airbrake or, in general, about entrepreneurship? GÖRAN: That's about it, I think. VICTORIA: All right. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at [email protected]. And you can find me on Twitter at @victori_ousg. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.Special Guest: Göran Sandahl.Sponsored By:thoughtbot: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devopsSupport Giant Robots Smashing Into Other Giant Robots