About Bill Staples
Bill Staples is New Relic’s chief product officer, responsible for driving the company’s market-leading platform strategy and leading New Relic’s product management, engineering and design functions. Staples is an execution-focused product and engineering leader who loves to build and scale cloud-based businesses. Previously Staples was at Adobe, where he led the 1,500+ employee global engineering team behind Adobe’s market-leading Experience Cloud. Prior to Adobe, Staples spent 17 years at Microsoft, including his last role as vice president of Microsoft’s Application platform. At both Microsoft and Adobe, he successfully led transformative product, culture and technical innovation agendas, helping both companies expand multi-billion dollar cloud portfolios with developers and IT as the customer.


Links Referenced

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Bill Staples, New Relic’s chief product officer. Bill, welcome to the show.

Bill: Hey, thanks, Corey. It's great to be here.

Corey: So, before this, you were over at Adobe, and before that, you spent a brief 17-year stint at a small company called Microsoft.

Bill: Brief 17 years, that's correct. 

Corey: And now you've been at New Relic for a whopping six months, which in technology terms is close to about seven years, and given this whole pandemic era that we're living in, it kind of feels like it's close to that even without the joke.

Bill: It's true. I mean, starting to not feel like the newbie anymore here at New Relic. It's been an awesome six months though. Wow, what a ride.

Corey: New Relic is one of those interesting companies in that it feels like—at least from my perspective—that it's been around forever. It's a product that I used, at first begrudgingly, and then happily, and then I, you know, like any shiny thing, I wound up doing my raccoon act: seeing something shiny somewhere else and wandering off into the weeds. It was a really innovative product for a while and it seemed that there was nothing else in the market quite like it, and what surprised me was how long it seemed that that lasted.

Bill: Innovative product for a while, Corey. We got to get you back into New Relic. We need to win you back.

Corey: That's the problem, is I still have this mental model of New Relic being, “Oh, that's the thing you use for application performance monitoring.” “What is that?” “Well, it's a buzzword, but what it really means in practice is you open up a webpage, and it tells you why your website is loading slowly, or your application isn't working anymore.”

Bill: Right. 

Corey: That has always been the way I have contextualized New Relic. One of the things I see across the industry, though, is that we have these—you have companies like DataDog, for example, that have a monitoring strategy of, yes. Whatever it is that you want to do in the world of monitoring that you could possibly do, that's what they do. And every company, for whatever reason, in the monitoring space seems to start off as doing something that is niche. With New Relic, it was the application performance monitoring piece, a bunch of other companies are focusing on the log analytics piece, other folks are doing synthetics. There's the idea of the Pingdom style of ‘is the site up, or down, or not?’ but over time, it seems that every monitoring company tends to expand into a, I guess, a broad-based platform of, “Yes, we're going to start doing all of those things as well, and spreading out from the core competency.” Why is that?

Bill: Well, therein lies the problem. I mean, the reason for that is engineers choose the best tool for the job. And increasingly, the world has gotten more complex. Like the use case you described of, you deploy an application, you want to see what's going on, so you deploy New Relic agent, open up a webpage and see if it's running. That was so avant-garde, 2008. 

In today's world, you've got, increasingly, complexity at the infrastructure layer, with [00:04:39 finally], you know, virtual machines and infrastructure as a service from public cloud providers, but container-based systems like Kubernetes. You've got increasingly number of digital clients. Not just your mobile phone, but TVs, and other wearable computing, and in-store advertising, and all kinds of devices that deliver an experience to you. And then in between, you've got this explosion of distributed services, services calling services, inside your company and outside your company. And whether the application or, I guess, the customer experience is being served or not is not a simple question of is the application up and running, anymore. 

It's a question of all those layers working in concert to deliver the end-user experience. And you need a more sophisticated approach to understand is it up and running. And so increasingly, as you said, vendors and open-source systems are striving to expand the capability set to cover that full-stack view. And that's the journey New Relic’s been on, and that's what we're doing with the New Relic One platform and the announcements we made last week.

