No product manager wants to build a bad version of their software. But sometimes that’s what it takes to accelerate the learning process. Well, maybe not a bad version. But an early, admittedly incomplete one. Something you can quickly get out in front of users, gather some feedback about, and iterate on. Today’s podcast guest, Candu co-Founder and CEO Jonathan Anderson, explains, “If you then decide to go down the development route, you’ll be so much smarter, so much further along the path of figuring out what the right thing to build is.” This concept of drafting is super-valuable, he adds, “but not because we know what the end product will look when we’re done. But because we don’t.”

Candu provides no-code web tools for SaaS apps; at its core, no-code is like products for product people. It helps non-tech-savvy product managers bring even greater impact to their teams – a sort of counter-punch to the vexing “all the responsibility, none of the authority” PM mantra.

“So often we think of building software a little bit like a sacred cow, something only a handful can do along a very prescriptive process.” Jonathan says. “Maybe it’s time to allow non-technical people – like product managers, growth teams, maybe even customer teams – to actually build some of these interfaces themselves.”

No-code, low-code tools help transform passive, receive-only PMs just waiting for requirements to fall from on high into more engaged product builders. We’re better positioned to shift the development effort upstream and figure out where that cut-off is – when the “bad” version of our software is still good enough to ship.

Be sure to catch the whole conversation with Jonathan Anderson; and don’t forget about our 100^th Podcast Episode Book Giveaway. Enter for your chance to win!

Podcast: Play in new window | Download

Paul: [00:00:19] Hello and welcome to Product Momentum, where we hope to entertain, educate, and celebrate the amazing product people who are helping to shape our community’s way ahead. My name is Paul Gebel and I’m the Director of Product Innovation at ITX. Along with my co-host, Sean Flaherty, and our amazing production team and occasional guest host, we record and release a conversation with a product thought leader, writer, speaker, or maker who has something to share with the community every two weeks.

Paul: [00:00:43] Hey, everyone, Paul Gebel here. Before we get into our conversation with Jonathan Anderson, I wanted to tell you about a little giveaway. It’s a small token of our gratitude for helping Product Momentum get to 100 episodes. So we’re going to select ten winners to receive a book authored by one of our actual podcast guests. It could be from Jesse James Garrett or Jake Knapp. Could be John Zeratsky. Really quick, here’s how to enter. Head over to itx.com/pod100giveaway. That’s itx.com/pod100giveaway. It’s a real quick survey. Get yourself entered to win a book and it will arrive sometime after the new year. All right. Let’s get back to business and on to the conversation with Jonathan.

Paul [00:01:26] Well, hello and welcome to the pod. Today, we’re excited to be joined by Jonathan Anderson. Jonathan is a passionate product-led seller. He’s launched services, strategy, operations, and analytics teams at venture-backed SaaS startups, including Insight Squared and Launch Darkly. Prior to startups, Jonathan worked at Bain and Company and he has a B.S. and Master’s in Engineering from Stanford University. Jonathan, thanks for joining us today. So glad to have you.

Jonathan [00:01:50] Oh, it’s great to be here. Thanks for having me.

Paul [00:01:52] Absolutely. So just to tee things up, Candu is what you’ve described as a low-code, no-code UI component builder for SaaS products. It’s an entrant in that growing category of like products for product people. And I’d love to just start out by hearing your story of what Candu has been through and the iterations you’ve taken. Can you tell us the story of your journey so far from beta to launch and relaunch?

Jonathan [00:02:27] I can certainly try. We’ll see how long we have. I think like most good products, it’s been through a couple of phases about figuring out what the core problem is and what we solve for. But yeah, at its’ core right now, we help non-technical teams build user experiences, so like embeds that you can use to enhance an existing product. So an example could be, like, an onboarding checklist or an announcement bar. It’s all the kind of sweeteners or the helpful cruft you can add into a software product to help people kind of orient themselves and get started.

