Speaker 1: Hey there, product lovers. Welcome to the Product Love podcast, hosted by Eric Bodak, co- founder and chief evangelist of Pendo and super fan of all things product. Product Love is the place for real insights into the world of crafting products as Eric interviews founders, product leaders, venture capitalists, authors, and more. So let's dive in now with today's Product Love podcast.

Eric Boduch: inaudible, I'm here with Matt Riley, who's VP of product at Elastic. Matt, why don't you kick this off by giving us a quick overview of your background?

Matt Riley: Sure. So as you mentioned, I'm Matt Riley. I've been working in, I guess the tech industry, since around 2008. I joined as a software engineer at a company called Scribd, which is now best known as sort of the Netflix for books. I was a software engineer for several years, moved into product management, and started my own company around 2012, a company called Swiftype. And then we were ultimately acquired by Elastic. And that's how I ended up where I am today.

Eric Boduch: So tell me a little bit about Swiftype.

Matt Riley: Yeah. So Swiftype came about sort of out of a personal need. So at Scribd, as I mentioned, I was working with another one of the software engineers there who was ultimately my co- founder at Swiftype. We were building a pretty sophisticated search engine, sort of consumer side at Scribd. And we were just using a lot of different tools. We tried out a lot of things and it ultimately was just a very challenging task to build and scale over time. So we started Swiftype with the idea that we felt like we could build a SaaS service that would simplify a lot of the more complicated aspects of building a consumer- facing search engine. And at the time, we had been using a whole lot of... a wide variety of different search tools, but just at the time that we were leaving to start Swiftype, Elasticsearch sort of entered the open source world. And Elasticsearch was still very, very new at the time, but it was gaining a lot of momentum. We really liked a lot of what it was doing, even in the various earliest versions of it. So we adopted that and built... used it sort of as one of the primary pieces of our search infrastructure, but continued to layer on a lot of proprietary technology that we built just to make the SaaS service work itself, really simple, make it really easy for people to get up and running with the search engine for their website or their mobile application. And then kind of all the things that come from that.

Eric Boduch: Let's step back a little. You talked about being a software engineer and moving into product. How did you get into product management?

Matt Riley: Yeah, it was sort of, I guess, natural, but maybe accidental. I was a software engineer for several years when Scribd was a relatively early company. Almost all of us were just software engineers. And I think over time, what I realized was there would go... a couple of months would pass and I really wouldn't write very much code. I was spending most of my time with the other engineers, talking to them about what we were going to build and why, and all the things that ultimately become what you do full time as a product manager. I was already sort of operating in that mode and realized I liked it a lot. And so made the transition to being a product manager there. I was the first product manager we had at the company. And then obviously starting the company, starting Swiftype, that wasn't my role there. But transitioning back into it as I got to Elastic. That's kind of the path right now.

Eric Boduch: So talk to me about what you're doing now at Elastic, problems you're solving, teams you oversee.

Matt Riley: Sure. Yeah. So when Swiftype was acquired by Elastic, we basically brought two products with us. We had a site search product, which is basically the original Swiftype product where we were trying to make it as easy as possible for someone to build a search engine for their website. And then we had also built a second product at Swiftype called Swiftype Enterprise Search, which was about making it easy to search over the wide array of tools that people use in their day- to- day work lives. So we brought both of those two products with us to Elastic. And today that's the enterprise search group at Elastic, which I oversee. We still maintain those two products. We also still actually maintain swiftype. com as a separate product and fully SaaS experience. But that's my responsibility today.

Eric Boduch: Talk to me about that acquisition integration process. What did that mean for both companies? How did it go?

