Can Product Operations transform your role as a product manager? Denise Tilles, who quite literally wrote the book on the subject (Product Operations, with Melissa Perri), thinks so. Especially if you’re interested in making better decisions faster – and who of us isn’t?

In her return visit to Product Momentum (having joined us from NY Product Conference, back in April), Denise reveals to hosts Sean Flaherty, Paul Gebel, and a standing-room-only audience of Product + Design Conference attendees how Product Operations unlocks the value of our organizations’ collective work.

What Is Product Ops?

Product ops provides the essential systems and supports that capture, review, and analyze data.

“It’s really about surrounding product managers with the tools they need to make faster and better-quality decisions,” Denise offers. It’s based on three key pillars:

• Business + data insights. Quantitative measures like revenue, engagement, and market performance.
• Customer + user insights. Qualitative research about customers, users, and they markets they comprise.
• Processes + practices. Best practices and methods, combined with the systems thinking that complete your operating model.

“Product ops fine-tunes existing ways of working – not by being prescriptive, but by helping people understand how we work so we can work faster, smarter, and hopefully in a more pleasurable way,” Denise adds.

What Product Ops Is Not?

Product ops isn’t designed to take jobs away from product managers; nor does it seek to undermine their efforts. Product ops isn’t about building systems and processes for their own stake. And it isn’t necessarily a formalized role as much as it is an approach to efficient product building. In fact, as Paul suggests, “Even if we don’t have the title, even if we don’t have a product ops team, we can always bring a little bit of it to our daily work to make things a little bit better.”

Be sure to check out the full conversation with Denise Tilles; if you prefer the video experience, you can find our episode with Denise on the Product Momentum YouTube channel!

Podcast: Play in new window | Download

Paul Gebel [00:00:19] Hey everyone, and welcome back to Product Momentum, a community of product people and a marketplace of ideas where leaders and learners come together to shape our way ahead. My name is Paul Gebel, and together with my co-host Sean Flaherty and the rest of our amazing team, we record conversations with thought leaders in product, UX, security, and beyond, that will help you shape the lives of your users through software. Check us out on all your favorite listening platforms. But for those who prefer the video experience, you can find all our latest episodes on the Product Momentum YouTube channel.

Sean Flaherty [00:00:50] Paul, I’m so excited! I love recording these episodes in front of live audiences, especially here at our Product and Design conference.

Paul Gebel [00:00:57] The energy in the room has been great. The questions and the engagement have been just vibing.

Sean Flaherty [00:01:03] And Denise is just a rock star. She just knows so much about product operations. In fact, she wrote the book on it, Product Operations, with Melissa Perri.

Paul Gebel [00:01:10] Absolutely. We’ve been really fortunate to dig into her thinking and the light that she’s shining on it. I think a topic that’s been in the back of people’s minds for a long time, but bringing out how to implement it, I think, can be scary because it’s an organizational change and that always feels big and daunting.

Sean Flaherty [00:01:28] But, you know, the bigger we get, the more we need. We need to understand the data. We need to make better decisions. We need to make those decisions faster. It’s not, it’s not something we can do without.

Paul Gebel [00:01:36] Yeah. We buried the Lede a little bit in the conversation, and I think I want to make sure that it comes out up front here because this isn’t about building systems for system’s stake. It’s not about building structure or rules. It’s about making people feel safe to do the work that sometimes feels chaotic. And I think that’s our job here. And even if we don’t have the title, even if we don’t have a product ops teams, we can bring a little bit of this to our daily work and make it a little bit better.

Sean Flaherty [00:02:04] I’d argue, we have to. Let’s get after it.

Paul Gebel [00:02:06] Let’s get after it.

Paul Gebel [00:02:09] Well, welcome. It’s been a fantastic, day so far. Denise, thank thanks so much for joining us again. Thank you. This is a returning guest, Denise Tilles joining us, talking about product operations, following a fantastically jam-packed keynote, on how when, and why you should be considering product operations for your organization. Denise, you wrote a book coauthored by Melissa Perri, called, literally, Product Operations.

Denise Tilles [00:02:40] Product Operations is very sexy. Yeah.

Paul Gebel [00:02:42] So let’s, let’s jump right into it. We’ve got a couple questions I want to start off with, but just at a really high level, I think the thing, the through line throughout your talk that I took away most was how to make better decisions. There’s a lot of, workflows, there’s a lot of templates, there’s a lot of processes and titles that are floating around in the space of probably operations. But it comes down to making better decisions. Is that is that fair? Does that strip too much away?