Corey: Credit where due, the entire world has changed. When you have a system running on a single computer. It's pretty easy. Is it up or down? At some point that narrative changes, and as we look into this world that we live in today of distributed applications, it's not, “Is the service up or is the service down?” It’s, “how down is it?” And there's a monitoring evolution. I still tend to live in a world where you could say, okay, users are complaining, what is the monitoring story? And my honest answer is, what do you mean, you just told me my monitoring story.

Bill: [laughs]. Yeah, exactly. And the other factor that's, I think, playing into it is developers, they want to move faster, they want to innovate, and with that complexity, the reluctance, sometimes, on behalf of companies to make changes in productions, and put lots of barriers to ensure that the customer experience doesn't regress, slows down innovation. So, it's as much about dealing with the complexity of the application and experience architecture, as it is the need to unlock developers, and moving fast, and being agile. Again, the only way you can do that as if you measure everything, understand how things are performing now, and then understand how they appear to be performing after, say, a deployment, with the ability to roll back if things aren't going well. So, both factors play a role in terms of companies looking harder at monitoring, both to deal with the complexity and to speed up or accelerate innovation.

Corey: I've got to say, one of the challenges I had with New Relic for a long time was, I was at a couple of different companies now where there was a fixed contract price for the year, things were great. And then, surprise apps do what they do: they get bigger because it turns out that your infrastructure footprint and, by extension, your AWS bill is never a function of how many customers you have, it's a function of how many engineers you employ. And it seems like there's a natural state of truth to that problem. And midway through the cycle, it was, oh, you have the salespeople reaching out with, hey, you're using more than we anticipated. Let's settle up again mid-cycle, which was just a terrible experience from where I sit. 

It's “oh, great. Now I get to go and tell my boss that A) I'm bad at managing vendors, B) I need to get more money,” which is always a compelling story to tell someone who has already done their own budget. And it basically led to a lot of unfortunate outcomes as a direct result. One thing that I find really interesting about what you folks are doing this year is you've completely revamped the pricing model in such a way that even your messaging around this is pretty much burning the boats behind you. What led to that? I think it's something I haven't seen much of in this industry for a while, and I'm actually really excited about it.

Bill: Yeah, I mean, you can disrupt lots of ways and we're disrupting ourselves from a messaging standpoint. I think I've said, “As the company who invented or created APM, we're going to be the ones to end it.” We no longer sell our APM product as an independent product anymore. With the announcements last week, we established a new packaging and pricing structure for the New Relic One platform, and the intention there is to just make it simpler for companies to adopt observability. The number one problem as I spoke with customers and their ability to take advantage of observability, is the complexity and the cost of it, frankly. 

They're left with this expanding set of tools and vendors to deal with, and even from New Relic. You could look at any of our competitors, it's the same thing. Up until a week ago, we offered a dozen-plus different products with lots of different pricing meters. And any VP of engineering or CIO, who looked at that and tried to predict, “Geez, how is my infrastructure going to expand across all of these dimensions, and how can I forecast the budget to ensure that my developers have the best tools and are covered in what they need to do?” It was almost impossible. So, it led exactly to what you described in terms of surprise bills. And that led then to companies deciding, hey, we can't afford to monitor everything. Let's only deploy agents on the most critical layers of the application stack.

Corey: Or you start sampling, like, okay, one in every 10 servers is going to have this on it. And that gives us a rough statistical overview of these things.

Bill: But then that leads to blind spots, and it leads to surprises. And no engineer wants to wake up in the middle of the night because, oh, that service didn't get instrumented, or, oh, there's an outage in part of the production degradation service, and part of the production cluster that didn't have the monitoring agents until it was caught too late. And so the changes we made are directly in response to that. We believe everything should be instrumented, and the groundbreaking product we introduced last week is telemetry data platform. It's been our back end technology for a lot of the applications that we've built up over the years, but we're now exposing it as a first-class platform. It handles metrics, events, traces, and logs. 