Matt Riley: So I think we were very fortunate in that where the Swiftype product was as a user experience. Basically, we had taken a lot, we had taken Elasticsearch. It was already one of our core building blocks of our service, but we had layered on a layer of simplicity and sort of business facing tools on top of it that made search easier, less complex for the average person who wants to come in and build a search engine, of which there are many, many of those people. And that was very much in line with where the Elastic product suite was already evolving. What we call today at Elastic our solutions, they're basically... We have the open source components and the Elastic stack. That's our Elasticsearch, inaudible, and Logstash and all the many core developer tools. And over the last several years, we've been building these what we call solutions. They're basically purpose- built applications for specific use cases. So in the case of what I'm responsible for, those are for enterprise search use cases. We also have purpose- built solutions for observability like logging and metric monitoring and also for security. So it was fortunate about our acquisitions that our product was already very much in line with where the Elastic product suite was heading. So we slotted in quite nicely to that. But there were certainly some challenges, probably the largest of which was that Swiftype was built as the fully SaaS multi- tenant product. Everyone's kind of using and sharing resources. And it's only accessible online via swiftype. com. Elastics products, they originated as downloadable software components. They had a version that you could run on premise. We also have a cloud service, but even in our cloud service, people are running in a singleton and environment. It's a bit more like a platform as a service product right now. So one of the bigger transitions that we had to make was taking the Swiftype product and rearchitecting parts of it out of this sort of multi tenant SaaS thing into something that could run on premise with only a single external dependency, that being Elasticsearch.

Eric Boduch: Difficulties in the process? You're taking two product teams, putting them together, right. What challenges did you run into?

Matt Riley: I don't think we had a lot of difficulties from a product management perspective. I think one interesting aspect of Elastic is that kind of the way that we've built, as I just described the product suite, we had this core Elastic stack foundation, and then we built these purpose- built solutions on top of them. The purpose- built solutions are able to operate somewhat independently because we're all building on a core foundational Elastic stack. So there wasn't a lot of difficulty across the products, but I would absolutely say that there were... At the time when we joined the company was still growing very, very rapidly. And there were a lot of things to kind of figure out as we jumped into this integration process. And I think looking back in retrospect, when we know more about where we ultimately want to take this solution offering of Elastic, we might've done things slightly differently earlier on to set ourselves up for the kinds of integrations that we're building today.

Eric Boduch: You talked about thinking through some things earlier on. Are you talking about roadmap decisions or are you talking about some of the structure? What would have made things smoother?

Matt Riley: Yeah, it's an interesting question. Maybe kind of get somewhat of the more interesting aspects of what we do as product managers. But I think I didn't fully appreciate when we joined Elastic, what Elastic's existing distribution mechanisms were and how we can leverage those best. So when you think about how our customers find us, we have people who visit the website and download the products. We have people who go to Elastic cloud and spin up a deployment. We also have a huge existing user base of customers who just upgrade their existing software. And as we joined, we first were still in a sort of separate piece of infrastructure. And we had our product over there and we were dedicating some various marketing and go to market efforts to continue to drive and grow that business. But as we integrated, I was starting to realize we needed to really prioritize making sure that we could get our products into the existing distribution mechanisms with Elastic as quickly as we possibly could, which meant definitely restructuring into something that could be downloaded on the website, making sure that we were available to people when they went and upgraded an existing piece of the software so that we could have sort of a presence in that upgrade process. And finally, also being available on Elastic cloud, which of course required this migration from a multi tenant SaaS product into something that you could run as a single tenant inside of the Elastic cloud platform. So I think emphasizing the speed with which we would run towards that is certainly something that I learned along the way. And it's a good lesson in just emphasizing where your distribution mechanisms are and how valuable it is to be integrated with those when they're working really, really well.

Eric Boduch: Yeah, yeah, no, absolutely. It's something I think as companies acquire other products and merge product technologies in is often overlooked, like how to leverage existing channels or sales infrastructure and make sure that products align to take advantage of that. One of the things we were talking about, too, is like product teams working together. Right? So let's dig into that a little bit more. How are your product teams, how did they work with the other departments there, engineering, design, customer success? What have you guys done to ease friction that, in a lot of companies, is inevitable?