Sean Flaherty [00:03:07] And the last time you were on our podcast, there’s an episode out there, we talked about faster – not just about better decision-making – faster decision-making.

Denise Tilles [00:03:14] Right, right. So, if I can combine those two, it’s really about surrounding the product managers with all they need to make faster and better-quality decisions.

Sean Flaherty [00:03:23] Yeah.

Paul Gebel [00:03:24] Love it. So, it’s jump to do a little bit more. You talked about three pillars and let’s just kind of lay a foundation for folks who are, you know, I think product ops is a bit of a buzzword. And it’s not, I think fully, understood by the product community. Yeah. So, what are these three pillars? Quantity, quality, and process. What does that mean?

Denise Tilles [00:03:43] Business and data insight. So, your product engagement metrics. Revenue. So all of the quantitative inputs you would have hopefully to make a solid product decision. The second is qualitative. So, user research, market research, customer research. And then the third one is process, methods, systems thinking, operating model if you want to call it that. And just helping fine-tune ways of working not being prescriptive, but helping people understand how we work so we can work faster, smarter, and hopefully in a more pleasurable way.

Sean Flaherty [00:04:21] Well, I want to dig into your brain a little bit and discuss data.

Denise Tilles [00:04:25] Okay. I’ll do my best.

Sean Flaherty [00:04:28] So this is where you live. You live and breathe data all day long. We need data to make decisions. And there are really two — only two reasons I can see why we need the data. One is to understand how the experiments we’ve done in the past are turning out like, you know, pulling on the John Maeda thread from earlier today. We’re building vaporware. We’re building things that don’t exist, which by default means we’re innovating every day. That’s what we do. And our job is to build something better than everything else out there in the universe, right? That’s our job as product people. So we need this data, but why do we need it? And I think it’s important to understand like the reasons behind like why we’re collecting it.

Denise Tilles [00:05:07] Yeah. Well, if you can’t measure it, did you succeed? Did you fail? And I see this as a trend with companies I’m working with. They’re like, well, yeah, we’ll measure that after it launches. And it almost feels like if it doesn’t get measured, they’re not held accountable. But in my mind, it’s like, don’t you want the credit if it works? And then hopefully you’re in a culture hopefully. And I know this isn’t always the way, where it’s a learning culture that if it didn’t work out or didn’t meet the heuristics of what you defined as success, how do we learn from it? So, if you can’t measure it…

Sean Flaherty [00:05:40] Then how do you know how? Well, how do you know?

Denise Tilles [00:05:41] So you think about it. You drill it down a little further. Leading indicators, sort of understanding day-to-day, what’s happening. Are there any levers you can pull. And then more lagging which is revenue. You need both. Yeah. But oftentimes and I’m certainly guilty of this early in my career of just looking at revenue. And I think you can’t look at one without the other engagement metrics or revenue.

Sean Flaherty [00:06:03] Yeah. And then the second reason you need data is to figure out what you’re going to do in the future.

Denise Tilles [00:06:08] Exactly, exactly. Hopefully it’s giving you signals of potential opportunities, potential challenges, potential problems. And that’s where product ops comes in. And that was my experience with product ops in that, we had a team and they were more focused on the quantitative side, and they were amazing partners. They had a little bit of a remove from the day-to-day. So, me and my team were a little too close to some of the metrics and they’re like, oh, well, if you did this experiment here, that might actually yield more money within, a certain customer’s annual spend. We tried the suggestion they had, and we made $1 million the first year of just back of a pocket product that wasn’t even on the rate card.

All of our experiments were not like that, but it was like extra leverage. And someone who deeply understood our product but had a bit of remove and that really helped. It was like kind of a two-pronged approach.

Paul Gebel [00:07:01] So I want to tee up a question from the audience. By just sharing, you shared in your talk, a few ways that you can identify how you might benefit from product ops. If you don’t have visibility from the way your work connects to strategy, you might need product ops. If you don’t have access to the data you need, getting that self-serve data into product ops, and then growth beyond the original product into a governance that scales as a way to identify your organization might need product ops. So there’s the question from the audience, that I wanted to tee up with that idea is what are some of the risks? What are some ways that companies have mistakenly either implemented when they didn’t need to or tried to implement and maybe, fumbled a bit? What are some of the mistakes that you’ve identified in Product Ops rollout?