Jonathan [00:02:45] That’s not where we start as a product, but it’s where we ended up. We took the last two years kind of building up the latest vision for it. But I think probably it came from my feeling working as a non-techie in a technical team, honestly, just because I couldn’t do a lot of the stuff that I wanted to do. I’m not going to say there’s like a difference in stature among the coders and non-coders, but certainly, when you’re kind of working in product or on customer or even in marketing teams, you’re very impotent in many ways when it comes to actually building the actual product experience itself. And I was actually building my wedding website with Wix, which is a drag-and-drop, easy-to-use website builder. And I was like, “I know that these are technically different,” right? The onboarding page, for example, of an app versus my wedding website, but fundamentally like, a button is a button is a button. Like why can’t we use some of this drag-and-drop technology, this interface builder in a product experience? What would that look like if you kind of incorporate some of these elements into building software?

Paul [00:03:44] Great. So I think the journey then from ideation to concept and then launch… And by the way, your mom’s video of how your product works is one of the most adorable things I’ve ever seen. So I think that launch video was really telling in terms of how much passion you have for bringing products to life, not only your own product and Candu but also how to help product managers be more effective in their team. Is that kind of a fair perspective of what you felt like you wanted to bring to the table?

Jonathan [00:04:14] Well, that and also finding an opportunity to get my mom involved, obviously. She’s been asking to help for years. You know, I mean, she used to actually sell software for IBM. So, you know, she grew up in that model. But I have not been willing to give her a job, in part because I don’t think I could manage her effectively, to be totally honest. I just don’t think it would work out from a relationship perspective, but I’m glad that she was able to join for a little commercial we put together. And also, I don’t know if any of you are like this, but I spend a lot of time doing, like, tech talk with my mom. She’ll come up with a list of like 15 things she needs help with and I’ll try to, like, help as much as I can. And so I was like, “what if we took this and kind of brought it into the world of, you know, what I actually could use help with, which is trying to convince people that it’s okay for non-technical people to have a little bit of influence on the front end,” and how do we kind of communicate that to an audience that traditionally really hasn’t done this type of work, hasn’t done this job?

Jonathan [00:04:56] Because I think a lot of what we’re trying to do with Candu is shift who gets to create software, as opposed to, like, what we’re making, right? We’re saying, you know, “hey, an onboarding checklist is an onboarding checklist is an onboarding checklist.” It’s really the who, not the what, I guess is like the core concept here, which is why my mom was such a good foil for that particular video.

Sean [00:05:12] I’ve heard you say it’s like shifting to the left. It’s like shifting everything in terms of a timeline to the left. In particular, I’ve heard you say that a product manager’s biggest asset is knowing what drives value for customers. And this sort of toolset or this sort of thinking, I think is important and I think you’re seeing that shift across the industry to no-code, low-code ways of prototyping, ways of getting ideas and concepts to market faster as sort of the core philosophy here.

Jonathan [00:05:39] Yeah, I think philosophically, like I think software development has actually moved so far in that direction right? Like if you go back to like the Lean startup model versus like the waterfall kind of ways of building software, I think we’re seeing a lot of it within technical teams already. And I think actually in some ways product managers are a little bit playing catch up in some respects because I think the next step beyond just working within the sprint is saying, “Hey, what can we actually pull out of the sprint? What doesn’t need to be done by the engineering team?” And I would argue that, like, an announcement bar explaining to users how to use the new feature probably doesn’t need to be in the sprint anymore. So what if we could not just reduce how long it takes to build a software feature with development, but actually move some of those jobs out to the product manager, to the designer, to the marketer? How do we kind of give them more of our Legos, as it were, as we kind of build software?

Paul [00:06:24] Yeah. It’s not being removed from the sprint, it’s just changing who’s doing the work.

Jonathan [00:06:28] Right. Right. And I think especially as we move into this world where our users have these expectations for how easy it’s going to be to kind of get up and running, I think, especially on the consumer side, everything from Netflix to Tik Tok, we’re just used to really good UI, really good UX. And I think enterprise software obviously is much more powerful and has more core functions. But there’s this big disconnect between what our users, even in business applications, expect versus kind of what we’re able to deliver easily. And I think that’s really where no code kind of plays in, because basically what we’re saying is, you know, “if this is a solved problem, if you’re trying to figure out how to help someone, you know, click through to like see some content or see some recommended actions to take in the product, like, let’s not reinvent the wheel here. Let’s borrow great concepts from user experience design and kind of pull them into our powerful, robust enterprise applications.”

Sean [00:07:16] All right. So want to pull on that thread a little bit. So expectations are changing not just in the consumer space, but also in the enterprise application space.