We've open-sourced all of our agents and integrations. So, we're doing those roadmaps now in the open and accepting code contributions from the community to make it easier and richer than ever to capture telemetry from everywhere. We're embracing open-source systems. So, we've announced as well support for Prometheus, and its remote write capability directly into this telemetry data platform so you can get extended retention, enhance security, increase scale of your Prometheus systems, PromQL as a query language on top of it, so you can ask questions of that metrics data and use Grafana dashboards on top of it, all for incredibly low price. The multi-tenant nature of our architecture and the high scale of it allows us to pass those savings on to customers so that they truly can instrument everything now in the telemetry data platform across data types, and visualize and analyze that data in ways they've never been able to before, functionally or because of the economic barriers. 

And it's in direct response to those challenges you mentioned. It shouldn't be so hard to instrument, your digital infrastructure, and be able to get answers to questions that you didn't even think about when you were building the system. I mean, that's the major shift between monitoring and observability in my view, is monitoring you deploy after the fact to detect when something goes wrong, observability you instrument upfront so that you can understand why something's happening as it's happening, or even investigate and understand how the system’s performing in ways that you didn't think about given the complexity when you were building it.

Corey: One of the things that struck me when I looked into a demo of New Relic about a year ago was when New Relic One was first announced, it ties directly to what you're saying. I ran into enough challenges along the way when I was writing my review that I eventually tabled the thing because, and I don't say this lightly, it was to mean. I tend to have a bit of a brand for punching up at publicly traded companies when they sell things that I don't like. And it was just a—to be blunt—terrible experience start to finish. It was confusing, the documentation on how to install it on the serverless side disagreed with itself, talking to the support folks to get up and running, it seemed that some of them didn't know that this product existed, and it was a very disjointed story. 

I knew what it was going to cost at least because it was a fixed fee, but, A) it was a lot of money, and B) the annoying part is after the demo was done, it took my normally $2 serverless app and add another $40 in AWS charges on top of that for the way that it was set up to pull the monitoring and all the rest. I mean, again, it was this is not the end of the world stuff, but it was frustrating, and it led to a point of, “Oh, I guess yeah, I'll just continue to consider New Relic from an APM perspective and move on to other things in the rest of the world.” Now you've relaunched the telemetry platform it’s, okay, this is unifying this in a way that how I try to view a monitoring product from a vendor—monitoring offering from a vendor—and now it's really coming across as, “Oh, okay. This is a cohesive product where someone has taken the bold step of introducing various product managers to each other.” And now you finally have relaxed the NDA that prevented internal service teams from speaking to one another. 

Now it feels like there really is a sense of this is an actual product offering that is aimed at user problems, not a component by component microservices product offering strategy that each one goes into different bits and pieces. I mean, I was, I've got to say, a little concerned at the IOpipe acquisition on those grounds of, “Oh, dear Lord, this is going to be yet another attempt at a second or third Lambda service monitoring system.” No, I'm seeing integration stories coming out of this, I really should have given those folks more credit. They're great. I was a paying IOpipe customer, and it's nice to see that those folks are clearly being listened to, as well as many other obviously intelligent folks at New Relic.

Bill: Yeah, absolutely. And apologies you didn't have a great experience the first time around with New Relic One.

Corey: Oh, it was ancient history. It was more than six months ago before you were there.

Bill: [laughs]. We'd love to have you back and give it a shot and give us feedback on if we've addressed the issues you hit.

Corey: More to come on that for sure.

Bill: Oh, good. Good. I definitely think we heard the feedback from you and other customers as well. And I believe we've solved some really fundamental problems with the announcements last week. As you said, starting with experience, we heard that the user experience was too disjoint. We had a lot of our existing applications and monitoring tools in a separate experience from the New Relic One experience. We heard that it was too complex to get started and to learn to use new features. And then, as we've already talked about, we heard that the economic barriers just didn't make sense, didn't help with adoption.

Corey: Yeah, and other engineering stuff that was irritating, too, of, “Oh, how do I install this?” “Oh, grab this janky script off of GitHub and run it.” “Okay.” I read the script because you can only trick me into doing things like that once before, “Okay, I'm going to learn on this,” and, “Okay, read things where you run them.” That's one of those things that’s extremely valuable to know right after you should have known it. But it was fine. It did everything I would expect except there was no uninstall option at that point. 