Denise Tilles [00:07:45] Implementing product ops?

Paul Gebel [00:07:46] Yeah.

Denise Tilles [00:07:47] Oh, buy in at the top. If you don’t have your CEO at least bought in at a very high level, it’s going to flop. It’s going to flop. Because they will be your biggest champion, reminding people, why are these people here? Why are they setting up more processes and helping sort of distill why we’re doing this and the value. So that is hard. And if you are reporting to the CEO, that’s your job. If you’re a couple levels below, you’ve got to give your manager enough ammo to make sure that they understand how to make the case to them.

Another is not understanding the culture. And I learned this the hard way. I was working with a large retailer, let’s say that. And I assume they’d be like, you know, we’re getting product ops.

And I was interviewing some of the team’s leaders, and one of them was like, I just want a program manager. I don’t want this. I got my stuff together. And I was like, what? What? That doesn’t make — it didn’t compute, but I understood it because, like, he had his act together, his team, they had all their metrics set up. They had a flow of data. And I’m like, well, maybe we could use you is sort of what good looks like and try to bring him into the fold that way. But that was surprising. So you have to kind of understand the culture in that, not everybody is going to be throwing roses as you set up this function. And that was surprising to me.

Paul Gebel [00:09:02] That actually leads into another question also from the audience. Shout out to Matt Ray. Thanks for phoning this one in. The idea that you’re talking about of, of buy-in and, and sort of the throwing roses metaphor, kind of speaks to this idea of product culture and how this integrates with taking a team and elevating it from, you know, how do we take a product house that’s existing? It might be even doing fairly well, but just not able to scale – they’ve hit that ceiling. I’m paraphrasing the question a little bit, but would it be fair to say that product ops is just as much culture as it is template or governance? Is there a mindset that has to come along with it in order for it to be successful?

Denise Tilles [00:09:49] Yes, I that was a lovely lead-in. Thank you. I think that the culture definitely counts as you’re sort of thinking about being that change agent in terms of how we work, how we think about the things that we need to make decisions. And it’s about helping roll out the culture that’s set at the top from your product leader and eventually your leader of your company. So it’s sort of being the face of that, too, because probably the day-to-day your product slate is going to be working. More, especially if you have a large company with some of the product managers, you know, coaching them. How do we get our roadmap rolled out? How do we figure out annual planning and where to pull our cross-functional stakeholders in? So, yeah, absolutely. I think that’s a side of it as well. I like the way you put that or Matt or whoever.

Sean Flaherty [00:10:34]  I want to keep pulling on this data thread. Okay. I’m a geek and I appreciate logic. So, quantitative versus qualitative, and we know we need both of those things, but is there a time to think when you think of the product lifecycle? Or the life cycle of a given idea. Talk a little bit about when you think you need more qualitative versus quantitative. How do you find that balance?

Denise Tilles [00:10:57] Yeah, that’s a good question. I love finding, opportunities in the data initially. And then that sort of guides us to figure out, like, let’s poke on this and look at it from the other side. And are these actual problems? The numbers are telling us something. We need to put some humanity around it. Right. And understand. So, I think from my perspective it kind of starts with the data. But then you sort of start probing, understanding, speaking to somebody like, tell me about your day and what it looks like and then teasing out pain points like, oh, that did sort of, prove that out. Or, you know, looking at the data and kind of trying to make it work for your idea.

Sean Flaherty [00:11:33] To figure out what’s what story is it trying to tell you.

Denise Tilles [00:11:36] Or bending it to work for your idea. So, it’s about being honest with yourself, too.

Sean Flaherty [00:11:41] Yeah. Something you said on the stage made me think of qualitative being what people say, quantitative being what people do. And you know, it’s the combination of those two put together properly that’s going to give you that sort of pointer. So, you know what to try next.

Denise Tilles [00:11:58] Exactly, exactly. And having that skill. And I’m sure all of you guys have done this and working with good user researchers are having that skill yourself and understanding how to tease out the problems without either leading them or getting, you know, inputs that they think you want to hear, you know? Yeah, that’s amazing. I buy that and then you roll it out like, hey, they didn’t buy that. What happened? So having that scale I think is important.