Jonathan [00:07:24] I mean, yeah. Have we figured out how to divorce our lives completely from our acting as consumers? No, I don’t think at all. I think, and I actually saw this at Launch Darkly on the sales side, where increasingly it’s not just the VP of Engineering saying, “Hey, you know, let’s go ahead and use this feature,” they’re going down the team and saying, “hey, is this something you want to use?” Right. So I think even in these like procurement-heavy, box-checking, enterprise sales cycles, usability is more important than ever. And so I think it’s not just that usability is important, I guess, and I’m using usability as more so than just accessibility. I really mean like, how easy is it to get up and activate a software product? It’s exciting, I think, that enterprise software is moving in this direction and also making a lot of us who sell enterprise stuff are pretty nervous because we’re like, “Oh, we have a lot of catch-up to do,” right? It’s a big difference if your DNA is Dropbox versus, not to call attention to anyone else, but one of these more legacy players. So.

Paul [00:08:11] Yeah. I think one of the things that you’re doing in differentiating not just your own product, but also how different product managers within different types of organizations deliver value, the quote that sticks out in my memory when we were chatting earlier is, “different users mean different use cases.” And it sounds sort of deceptively simple on the surface, like, it’s almost a tautology, but you have this concept of, as a user, you know, fill in the blank user story. There’s almost a Jobs-to-be-Done end of the spectrum, where it’s, “I’m documenting all the unmet needs that need to be addressed.”.

Paul [00:08:43] But what you’re talking about is almost like marrying the two back up and saying, “this is a human being who has a role but also has a job,” and there’s a need that’s going unfulfilled right now that you’re trying to plug the gap in. So I’m wondering, can you share some of the stories that you’ve heard from product managers and feedback in terms of, you know, what is this road that you’re going down? Perhaps focusing on the personalization aspect. That was something that I think you’ve discovered, as a real sort of key element to your journey.

Jonathan [00:09:12] Yeah, it’s such an interesting dynamic, I find, because the longer your product’s been around for, the more use cases it unlocks and the more types of people who come into it, right? So it kind of has this multiplicative effect where you suddenly have so many things your software can do and then so many different types of people who are coming in and looking at it. And often this is kind of broken up by role. I’d say, like, admin versus end user is like a super common, I guess, difference.

Jonathan [00:09:33] But I mean literally it’s much more complex, especially when you get into these hub-based products, like a CRM that has multiple different packages. It’s really easy to understand that just the complexity gets really overwhelming. And that’s just like so bad for your actual end user because we can really only process one thing at one time. And also it’s really easy for people to be overwhelmed. I think, getting back to our expectations conversation, people are less willing than ever to invest in learning software at this point because they expect it to just be easy and to be straightforward. So I think one of the most powerful things you do as a product manager is to say, “let’s just pause, what are the most common use cases that we know drive value? And then how do we expose the right use case to the right user in the software offering we have?”

Jonathan [00:10:17] So let’s just imagine a world where like, let’s say we’re implementing Salesforce and all three of us are looking at the application. Maybe we all have different needs for it, and maybe the three of us actually see different things, right? We have different experiences in the software. That’s not really happening today if you think about it. I mean, we all log in, we have the same tabs, we have the same navigation. So I think this idea of like, what if we actually had fundamentally different experiences, different interfaces based on what our core needs were? It really simplifies, I guess, what software should look like. It’s not, what’s the expression we use sometimes? The grandma’s garage of features, right? How do we clear a path so that you just see one thing at one time? Because honestly, that’s all that we can handle.

Paul [00:10:53] Amazing. Yeah. The grandma’s garage. It’s really the beginning of the end for a lot of those legacy product players where you start to get so feature-bloated and it’s hard to disrupt yourself at that point. It’s hard to see through to, what is that core personalized experience that you’re trying to carve out if what you’re presenting is 50 different use cases for 50 different users and being kind of all things to all people.