It's, “Oh, great. Then I get to go through, see what it did, and manually remove resources if the trial doesn't work out.” I have checked, that's not the case anymore. It’s, “Okay. Someone is paying attention to this stuff. It's not just a repositioning/cash grab,” if you'll pardon the cynicism. It's, “No, this is something that is actually envisioned through a lens of what a customer wants.” So, I've got to say, I'm an inherently cynical person, it's nice to see it.

Bill: I can tell. And speaking of cash grab, you probably saw we're offering now a very generous free tier. I think it's 10x more generous than any other vendor out there. Hundred gigabytes, free in just telemetry per month.

Corey: That's great. I'm going to start using my logs as a database.

Bill: Totally.

Corey: I've already been using DNS that way for years. So, now it's time to upgrade.

Bill: Take all your logs, put them in New Relic, 100 gigabytes free per month, or metrics, or events, or tracing, your choice. And you get our full-stack observability product on top of it, which is the complete set of APM, infrastructure, digital experience monitoring, synthetics, you get full access to all of that, one user, free forever. So, no more money grabs. And I'll say to the experience question that you had earlier, one of the explicit focus points for us over the last several months as we prepared for this launch is the out-of-box experience and the minutes to do it. We had a goal of five minutes to join. 

We want any engineer to be able to sign up for our new offering, get into the experience, automatically we provide a built-in data set. It’s actually kind of an interesting data set. We've aggregated all of the public API calls that our customers are using across all of our customer base, and we actually provide analytics on all of those public API endpoints and how they're performing. So, you get an out-of-box data set that’s kind of interesting to explore, built-in dashboard, so you can kind of see the capabilities of New Relic dashboarding and visual realization, explore that, and then begin to ingest your own data from more than 300 different sources of telemetry, and start to create your own dashboards and dive in to understand how your own systems are performing. Like that, five minutes to joy, that simplicity of experience has been a big focus for us. And we hope people take advantage of the free tier to check it out.

Corey: So, I have to ask, because this is the sort of thing that no one is ever going to ask in a formal CNBC style interview because they have this thing called, you know, tact. I'm going to come out and ask it. How the hell did that fly when you're sitting in an internal strategy meeting, and someone says, “Now listen here. You know how we normally charge people a whole bunch of money and put them into contracts so it’s, we A) charge them a lot, B) know what it's going to cost, and C) be able to book that revenue for several quarters out? Yeah, we're going to get rid of all of that, and just charge people for what they use instead,” and still be employed 20 minutes after saying that. How did that happen?

Bill: What is the New Relic values—and I have to say, I've been some pretty great companies, but New Relic lives its values more than any company I've been at. One of our values is ‘bold.’ and this was a really, really bold decision. If you need further evidence of that, just look at our stock price since we announced this strategy. Every investor I've spoken with this week has said, “We like your strategy.” It's very bold, and it's very disruptive, and it's pretty exciting to see it happen in this space. But we want to see it play out. [laughs] which is normal. Like, you know—

Corey: So, does the rest of us.

Bill: Yeah. Well, we're very bullish on it. Yeah, we spent a lot of time not only coming up with that idea, but validating with customers. So, before we ever rolled it out, we did, as you can imagine, a lot of customer studies, we've done pilot deals, we made sure that what we were doing was actually solving customer problems as opposed to making a great PR move. And that's what gives us the confidence to take these lumps, in terms of uncertainty in the market to really serve our customers because we believe when we serve our customers in the right way, it'll pay off in the long term. So, that's what we're doing.