Sean Flaherty [00:12:22] Yeah, I also think the way, the way you kind of described all the different places you could get information about, to build. You know, and it occurs to me that your team knows a lot as well. It’s not always just about the customer. Like they’re thinking about these problems all day long. And there’s a that’s a big data source too. We need to we need to figure out how to tap into that.  And I see a lot of teams that aren’t really thinking that way. They’re just so customer focused. They’re not taking advantage.

Denise Tilles [00:12:48] …of having a perspective.

Sean Flaherty [00:12:50] Yeah, exactly. There’s a lot of other perspectives that might be valuable.

Denise Tilles [00:12:53] Well, in that that sort of, you know, gets you in that spot of like, do you want fries, a Coke, Diet Coke. You want to make sure that you’re not getting into that order-taking mode. If you’re just listening to the customers. You need the balance.

Sean Flaherty [00:13:05] Yeah. Especially in like a retail environment. We talked about a big box store. Right. Like the people that are closest to the customer probably have a lot of information locked up in, you know, what they know about the customer point checkout people.

Denise Tilles [00:13:18] Yeah. Absolutely. Yes yes, yes. Some of them are really good at tapping into that and making sure that they’re leveraging. Yeah, it comes from everywhere. That’s exactly it.

Sean Flaherty [00:13:28] So that’s probably the biggest thing I got from your talk is like, hey, we need to zoom out and look at all the different places where we can pull data and be maybe more logical about it, as opposed to just looking at the traditional sources that we always go after.

Denise Tilles [00:13:41] But the sequencing is important. I’m glad you brought that up, because I’m working with a company now, and they have this very elaborate product development lifecycle mapped out, and the user research has like, yeah, guess what’s not in there? Me. And I’m like, this is an amazing resource. Why are they not leveraging this? So it’s about the systems that we think about and making sure everything is considered. If we’re investing in this huge function. Let’s use it.

Sean Flaherty [00:14:07] I love that.

Paul Gebel [00:14:08] There’s a couple questions that are coming in around, the idea of. So at the macro level, there’s a lot of ops, design ops, DevOps, product ops, and sort of at the macro level of how product ops fits into all the other ops. And then at the, at the micro level, there’s a question about –  you showed a Venn diagram in your, keynote about, product and customer success, and engineering and product offset in the center of that. And the question is where does design fit? So, sort of at the micro level, sort of the players in the space aren’t always cookie cuttered out. You know, it’s not always going to be the same players interacting in the same way. And at the macro level, there’s a lot of operations at different layers in the org. How does product operations, how does a product ops team or a product ops professional start to engage at these different levels of the organization, where product isn’t necessarily the core of the conversation?

Denise Tilles [00:15:03] Yes, and sorry if that was too product-centric. If any UX folks are in here, I apologize. And I’m sure if we had, you know, design ops, doesn’t have to be in the center. And as I mentioned. There would be so many concentric circles, right, with all of the teams. I love the idea of having that sort of Superfriends council where everybody’s sort of understanding where you leave off, I pick up, here’s where we overlap, and it can be a great source of support as well too. So, I would think about it, understanding this sort of starting and stopping in the overlap, making sure that’s mapped out, because you’re right, at each center a functional excellence support would be there. That’s fair.

Paul Gebel [00:15:44] Yeah. Follow up to that, just kind of quickly, in terms of implementation, making this all practical, your whole purpose in delivery was to be kind of hyper-pragmatic. But, the rollout into an organization might not be a full-time hire, maybe not even close to a full-time team. So, this is a fractional product ops person who is dedicated to a team somewhere else. And they’re doing this with 30% of their time. They’re able to leverage. What’s the one thing that they should do? Is there a thing that will jump to the top of the list that sets that product ops focus into clarity or is it going to be the kind of person that can just be the 911 response and be the I’m this is the thing that I need to focus on today and tomorrow is going to be different. And the day after that is it going to be a person who can respond in the face of ambiguity, or is there is there a North Star for product ops overall?

Denise Tilles [00:16:42] You know, I was going to use those two words. It depends. But I think that the person who’s giving the 30%, characteristic that I think is so helpful is that curiosity and understanding, you know, their perception or their hypothesis or where the problems are may not be the case. So, someone who’s really good at discovery and really digging in and then having a clear view of like, we would love to do everything. Here’s what’s above the line, here’s what’s below the line, and really being intentional about that. So not doing more boiling the ocean, so to speak.