Jonathan [00:11:16] Yeah, for sure. So actually we did a lot of cool UX studies on, like, what’s the most effective first page of your product? And you know, we looked at things like, is it a checklist of actions? Is it a slide that says, “here’s the one thing to look at?” Is it a tour that tells you where things are in the product? And obviously, it’s going to vary a little bit by use case. But actually, one of the best UX patterns to think about is actually a progress or workflow. That’s [inaudible]. So the way that would work is you basically start with a question, you know, “what are you here to do?” I think TurboTax is probably one of the best-in-class tools for us. And then once you’ve kind of said what you’re here to do, then you have one question per screen, as it were, as it takes you through the completion of that specific flow. That’s really a different UX pattern than what I think a lot of us are used to, on the enterprise side specifically. But it’s actually super, super valuable because it kind of lets the user first identify what they’re here to do, we can’t infer that. And then it says, “You’re not done until you get all the way through this job, until you get to some value.” And that’s really, I think, a really helpful framework when it comes to, how do we simplify the product a little bit while still allowing for choice?

Sean [00:12:15] This is for onboarding, right? Because once somebody is in and they’ve learned how to use the products, then this concept of autonomy becomes a different thing.

Jonathan [00:12:23] Yes. Yes.

Sean [00:12:24] You made a statement about, do you clear the past so that just one thing is visible at a time or there’s like one decision to make and I think it’s really valuable in a simple sort of workflow where you have this very simple decision tree, but then it gets complicated after you’re in the product.

Jonathan [00:12:40] One hundred percent. Hence why product managers will still have jobs for a long time. But no, I think, even if you think about hub-based products, Zenefits, for example, I think does a great job with this as well. So they have, I don’t know, so many different product options. They maybe have, if you go to their home page, maybe there’s 14 different tiles of things you can pick up. But when you go into one, you actually are re-onboarded to that specific feature set and then you’re taken back through a workflow again.

Jonathan [00:13:02] And that’s kind of how I think the right way of designing complex products is, is you allow for this expansion and contraction. So expansion where you’re trying to say, “hey, look at all these cool things that you can do, let’s give you a couple of options.” Actually, I’d recommend three instead of fourteen. And then once you’re in a certain flow, you are making micro-choices, like small input fields or configurations, to kind of do that one thing but keeping people kind of on track. Not to treat our users like children, but like, let’s make it really easy, turn-by-turn directions, think Google Maps, not your paper map, as it were.

Sean [00:13:36] Yeah. You know, one thing you said too, you know, going back to that quote about, how do you clear a path for just seeing one thing at a time? We know people can really only process one linear thing at a time, that’s the way it works. But, you know, we build these complex systems to solve complex problems. And the more of an expert someone becomes, the more important the navigation UX and all that stuff…

Jonathan [00:13:57] Mm-hmm.

Sean [00:13:57] It caused me to see the world in a little different way, and I appreciate that.

Jonathan [00:14:00] Well, it’s impossible to unlearn what you know, right? And as software builders, we’re seeped in the stuff. We’ve thought about fifteen different workflows. We’ve talked to a million customers. We’ve really gone into the detail and we really know a lot. And it’s really hard to go back to being the novice again and saying, “What happens when I don’t know anything, you know, what does it feel like to be green on this?”

Paul [00:14:19] Yeah. You’re getting at something that we talked about earlier, too. I think there’s an element of risk management, if I could put it that way, in the speed to which we apply this delivery of value. And the way that we were talking about it, it’s a way of protecting the vision of the product by getting a more complete or a more apt version of the concept or vision, so that, in other words, the faster we get something in front of people, the more likely they are to think that that’s the thing. And now we have to compete against unlearning that draft version. And by being so fast to market, we can create an unintended risk of saying, “This is what we’re building,” when it’s actually just the MVP or it’s just an iteration of it. So I wonder if you could pull on that a bit and sort of this done draft…

Jonathan [00:15:10] Oh, yeah, the done draft part of building software. Oh, my goodness. What an interesting question. Okay, first of all, this is really hard. Let’s just be really clear about that, because we are, at least I’m a perfectionist and I love to see things that are like crisp and clean and useful. And I think it’s also really difficult when you have an engineering team, especially when resources are scarce, because they often are, how good is good enough? Right.

Jonathan [00:15:30] One thing that I think no code can be helpful on is helping you first make a really bad version or like a really early version that you can actually get out in front of users, that you can then get some feedback on, that you can then use to iterate on and continue to tinker with. And then if you do decide to go down the development route, which most of us will for most serious applications, you’ll be so much smarter, you’ll be so much further along the path of figuring out what the right thing is. I think this concept of like drafting is really, really valuable, not because you know what the end product will look like at the end, but because you don’t, that’s, like, the main problem, right? We need to see and test what will actually work for our users. That said, it’s really hard to talk to a team and say, “Hey, we’re making a bad version because we want to learn how it’s going to work.” You know. It’s hard. It’s hard to know where that cut-off is, where it’s good enough to ship. And I think we all struggle with this. I would just argue that it’s probably a lot earlier than you think it is in the funnel.