Matt Riley: Yeah. So the engineering, design, and product teams are all part of the same organization at Elastic, which certainly means we work closely together, but it doesn't mean that there's no friction at all. And I personally think that there's actually kind of a good level of friction that's expected between, for example, the product management and engineering management. I always want my product managers to be pushing very hard on what's coming out of the engineering team, paying very close attention. And engineering managers are, obviously we all have the same goals, but they have various different concerns. They're going to think about things like technical debt and all the things that we want to do there. And we do have to balance all of that. But I think that the introduction of some aspect of friction is pretty healthy between those different components. And when it comes to something like design, it's possibly a little bit simpler there, but it's something that I emphasize with my product team, that to have a very close relationship with the designer who you're working with, try to simplify their life as much as possible. I tend to be a very design oriented product manager. So I think a lot about user experience and try to... And I think that in order to do that really effectively the PM and the designer, whoever's working on a product together, they both need to bring a lot to the table and work very closely together. Whether it's designers creating artifacts that a product manager can poke at, or vice versa, a product manager creating wire frames that a designer could look at and give feedback on. I think that that's probably the best way to create a really good relationship between PM and design.

Eric Boduch: So Matt, talk to me a little bit about how the structure works in Elastic. I know you have product, engineering, design, all reporting up into one org. Can you talk to me about how they work together, how it's organized, who they really report to?

Matt Riley: Sure. Yeah. So I think we have kind of a unique structure at Elastic where each product team essentially has three primary leaders, and the teams within them also have the same sort of leadership structure. So at the head of each product team, we have what we call the product lead, the team lead, and the technical lead. And the product lead is the head of product for the group. The team lead is basically the engineering manager, VP of engineering. And then the technical lead is essentially the architect of the team. And each team has that set of people. And we all roll up into one chief product officer who manages all of the different product groups starting kind of with a group of three at the top of each of those.

Eric Boduch: Definitely interesting structure. Is there an overall engineering leader or is it ends up that each of the product groups has an engineering leader that independently report up to the CPO?

Matt Riley: Yeah. So it is the way that you described it. We have engineering leaders who all independently report up to CPO. The CPO is obviously also highly technical. We have a highly technical product suite. Also our CEO, Shay Banon, is the founder and the original author of Elasticsearch. So he's still in some ways involved with a lot of the really important technical decisions that get made there. So a lot of highly technical folks in that leadership structure without a single individual person, I guess you would call it the global head of engineering specifically, aside from inaudible CPO.

Eric Boduch: Interesting. I think, I mean, obviously works for you guys. You guys are doing really well. You know, one of the things we were talking about when were talking about alignment, we've obviously touched on engineering design, we've touched on the organizational structure. How do you work with some of the other departments? So like customer success, right? How is that interaction?

Matt Riley: Yeah, that has evolved a bit at Elastic. Being a... A lot of how Elastic has grown has been a very bottom up adoption mechanism. We have a lot of practitioners who use the product and who ultimately become customers of ours through really natural evolution. And departments like customer success, where product ends up being, I think, most interactive with them is, oftentimes you're coming in and helping develop relationships at a practitioner level in some cases with the folks who are using the products very heavily. So we end up getting to work with a lot of our customers and helping the customer success team with having conversations at the practitioner level, where we would have to go in there, if we're going to give a product roadmap overview or something like that for a really key customer. But kind of dropping down into a lot of the details, talking to the technical teams of which inaudible customers of Elastic really ultimately ended up being technical teams. And that's really, I think, what we bring to the table in a lot of those conversations, that level of expertise and participating in that part of the relationship building.

Eric Boduch: I'm curious, too, how technical is the customer success team there, given the nature of who they're supporting, what they're supporting?

Matt Riley: Yeah. I would say that they're fairly technical. In fact, when I interview people kind of across departments, there's a very common interview question people ask me like," What does it take to be successful at Elastic?" And even when I'm talking to people in say like a finance role, which I'll sometimes participate in interviews for, I always tell them that I think that it's really important to understand our products and have the technical acumen at Elastic, just because that is where our customer base is. It is where inaudible of the value of our business is, in this technology platform that we've built and it's pervasive throughout. It's very hard for us to serve our customer really well without a strong technical understanding. And I see it prominently displayed throughout our organization, throughout the sales org, marketing, and customer success as well. A lot of the very... the highest level leaders are really quite technical and their understanding of the software is pretty deep. And I think that that's been important to Elastic's success.

Eric Boduch: Awesome. Thanks. So what's the big challenges right now for Elastic? Like what keeps you up at night?