Paul Gebel [00:17:19] And you did touch on this in your talk. You talked about, you know, if you are just getting started and there’s not a budget or a team. You can identify the strengths and deficits. You can craft that value proposition. You can pitch your manager whatever shape that takes. And then ID those existing resources in the org that can start to take on some of the work. It might be you, it might be a couple people, but as a plan, it might be a bit of an internal skunkworks that you’re just kind of…

Denise Tilles [00:17:46] Yeah, that’s a great way of putting it.

Paul Gebel [00:17:48] Building this up and making it happen.

Denise Tilles [00:17:50] That’s a great. And in the book we talk about, Christina Itwaru at Pendo. And that’s how she started, her journey. She was a product manager. And just so fed up of the sh*tshow, pardon me, of things that were happening. And she’s like, I’m going to make this better for everybody. And that’s where it started. So, I think it’s important to sort of have some parameters around it. Like we’re going to test this for six months. This is what success looks like. We will understand that this may not have worked if x y z. So having those set at the front and making sure that your manager is clear on that too, because I might say, and it didn’t work. Everyone has their own perception. What did we define at the outset as success or outcomes? Hopefully.

Paul Gebel [00:18:29] Yeah.

Denise Tilles [00:18:30] Yeah.

Sean Flaherty [00:18:30] So early in the conversation, you mentioned culture. Important factor here. Like culture of data. And then you said…you use this word curiosity. And it occurred to me that this is what we need to build into our teams. Is this culture of curiosity. Yeah. So any advice on how to do that? Like, how can we better actually build it into our culture?

Denise Tilles [00:18:50] Yeah. I think it’s not letting the naysayers get you down. A company and working with right now, the SVP is like my, my product managers are not doing enough discovery. And as I’m poking and talking to folks one PM says well, the engineers think they know what to do and there’s no point in doing it. And if we do research or we do discovery, it’s going to, you know, throw off the schedule. So that’s a bigger problem. Right. But that and what John Maeda said earlier about the victim or player. Right. It’s easy to sort of fall into I the victim. That’s much easier and low, low impact. Yeah. And low, low, low accountability. But I think trying to, you know, you can’t go this way, go that way, or go under or try to go above, but it’s about not letting the naysayers bring it down. I don’t mean to sound too Pollyanna about that, but, and showing what curiosity that the benefit and outcome it can bring and, I think most product managers are pretty curious. That’s a good guess.

Paul Gebel [00:19:50] Yeah, I agree, we talked about the systems that can be part of Product Ops and there is, you know, kind of the governance models take the shape of any given organization. There’s not a one size fits all.  As you’re starting a journey into Product Ops, is it going to be an evolution of systems, and then applying them or are there a set of templates? I’d imagine if somebody were to pick up your book, they would find a few suggestions to get started on. But the systems that an organization begins to take shape around aren’t self-evident. You’re not going to look at an organization and say, this is what they need. You have to live through the experience and apply it. Kind of building the railroad tracks as the train is rolling. So, is there a chicken or egg here? Is it build the systems and then apply them or live in the space and figure out what the systems need as it becomes emergent. How does how does how do these relationships of designing the systems and applying the systems begin to take shape?

Denise Tilles [00:20:54] I think eventually the pen has to hit the paper right at some point. So you have that strawman of figuring out what could this look like? And in the book, Shintaro Matsui from Amplitude, you know, he was doing a lot of discovery talking to people. He’s like, here’s what I think. Go to market could look like, this is your process. I’m just mapping it out. Let’s use this and start from here. So, I think you can listen and live in it, but how long is the right amount to live in it? Sometimes just kind of take a stand and let people start poking at it. Prodding, kicking the tires.

Paul Gebel [00:21:26] Yeah. I think it’s fair.

Sean Flaherty [00:21:27] Yeah, yeah. Love it, any other questions from the audience?

Paul Gebel [00:21:30] One more that I it’s a bit niche, but I think it’s actually more widely understood than it might seem on the surface. So Zach asked a question about how this applies to, the agency model. I’m going to broaden that a little bit, too. You know, if you’re if you’re an enterprise and you’ve got, silo teams or if you’re an enterprise and you have vendors of any kind, the people doing the building don’t always have control of the governance. So, if you’re on that team that’s doing the building for either a client or another stakeholder within your organization. And you can’t just wave a magic wand and blanket a policy across the enterprise. Is it still worth doing product ops in your own space that you do have control over? But knowing that it’s not going to be, it might bounce off the people to whom you would call stakeholders. So, I guess the shorthand of the question is how big do you have to be? And maybe I’m dumbing this question down a little bit too much.