Corey: I have a complicated relationship with usage-based pricing models, just because it comes off as being in general, yes, it can be a lot less money. I mean, I look at it through the lens of AWS as a general rule, but the problem is, is it is virtually impossible to predict, and you wind up with thinking you're doing everything right, and then finance as a minor question about why month-over-month spend is up 20 percent, and the answer is always, “The data warehouse.” But looking at that from a perspective of, especially during these unprecedented times, as we've taken to calling them, it does have a very customer friendly aspect to it that I hadn't really appreciated until confronted with a worldwide pandemic, where I have a number of customers who have a infrastructure strategy where, all right, their user traffic has dropped off of a cliff, and their infrastructure scaling and spend has not because of how things were structured and how they were built. We're hearing horror stories from other companies in the space where their entire model is that they are not letting customers do any contract adjustments whatsoever. And because you signed the line, you get to pay for it. The end. Usage-based pricing, like what you're doing solves for that. And that's really kind of a neat lens to view this through because it winds up becoming such a, I guess, a friendly story of you pay for what you use. If you don't like what you're paying, use less and the problem solves itself.

Bill: Absolutely. And there's an extra dimension of the way we structured our usage-based billing that I think it’s worth calling out because you pay for what you use, but one of the challenges even in that model is if the meters that you're being charged for are hard to predict, it's really hard to budget for. And if you look at the meters in any public cloud provider, and also maybe some of our competitors, you can see examples of that. One of the choices we made early on is to say, one of the most predictable things that every company has is their people costs, their headcount. Typically those don't go up and down very wildly. 

And so as we looked at a pricing model for our full-stack observability product—which for most companies will be the majority of their spend with New Relic—we intentionally chose that as a metric, A) because it's used very commonly in other industries. You think about, for example, sales teams with, say, Salesforce as a software service. They charge based on the number of users, the number of salespeople. Very predictable model, very common. If you look at, say, the design industry with, say Creative Cloud from Adobe, again, you pay by the user for your enterprise so all your designers can access the Creative Cloud tools. 

Same thing now is true with observability. You can now essentially cover your engineering team with access to a full stack of observability tools that we provide for one price. It's extremely predictable, and you only pay for what you're using. So, if your engineers are getting value out of it, then you pay for it if they aren't, and you don't pay for it. And we love that kind of mutually beneficial or reinforcing value proposition, right? If we're not giving you enough value that incents your engineers to want to use it, then you shouldn't pay us. And we're motivated to create more value and in return, customers are willing to pay for it. So, that's an exciting change.

Corey: It resonates. I mean, my least favorite software that I use right now is Tableau. And the reason is because it's a per-seat license, and it's on a year or multi-year contract, which means that every time I'm sitting here saying, oh, we've hired someone new, do they need access to Tableau, or not? The tool’s incredibly useful, and it's good, and there's really nothing else quite like it, but it's a investment decision every time I have to weigh the trade-offs of those things because the price is not small, especially as you continue to scale up. Getting away from models like that, where, “Well, I have this new application I'm launching. Do I want to wind up splurging on licenses for New Relic with it?” 

I mean, I will say a part of me, I'm cynically going to miss the days where it was charged per instance because in the early days before everyone fully understood how AWS and Lambda worked, I could spin up 20,000 concurrent executions and have it reporting into the New Relic library, and then later that day, which is superhero speed underpants-outside-the-pants style for enterprise software people, you'd have one of the salespeople calling me and the hardest challenge was not making a cash register sound with their mouth. And now it's a very different story. The world and market’s understanding of how software is continuing to evolve has itself evolved. And now it's just this… it's a much different universe. It seems that now rolling out something like New Relic can also increasingly become a bottom-up strategy, as opposed to being something has to go through procurement in the traditional style of ‘determine your usage before you roll it out for anything more than a POC.’

Bill: Absolutely. Shouldn’t observability just be part of the basic engineering process? We take for granted now vast array of developer tools, source code control systems, issue tracking. There are many open-source versions, many commercial systems that are—tools that are free, GitHub, wildly popular. Shouldn't observability be the same way? 

Engineers can adopt this basic part of their tool chest, use it where they want, and then companies pay for what kind of coverage that they want to have for their employees, and deploy it everywhere and instrument everything so that they're not left with surprises and waking engineers up in the middle of the night because they couldn't afford to monitor everything.