Sean [00:16:21] Well, it becomes more risky the bigger the product is, the more users you have.

Jonathan [00:16:25] 100%.

Sean [00:16:26] But there’s always a way to do split testing.

Sean [00:16:27] Yeah. And I think that was one of the key goals of actually what struck me, one of my last roles, which was, how do we dark launch something? How do we show it to a small number of users, like get some insight if it’s working or not, and then if it doesn’t work, how do we make sure we can turn it off? Right. Where’s the undo button? You know. So I think that’s a really valuable software practice. And I think it’s also valuable for product managers to be thinking about, “what’s the minimum I can do to learn something, to get some good data?” be it qualitative or quantitative.

Paul [00:16:51] Well said.

Sean [00:16:53] Yeah, well said. So all of this to say, what you’re proposing or supporting is this concept of more democratization of product managers and actually the building of features and putting things into the market over time.

Jonathan [00:17:06] Yeah. I think, I’m saying that as software builders, our job is getting really hard because expectations are getting really high and we need to move really fast. And I’m saying there’s a shortcut here which is borrowing or like using no code to kind of move along that path a little faster because ultimately it’s about the speed of your learning, I think is really what it comes down to, that’s the argument I’m making, and that often we think about building our software products a little bit like a sacred cow, something that like we have to do in this like very clear process. We’ve already kind of burned down the world once. We shifted from waterfall to Agile. And I think that another flavor of this is actually, how do we kind of use no code in this? And part of that really for me means allowing non-technical people, like product managers, like growth teams, maybe even like customer teams, although maybe that’s pushing it, to actually build some of these interfaces themselves, especially if it’s lightweight stuff that’s been done before. Yeah. Spend your dev calories on things that are really hard and unique and make your product really special. For everything else, look around, you know, build-versus-buy I think is an interesting, is always an interesting thing.

Sean [00:18:12] Well, I love that little phrase that you squeaked in there around dev calories. That’s a quote.

Jonathan [00:18:19] For sure.

Sean [00:18:20] It’s almost like what you’re pitching here is a guerilla approach to sort of getting some features tested and getting things to market faster. And again, I’m going back to shifting left our learning. I think that’s the intent and I think that that’s never a bad thing to do if we can figure out how to do it in a safe way that also helps us make sure that we’re defending the hut, you know, we’re not doing irresponsible things out there.

Jonathan [00:18:39] Oh, yeah, of course. I will say in general, users are actually a lot more forgiving than you think. In general, they would actually rather, in most cases, at least I believe, there be more innovation because that you can learn and continue to move on. But yeah, no, obviously I’m arguing that we should move ourselves to the left. I’m not saying we should throw the baby out with the bathwater. I’m not saying, build your whole enterprise, replicate your bank routing with bubble. But I’m not making that claim by any stretch.

Sean [00:19:04] No, I do think this is a really important conversation for the product leadership community, especially in products. Like the bigger the product is, the more established it is, the more important it is to learn because you’re the one that’s the target for disruption. You’ve proven the model. The market’s there.

Jonathan [00:19:17] Yes.

Sean [00:19:17] They’re coming after you.

Jonathan [00:19:18] Yes, they are. You have to be comfortable to burn the ships, you know, and that’s really hard to do.

Paul [00:19:24] Yeah. I think one of the things that I’m hearing, just to tie this question up, is that it’s not necessarily even a matter of speed or coding talent. It’s a matter of confidence and posture in the teams themselves. So as a product manager, you are not a passive, receive-only person who is just waiting for requirements to fall from on high so that you can put them in a backlog.

Jonathan [00:19:46] Yes.

Paul [00:19:47] You’re speaking the vision into reality for the team and that calling is really, it’s a big responsibility. And as we’ve said many times on the show before, it’s all the responsibility with none of the authority, it’s trying to navigate those waters.