Matt Riley: I think that there's an enormous opportunity in front of us. There is no end of challenges when it comes to the things that search can be applied to. Even if you're just looking at my solution area where we have a product in helping you add search to your application or to your website for some consumer- facing use cases, pretty much any website, mobile application, on the entire internet has that need. So there's an enormous opportunity there. At the same time, we have the workplace search product, which is really intended for helping employees of companies find the things that they need on a day- to- day basis. And I would argue that that problem is only getting larger and larger with time. We've seen a huge explosion in the number of purpose- built SaaS- style tools that people are integrating into their productivity, the work that they do on a day- to- day basis. And as we do that, people are getting more productive, but they're also scattering information all over the place. And search is a really great tool for helping you organize that, that helps you explore all the information that's out there and bring it back in a relevant way. So to me, the challenge is just building to meet those needs of the market right now, and certainly to build it in a way that is highly extensible, because I think search itself is a problem or a challenge that is not simple to define in all cases, especially when you have customer A, who wants to solve it in one way, and customer B has a slightly different data set and wants to solve it slightly differently. You have to build very extensible products, but we also want to make them easy to use, and balancing extensibility and ease of use with onboarding, I think is always a challenge, especially in the enterprise software space.

Eric Boduch: How much is your business enterprise versus non enterprise segment? And we all define enterprise a little bit differently, but...

Matt Riley: Yeah, we have a large enterprise business. And I think that, without getting into an exact breakdown, I think what you see, one thing that's very interesting about Elastic, at least what I think is really fascinating, is we have really adoption across the board. Everything from very small, people adding search box on their blog and having a relatively small monthly contract with us on Elastic cloud. That's a great customer. But we also have people who adopt us in that mechanism who are very, very large customers. So large, established companies, we have a large federal business with government agencies. And so we really do span kind of the entire gamut of what the software space is. And what I think is actually also quite interesting is, we see a lot of customers who start off in these relatively small segments. We see customers who are smaller startups. They have the ease of use of getting started with something like Elastic open- source products. You download them, you can run them for free. In many scenarios, you can run them on Elastic cloud, starting with a very small monthly cloud account. So people adopt them when they're early stage companies. And oftentimes, those early stage companies grow into really, really large companies. And some of our largest customers actually started off with us as very small startups with relatively small contracts. So I think that's a fascinating sort of attribute of our business.

Eric Boduch: Yeah. And the reason I was asking it, because it was a lead into where I thought I would be able to ask, which is, it's a challenge, right? When you're building from really large enterprises, even federal, down to the person putting search on their blog. Right? So how do you balance that from a roadmap perspective, when you think about the different size constituents or consumers of your product? Is that as big a challenge as it appears to me?

Matt Riley: I think it is. And I think a lot of what we have to do is take a long- term view of what our overall architecture needs to be for serving that large set of customers. So if you look at some of what I was saying earlier about Elastic cloud, where we built a singleton and architecture, that you can choose a deployment in Elastic cloud and say," I want to run this deployment in this region of AWS, or I want to run this deployment in this different region of Google cloud platform," for example. So we've built this Elastic cloud platform that is extremely extensible in that way. And it's planned that way because I think we see that that's the kind of flexibility that our customers ultimately are going to want, certainly as you grow larger and larger. We also have a huge amount of compliance and security work that needs to go into that underlying infrastructure. But as we invest in the infrastructure and kind of its own layer, and we build our products, our software products that are user facing on top of that infrastructure, across a common platform, all the investments that we make in the infrastructure really benefit everyone sort of at the same time. So every time we add a new region in Elastic cloud, all of my products get it sort of naturally. In a similar way, every time we add new functionality or improve Elasticsearch, because my products are built entirely on Elasticsearch, We also inherit all the states. So we invest a lot in power plays, which I think makes it possible for us to serve a wider variety of customers where they otherwise would be able to focus on. So I can think about different customer segments than certainly some people are thinking about in the infrastructure world right now, and that balance can shift over time. I think as long as we have the right plan, which I feel strongly that we're building the right things for our even very large customer set. It's a huge investment of energy and it's certainly not easy to do, but is, I think, very fruitful.

Eric Boduch: Talk to me about mistakes other people make, or you see people make when they're building for that really big enterprise segment.