Corey: One question I've always heard from folks, whenever you talk about a software product or anything that aligns with selling something that is consumption-based—SaaS particularly—well, what happens when AWS decides to compete with you? It's always a fun story. I mean, in the monitoring space, I don't hear it nearly as much because the easy obvious rejoinder is let's get them to update their status page in a timely manner first, then we'll worry about how they're going to magically fix all of my other monitoring and observability challenges. But I'm curious to get your take on that. Is Amazon going to try to compete with you? It's probably the right question to ask.

Bill: You know, they've got CloudWatch, and they've got monitoring and other tools. Same as Microsoft. I think every smart public cloud provider will provide out of box monitoring tools for their services. Again, it's an essential part of providing a service nowadays. However, customers are often multi-cloud, and customers are not all in the public cloud, and so you need a system that can span clouds, and span your on-premise data centers, and your public cloud instances. 

In fact, the very nature of observability—of measuring things—is you want to measure the differences between those environments, right? And especially as you're moving applications or services between environments, you need to understand is the performance going up or down, or being less reliable? And so we think there's a very strong need to have an independent cross-cloud observability vendor, and New Relic strives to be the best one.

Corey: I'm really excited to see where it winds up heading from here. The market seems to like it so far, but the challenge is that it's super easy to get positive responses and everyone to say nice things when the engineering effort involved is more or less a press release. I think it's really going to come down to how the market responds once people start seeing how this works for themselves. I will say, having done an analysis of the pricing model, I don't see too much to complain about there at all. So, I'm eager to see what happens.

Bill: Well, I am as well, and we hope you give it a shot. We'd love you—check it out. Let's do a future podcast on your experience. 

Corey: Oh, if it goes well, then you'll be [00:28:15 laud] as a visionary. If not, you're going to be invited one of those fun meetings, where someone from HR you've never met before is sitting there, and they don't offer you coffee. That's always a warning sign. Last question for you before we wind up calling this an episode. Right now, as you look at New Relic across the spectrum, and analysts being analysts, and all the rest, what do you think is currently being the most misunderstood about the company?

Bill: I think some of the sentiment—and maybe some of it’s earned—is I've heard the ‘Old Relic’ sentiments, that New Relic is the APM vendor of yesterday.

Corey: You can't call it Old Relic, that's not an anagram of the founder’s name.

Bill: [laughs]. Well, that's true. That breaks that pattern, but there's some sentiment that New Relic’s best days are behind it. I am definitely a believer that the best days for New Relic are ahead, and it's been so exciting to be part of the reimagination of not only the New Relic One platform but the company. I mean, we talked about the bold pricing changes that impact our business model. Not many companies would be willing to take that kind of risk. And New Relic, like I said, lives our values, ‘bold’ being one of them. We've made some really big changes. And it's just the start of really exciting things to come. So, I'm excited by the future of New Relic.

Corey: Well, I’m looking forward to seeing how it shapes out. Again, if it goes well—or if it doesn’t—I'm going to be here, either way, casting stones from my particular corner of the world in which I produce remarkably little.

Bill: [laughs]. Well, have fun doing that, and stay in touch because we want to hear how it's going along the way.

Corey: Oh, you'll hear, unfortunately. That's what Twitter is for. If people want to hear more about what you have to say and what you're up to, where can they find you?

Bill: I’m @bstaples on Twitter, and you can search for my name on LinkedIn. I’m not hard to find.

Corey: Perfect. And of course, newrelic.com is where people can go to kick the tires on your new offering if they want to try it out for themselves, rather than listening to me cast slings and arrows from a place of relative impunity.

Bill: Yes, go newrelic.com, click on one of the many free buttons to try it out. Again, it's not a trial, it's free forever. And we'd love to hear what you all think. Thank you so much.

Corey: Thank you. Bill Staples, chief product officer at New Relic. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts, whereas if you've hated this podcast, please leave a five-star review on Apple Podcasts and a comment, and one of our enterprise sales reps will reach out to you in three to five weeks.

Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey at ScreamingintheCloud.com, or wherever fine snark is sold.

This has been a HumblePod production. Stay humble.