Jonathan [00:20:00] Yeah, oh I love that. I think often we confuse product management with project management or like maybe team morale building when it comes to like influencing developers or designers to kind of build what you think is valuable. But I think actually the really great product managers are the ones who have their thinking caps on the whole time and are always saying, “what can we learn from this? How can we move our thinking forward?” And they’re really partners, I think, coming up with the vision and then really thinking through, “what are these experiments that we can run to get us closer to where we want to be?” So yeah, it’s one of my favorite roles. It’s not just project management saying no. There’s more to it, I promise.

Sean [00:20:35] Alright. I collected some summary points, I just want to go through them with you real quick. One, We’re under more pressure than ever to deliver learning fast, and we have to think of creative ways to shift the work to the left. Number two, the expectations of the market are changing. We expect better UI, even in enterprise applications, than ever before. This is not something that’s going to lighten up. It’s not going to get better or easier with time. Like, expectations for UX are getting higher and higher and higher and it’s on an exponential curve.

Sean [00:21:03] The number three takeaway, a product manager’s best asset is knowing what drives customer value. And if you don’t have tools to be able to figure that out in a quick way, it can be very frustrating. Number four, this goes along with the expectations, but people don’t want to have to invest their energy, time, and effort into learning a new product. Like, they expect it to just teach them how to use it.

Sean [00:21:24] Number five, people can only really do one thing at a time. So when you’re thinking about this onboarding concept, onboarding new features, onboarding a new user in general, but even over time, as you introduce new parts of a product or new features or new modules, so to speak, this onboarding concept, I think, is the time in which you should really pay attention to focusing your user experience on what you want them to accomplish, even down to what you said, which was point number six: there’s a time for having one question on one screen, and if that’s the best possible solution, that’s something we should consider versus making a bunch of assumptions about our consumers.

Sean [00:22:59] Number seven, it’s impossible to unlearn what you know. Taking a step back and like trying to put the child’s mind on wherever you can so you keep that fresh perspective. Number eight, there are shortcuts out there to help product leaders learn faster. Number nine, the bigger, more established a company is the more important this learning is because you’re the target. So we got to find ways to get more lean-in terms of how we learn. And lastly, the thing that really stuck with me the most is your concept of dev calories. I don’t know why, but I wrote down, be careful with your dev calories, you know, they’re really valuable to the org. We know that. So those are my ten top takeaways, Jonathan

Jonathan [00:23:35] Phenomenal. I’m so impressed with your ability to come up with that phenomenal list. If you just do those easy ten things, no problem. You’ll be rocking as a product manager. I love it. I absolutely love it.

Paul [00:22:48] One thing that we ask of all our guests before we let them go is, well, two quick things. And the first is, could you share with us what your definition of innovation is?

Jonathan [00:22:58] Oh, that’s a great question. I’m probably going to just borrow the Clay Christensen’s model of innovation, which is, I’m sorry, it’s just so imbued in my brain. I can’t even unthink it. It’s when you learn how to discover something in a new way and it’s worse than the old way based on how you used to judge things because you’re now judging it in a whole new light.

Sean [00:23:16] I love that.

Sean [00:23:16] Because your frame is different for what’s valuable to you.

Paul [00:23:19] Love it.

Sean [00:23:20] Great answer. And lastly, what are you reading these days as a product leader? Like, what books or learning do you recommend to the community?

Jonathan [00:23:26] Oh, you know, honestly, I’m just such a podcaster at this point. I’m a huge fan of Pivot and [inaudible] and of course, what you guys are doing over here. So, I don’t know, maybe I would listen to a product podcast, if I was, you know, maybe some Product Momentum. I don’t know. Who knows? But I think in terms of like when I do reading for fun, probably my favorite book is still like Americanah. It’s just a really beautiful and really interesting take on race in America. The narrator is was just so humorous and heavy and wonderful. And I just really, really recommend that for anyone, just in terms of maybe empathy is the excuse here because product managers can just always develop it. But the truth is, is it’s just a great read, so.

Paul [00:24:02] Amazing. We love it.

Sean [00:24:04] Great podcast. Jonathan, thank you for joining us today.

Jonathan [00:24:07] Oh, it’s been such a pleasure. This was really fun to get into it.

Sean [00:24:10] Well, thank you for joining us.

Paul [00:24:11] Cheers.

Sean [00:24:12] Thanks so much, guys. Really appreciate it.

Paul [24:15] 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.