Matt Riley: Yeah. I think that maybe one of the mistakes is neglecting to realize that you do still have end users who want simple, great product experiences. That's something that I certainly try to keep in mind. Even if you're out there in a big enterprise space selling to the enterprise buyer, whoever in the C- suite is the buyer there. Ultimately, typically you're going to have the practitioner who's in there working with the software. And those people are used to really great consumer experiences in software. Software has been getting better designed and more polished many times over in the last several years, and the things that they interacted with them, their consumer lives, they start to have the same expectations of the things that they interact with at work. So I think that neglecting to think about those people is a pattern that I certainly don't want to fall into myself. And something that I think plenty of enterprise companies do fall into too.

Eric Boduch: So now we're working in this COVID- 19 world, right? Almost all of us working remotely. How has that impacted your company, your product team, and how do you think it's changed tech in general during this time and product teams?

Matt Riley: Yeah, I think it's interesting, especially from the Elastic perspective. So we didn't touch on this initially, but Elastic has always been a distributed company. So we grew up as an open source product with employees all around the world, and were from even the very earliest states. And even as we've matured as a company, we have offices in various locations, but we still had a workforce that most of which worked from home all around the world. So prior to the pandemic, we were already working in a way that's quite similar to what we're doing today. But I will say that it certainly added to a new layer of complexity even there. No travel has been, I think, a challenge for a lot of people and has meant, people being at home all the time, has certainly meant that there's a lot more hours in the day that people are sitting near their laptop interacting with their computer and their colleagues. So I think it's just put a little bit more pressure on that, but even thinking about this outside the perspective of Elastic, there's a huge amount of emphasis now on essentially asynchronous communication. And from a product management perspective, that's something that we have to think quite a bit. In previous roles, and certainly at Swiftype, product management was quite different than what it is in a distributed environment or in a totally remote environment like the pandemic has forced on us. If you're still all sitting in the same room, it's a lot easier to communicate, have a open conversation with the entire team at any given time. And you probably don't have as good of practices around documenting decisions made or writing things down and communicating things via email. All of the things that I think are good practices regardless, but are easy to kind of get away from in a live environment. And so I think that remote work has certainly changed that and probably brought about the need for better asynchronous communication, the utilization of different kinds of tools to stay organized across your group, and probably an endless variety of other things that I haven't even touched on.

Eric Boduch: Yeah. It's going to be interesting to see how this changes, when people are ready to go back, if they're ready to go back, how that adjusts to companies that were an office centric culture. What are your thoughts on that? How do you think... What's going to happen?

Matt Riley: I think people will be eager to get back. I think there will be aspects of the remote work that people are pretty happy to have, and will want to continue at the level of flexibility that you get. I think works pretty well. The lack of commute's certainly nice, but there's also something to being in an office with people. Even at Elastic, I went to our office fairly often. It wasn't a huge number of people there, but something that I can get a lot of energy from being around my colleagues. And I think that that's a... That may be something that product teams are very eager to do. Because I know most of the product managers I work with kind of similarly feed off that kind of energy being in a room with people collaborating.

Eric Boduch: So trends for the future. What trends do you see happening in product management?

Matt Riley: I think we'll continue to see some level of specialization across different product roles. You know, product management I think is becoming a more well- known, well- defined discipline. And so as that happens, I think companies are adapting to having specialized types of product manager, whether it's for growth roles or for specific user facing roles. There's a whole lot of different... There's some specialization there. I think there's also probably always going to be just an evolution of tools. I've been really thrilled to see how quickly some of our tools have evolved, certainly over the last year, but even preceding that. A lot of that was what precipitated thinking about the workplace search problems, how we're going to be able to actually pull all that information together. But I, just even independent of our own product, I've been really thrilled to see kind of the quality and the rapid pace of evolution of the tools that people can use to be more productive at work. And I have a few of my own favorites, many of which are relatively new.

Eric Boduch: Yeah, no. I mean, it's interesting how much the tool set on platforms for product managers have evolved over the last years compared to the 20 probably previously. It's kind of crazy as a vendor in that space, right? As someone who built product in that space, I just remember our tool sets before being things like Microsoft Project and Word and Excel. I'm like, it was like Office was our tool set, and it's gotten a lot more sophisticated. I'm super happy for the product management community. And we've seen that in education, too. I mean, you can get a Master's now from Carnegie Mellon in product management. I think Stanford has a program now. It's great seeing the rise, so to speak, of the product managers in a lot of different ways. We'll have to finish this up by getting your thoughts on two things more specific to Matt. The first is like, what's your favorite product, or your favorite products?