Denise Tilles [00:22:35] Please dumb it down for me.

Paul Gebel [00:22:37] How big do you have to be before you consider Product Ops?

Denise Tilles [00:22:40] Ah, Okay. Yeah, that’s a great  –  you know, it’s funny, people are like, what’s size? You know, some companies start out they’re fairly small. Like, we want to do this the right way. You know, I wouldn’t say that’s the norm, but I’ve seen it. I think it just depends whether…It really is a matter of understanding. Does anyone else have the capacity to do this? And if not that, then who? And then what happens if you don’t support that for maybe some subset and really thinking about like, what’s the worst case and what’s the best case? And then having sort of a view of, you know, the worst case here, the potential outcomes that we might see in the best case. And then thinking about, do we have a potential part of a resource, how do we make the case for a full-time time? Is 30% ever going to be enough? And I think if you get too far ahead of that, it’s like, take it as you can do it and sort of take the quick wins.

But in terms of influencing other stakeholders, I think it’s about making sure that you understand ways of working and then hopefully they can understand your stakeholders. This really benefits all of us that we’re not sort of rehashing how we do, PI planning every time. Or if we’re thinking about prioritization, you know, it’s not because someone’s screaming at you. But let’s like quantify this. Why this versus that? One in, one out. We’re not doing everything at once.

Sean Flaherty [00:23:59] Yeah, I don’t think product teams can really get away with not taking a pragmatic approach to data. Even the smallest teams just starting out. Like you got to have a strategy in place for what data you’re going to collect, what experiments are going to run, how do we know we’ll be successful? But as you get bigger, I think you need a much more pragmatic approach, like the one that you explain where you can zoom out and kind of systematize. How are we collecting this data? How are we sharing it? What does it look like? How are we, you know, going to use it to make future decisions like, it needs his own roadmap?

Denise Tilles [00:24:31] I’ll get a little salty here.

Sean Flaherty [00:24:34] Oh, boy.

Denise Tilles [00:24:34] You got awesome spicy. You guys may have heard about a book that came out in March that was critical of product operations and process. Process is a bad word. But, you know, Melissa, who wrote the book with me, you know, had a couple of posts, but one of them was like, it’s pretty naive to think as you get bigger that you wouldn’t have any systems in place.

Sean Flaherty [00:24:56] Right.

Denise Tilles [00:24:57] And how does that work if you don’t? Is it chaos? Is it anarchy? Is everything self-organized? I don’t know.

Sean Flaherty [00:25:03] Yeah. I’m of the belief. Well, it’s not a belief. The science shows, self-determination theory. Like we like structure, but people need structure to be, to feel. Somewhat safe, right? Like, if you’re working in a completely chaotic environment that causes its own level of stress. So there’s always going to be a balance of how much freedom do I have to experiment and create, and how much structure and predictability do I need in order to operate effectively?

Denise Tilles [00:25:30] I think what I would want everyone to come away with is like, there’s not one right way. And if anyone tells you that, it’s what your needs are and what works for you. I work with some companies. All they have is business and data insights aspect of product ops. Others, it’s all really focused on that operating model. Not really yet on the qualitative but shape it the way you need it. We’ve just sort of created that framework in a way to think about what the opportunities or needs are. So make it make it your own.

Paul Gebel [00:25:58]  I can’t think of a better note to end on. I’m going to say thank you to Denise, and I want to thank the audience for being so thoughtful and engaging. The questions have been amazing. It’s been, a really, I think, insightful look into how we can create a safer, more workable – just some, some human agreements of how we’re going to work together. And create a space where we can be a little bit better and improve.

Sean Flaherty [00:26:23] Get better at decision-making.

Paul Gebel [00:26:25] So thank you, Denise. Thank you. To the audience. It’s been a great conversation.

Paul Gebel [00:26:30] Well, that’s it for today. In line with our goals of transparency and listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get. So please leave a comment or a rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch, and inspire the world just like you’re doing. Thanks, everyone. We’ll see you next episode.