Matt Riley: Yeah, it's a hard question to answer, I guess. I would say I do have one product that I just really love as a product inaudible that I use a lot. It's a product called Whimsical. I'm not sure if you're familiar with it. It's basically kind of a wireframing and flow chart creation tool. It's entirely web based and it just gets a lot of things right. It's extremely easy to use and makes the wireframing process in some ways just much easier than it was prior to that where I was using kind of a grab bag of different tools. And I do a lot of that kind of work. As I was saying earlier, when you're working with the designer, for example, I think it's really important to bring some of that to the table. I encourage my product managers to be out there creating wireframes for the products that they're describing rather than entirely written descriptions or thinking about a whiteboard that doesn't exist at least right now while we're all remote. So I think that Whimsical has becoming a huge part of my own tool kit. Some of my other favorite things are really just small parts of product experiences. As a product manager, I have a tendency to look at just pieces of products that I really, really appreciate, whether it's onboarding of a particular product where I'm trying to take ideas away from that, or very boring things like account management or how you switch between multiple accounts. Because I think as any product manager knows, it's actually a pretty challenging problem once you have a user who can switch between a team account and their only account, and maybe they're a part of two multiple, different teams and all of those things. So I try to look at those pieces of products and I have some favorites out there, companies.

Eric Boduch: Yeah, that whole permission can be a nightmare with multi products, especially when you have suites, like you have different... Like Google comes to mind, right. Certain products or it logs you out of stuff, it doesn't give you permissions right. You can't have... It's just permission becomes a nightmare with multi accounts across a broad swath of products.

Matt Riley: Absolutely. Yeah. When I see it done really well, I feel like I notice it. And then also, when it doesn't work well, it's extremely frustrating. So I try to take notes on the ones that are doing it well, so I can bring those same things. Because we've faced the same challenge at Elastic. And similarly with onboarding where there are certain SaaS products, I think just do a really phenomenal job with getting the onboarding right. And there's always little things that you can take away from that to bring into our own products.

Eric Boduch: Yeah. I mean, it's interesting the whole account switching and permission. It's often something that people don't pay a lot of attention to when they start, but then their product portfolio gets bigger and then they have to deal with the multi account issues and then it becomes a huge major endeavor for them to update, fix, upgrade as they move into kind of that level of sophistication.

Matt Riley: Yeah. I mean, you asked earlier about how some of the states that enterprise software companies sometimes make, and if you're starting out knowing that you're going to build this enterprise software toolkit specifically for the enterprise, maybe you're not going to make all the same mistakes. But what you just described is something that I think is really common. A lot of companies start in these early stage SMB markets and ultimately start moving up market and meeting those challenges when they're not... didn't originally design around things like account switching and permission. Those become really challenging to solve in later stages. So they're certainly something to think about early on if you're thinking of going that way.

Eric Boduch: Yeah. Yeah, absolutely. And it's just, I mean, you don't want to spend a lot of time solving them before, because you have limited resources when you're first starting. So it's this happy balance of like," Okay, we don't want to create huge amounts of the problem for us later down the line, but we also don't want to build so much upfront that we're not getting enough traction to raise the next round or be successful or whatever it happens to be."

Matt Riley: Absolutely.

Eric Boduch: So this has been fun. One final question for you today, three words to describe yourself.

Matt Riley: Yeah. It's also kind of a tricky question. I would say, if I'm being optimistic, I certainly try to bring the level of enthusiasm to my team. So enthusiastic, diligent, with a high quality bar for the work that I do and that others do around me, and also try to bring a level of creativity. So creative as well, I think that that's probably... It's certainly something that I look for in other people, and hopefully if you were to ask my team, maybe they would use that word to describe me, but we'll have to see. I'll ask them after this.

Eric Boduch: Yeah. Would love to hear if they match. Well, thanks Matt. This has been a blast.

Matt Riley: Thanks. Thanks for having me. It's been great.