Episode 577 | Finding the Right Problem to Solve

Rob: Welcome back to Startups for the Rest of Us. I’m Rob Walling and this is the podcast that we ship every week. We have since 2010. That’s more than 11 years. This is the podcast about building real businesses for real customers who pay us real money and while we’re doing that, we’re seeking freedom, purpose, and relationships. That’s what Startups for the Rest of Us is all about. It’s a lens through which we view startups. Thanks so much for joining me today.

Really interesting conversation today with the author of a book, as you know I don’t have many authors on this podcast. It’s not a big interview with a guest about the next big concept or whatever, but this guest, his name is Jim Kalbach. He wrote a book on Jobs To Be Done.

If you haven’t heard of Jobs to be Done or you’ve heard too much about it and you feel like I don’t want to learn more about it, I think this interview might change your mind. I would give it a chance because we dig into some super practical points, specifically what if I’m pre-product or pre-idea, how can I interview people, ask questions, and figure out problems that are worth solving? What if I’m at 3000, 5000, 30,000 a month and I’m kind of plateauing where the product should go next, I don’t know what features to build next?

You can do this thing called switch interviews which are in the Jobs to be Done parlance. We’ll dig into those. Then we actually, in the end, did a roleplay. Jim did a great job. He totally humored me where I talked about a recent switch decision that I had made with MicroConf—switching from one software to the other. Normally, these interviews are 30–60 mins where you dig way, way deep and we spent about five minutes doing it. But I think it’s a great example if you haven’t been exposed to Jobs to be Done of the things you can learn from these frameworks.

I think if you’re a founder and you’re like me, you tend to roll your eyes at frameworks, at things that come out of Harvard Business Review, not that they’re not legitimate, not that they’re not real, but just that they don’t often keep small startups in mind. They expect that you are a middle manager at Procter & Gamble, you’re getting your team on board, and your budget is only $10 million this year. So many business books I can’t deal with because of that, and that’s what Jim was able to avoid. He was able to talk to us, the single founder, the mostly bootstrap SaaS companies.

I do have one announcement to make, but I’m going to keep you in suspense. Next Tuesday morning’s episode is going to have an announcement that I am really excited about. It’s probably the biggest announcement that we’ve made since launching TinySeed three years ago. Stay tuned, it’ll come up in your feed as usual. In the next episode, we’ll have information on that.

At that, let’s dive into my conversation about finding the right problems to solve whether you’re pre-products, or whether you’re plateauing and you’re just trying to figure out where to head next.

Jim Kalbach, thanks for joining me on the show.

Jim: Yeah, thanks for having me. Great to be here.

Rob: Absolutely. I got a Twitter tip. On Twitter, someone mentioned you and they said you have this amazing book, it’s called The Jobs To Be Done Playbook: Align Your Markets, Organization, and Strategy Around Customer Needs. Basically said, I forgot who it is, I’m going to have to go back and look later, maybe I’ll link up in the show notes, but he said, you should really interview him on the Startups for the Rest of us. I appreciate you taking the time to come out.

Jim: Love the topic. Happy to share my insight and thoughts on Jobs to be Done.

Rob: Awesome. The first thing I want to ask is can you loosely define what Jobs to be Done is in a way that is practical for early stage startup founders?

Jim: Sure. I characterize Jobs to be Done as a framework, a set of techniques around innovation. It allows you to talk about the problems that people are trying to solve, people that you care about in your target market, without talking first about solutions, products, or brands. Ultimately, it’s really about product-market fit, but looking at it from the market standpoint. Very often when we talk about product-market fit, you create a product, and then hold it up to the market and say, do you like this? And they say no and then you build, measure, learn and do that again.

What Jobs to be Done does is it says no, no, we can actually understand market needs by looking at the market in and of itself and work back towards the product. It dovetails with lean techniques, but theoretically, what it helps you do is predict adoption, which is the same thing as product-market fit.

As an innovator, as a startup, I want to have some sense, maybe not specifically, but at least directionally where should I be pointing and where should I be aiming at. Jobs to be Done gives you a language and techniques to help point your business in the right direction to the problems that you should solve that are going to have the biggest impact in the market.

Rob: What’s interesting is Jobs to be Done has been quite popular in the Startups for the Rest of Us, in MicroConf circles, and mostly bootstrap SaaS founders. Typically every MicroConf we host, we have at least one speaker, who mentioned Jobs to be Done whether it’s the focus of the talk, or whether it’s just an offhand like oh, we did these Jobs to be Done interviews and we found out this.

I think it’s permeated our group, our community in a good way. I still think there are a lot of folks who haven’t experienced it or haven’t experienced the magic of it. I did some Jobs to be Done interviews, probably not correctly about five or six years ago with a software product, and then more recently, we did some with MicroConf which is the community and events that we throw. We did those about two years ago.

I’m a believer and I know folks like Asia Orangio with DemandMaven does them. I know that Claire Suellentrop Forget The Funnel. If you’re listening to this as a founder and you’re thinking, why should I consider doing this? It’s really smart people who I trust their judgment on finding these things are using them. These are tools.

I think with that kind of couched, when I think of Jobs to be Done, there’s a lot of terminology of hiring. There are words or phrases that are used in certain ways. Without the phrases, the jargon, or the words used, are we trying to find what problem a customer is trying to solve and how they’re trying to solve it irrespective of my offering?

Jim: That’s it. That’s how I actually described it and I call that job thinking. Jobs to be Done brings a way of seeing things to the table. Instead of looking at the people that you serve through the lens of your own solution, whether it’s real or imagined, you’re seeing them in a certain way. You’re seeing them as possible consumers of your solution, and that clouds your judgment.

By taking yourself and your offering out of the equation, potentially—there’s no guarantee of this—you can actually find opportunities that you wouldn’t see otherwise. Instead of looking at them as hey, these can be consumers of my products, users, or adopters of my solution, you’re looking at them as free-will gold-seeking actors in the world trying to solve a problem. I’m glad you use that phrase because I use it as a synonym for Job to be Done are problems to be solved. What’s the problem that you’re trying to solve?

Rob: To piggyback on that, something out of your book, I read through the book and I want to quote you here. You say, “Jobs are stable over time even as technology changes. The jobs people are trying to get done are not only solution agnostic, but they also don’t change with technology advancements.”

Jim: Correct. I described Jobs to be Done as a language or Jobs to be Done techniques come with a language for describing the problems that people are trying to solve independent of any solution, product, or technology. What that does is it gives longevity to that view of the people you’re trying to serve because you’re not describing what they’re trying to get done in terms of today’s technology.

If you take a very high-level job like listening to music, a hundred years ago, people used to crank up a phonograph and listen to music. Then we had record players, 8-tracks, tapes, then CDs, and then Spotify. In the future, we’re going to have, I don’t know, VR listening rooms or a chip implanted in our brain. I don’t know what the technology is going to be. But from a Jobs to be Done standpoint, there are stable aspects of listening to music. If that’s the domain we’re interested in, listening to music is listening to music is listening to music. By removing technology and solutions from your language, you actually help future proof your thinking.

Rob: Got it. I think of another example, there’s a TinySeed company called Builder Prime which is a CRM software for home improvement contractors. If I go back to 1985, I bet their CRM software, their solution was paper, and then I bet by ’95, it was an Excel spreadsheet maybe, an email, or something. Then I bet by 2005, maybe if they’re lucky it’s a Google Sheet because now it’s in the Cloud. Then by 2015, 2020, some percentage of those folks have now adopted Builder Prime and other software like it, am I following a similar path?

Jim: That’s absolutely correct. In fact, one of the test questions that I teach students and talk about is to ask yourself, what did they do 10 years ago? What did they do 20 years ago? What did they do 30 years ago? When you’re operationalizing the jobs to be done language and you need to formulate it in a way, every statement, every step in your job map, or whatever technique you’re using, you need to formulate it in a way so that it would be true when people did that CRM with spreadsheets and Rolodexes because the step is fundamentally the same.

Record contact information, for instance. You don’t say click a button and create a record in the database because that’s what they did today. When they were using Rolodex, they recorded the client information. You would write it very generically like that. That helps you future proof your thinking because we might have some AR solution or AI solution, but guess what? You’re going to record the client information. That’s part of CRM. If you record things in a way that explicitly expunges technology from your language, you’re building this longevity into your thinking.

Rob: That’s really interesting. I hadn’t thought about it that way in terms of the language actually being different. Something I’ve said on this podcast many times is that the precursor to a lot of SaaS is a Google Sheet or an Excel Spreadsheet. Anywhere you see that, that awesome and winds up becoming a SaaS in a vertical or horizontal. I’m linking that to Jobs to be Done as we’re talking, of course, because that spreadsheet is doing a job and that job might be better done by a more complex or more focused piece of software.

Jim: Correct, and that’s what Jobs to be Done in advance of having a product or solution on the market. It tries to find that problem that’s going to be most important for people to solve. They were using a Google Spreadsheet, but what problem were they trying to solve? If I can describe that independent of that Google Spreadsheet, it flips my perspective and I start seeing opportunities from a different light. Then you say, oh, if I’m going to create software, I need to solve that problem.

It’s a way of being solution agnostic to open up the doors for new opportunities. You literally see things in a different light there. Again, there’s no guarantees in the Jobs to be Done in language, but it helps you find opportunities that you might have otherwise overlooked. If you are talking about your own software, even a brand, even startups, you’re starting to think about the brand, price point, or business models, sometimes that clouds the conversation. There’s red herrings in the room. Who’s going to pay for this, how are we going to brand this, and stuff like that? That doesn’t matter right now. Just what problem are we trying to solve? Let’s really, really understand that problem at a deep level before we layer on our own solution.

Rob: I think for our conversation’s purposes, I’d love to dig into maybe two kinds of stages that a startup founder might be at. One is pre-product, I’ll even say pre-solution where someone says, I want to serve this vertical, maybe I want to build stuff for designers or developers. We can just pick a vertical, maybe it’s home improvement contractors, and then have you walk me through a thought process. Maybe even some questions that you might ask like how would a startup founder who is seeking problems to solve, in essence, how might they go about it?

Then the second stage is what are called Switch interviews, which I read about in your book. I’ve read about them elsewhere, which is where you have a product, sometimes it’s early stage, but it can be much later stage too. You could be a big company into it or Salesforce, but you can also be a startup founder who has a product doing $3000, $5000 a month, you’ve plateaued, and you have enough customers that you can dig in like why did you switch to me?

I have a couple of friends who’ve done Switch interviews and learned a ton about it, and it actually changed the direction of the product. It changed the features in such a way that they wanted it to build. Those are the two things I want to dig in with you today to get pretty practical nuts and bolts.

Let’s start with the pre-product or pre-idea. I know you do workshops on this, you’ve written a whole book. What would you advise a founder to do? What would you do if you’re thinking to yourself I’m a developer, I want to build a SaaS product? How do you start?

Jim: The first thing I would do would be to scope the domain in which I want to innovate. I think there are two fundamental questions there. The first is, who do you want to innovate for? The other one is, where do you want to innovate or what’s the problem area that you want to solve for? Both of those come with multiple answers.

On the first one, the who, what I recommend people do is think about the domain that you’re interested in and just list all of the actors and the stakeholders that are involved. You have a stakeholder map and ask yourself, who’s going to be the ultimate consumer of the value that I create? Try to hone in on who. There might be multiple, but you want to focus yourself. Jobs to be Done come with a lot of focus and decisions. It’s a strategic decision, who you are going to innovate for, and the same on the problem space side.

If you’re looking at CRM, tax, or whatever domain you’re in, there’s lots of problems that people are trying to solve. List them all out and try to get it down to three, maybe just one. We’re going to try to solve that problem so then you have a who and you have a what that scopes your innovation domain. That scopes your innovation domain.

Now what I can do with jobs to be done, as I described in the book, is I can build up a model or build up an understanding of that problem for that person. How do I understand that job that they’re trying to get done in the context in which they’re trying to get it done and I can do something called, for instance, create a job map, that’s a play that I have in my playbook.

The playbook is a collection of techniques, but one of the first best things I think you can do after you decide who and what is to create is a job map. A job map is a simple series of steps that talks about what’s the fundamental process of getting that job done.

It might be listening to music, we just talked about that, or managing contacts and it’s in a CRM, you wouldn’t say the word CRM but managing contacts. You can understand that as having a beginning, middle, and end. How do people get started solving that problem? What’s the middle of it? Jobs to be Done give you a language and the techniques that actually map that out.

Now you have an artifact you can bring back to your team and say, where are we going to play? Let’s put our finger on that moment where the rubber hits the road for us and you can get even more specific there. That’s just an example of without a product on the market, how you would use Jobs to be Done to kind of work your way into what’s our opportunity.

Rob: Got it. I like that for focusing for sure of saying who and what. A few examples sprang to mind, but let’s dive into one. There’s a TinySeed company called Summit. It’s usesummit.com. In essence, it’s forecasting software for startups. I think it works really well for SaaS, but I think any startup, especially bootstrapped or funded, allows you to build pretty complicated models easily. To easily build these models that can forecast out and say, when do I have the budget to hire a developer? What happens if I run ads and it gives us this return? What is the cash flow? All that stuff.

You can imagine the precursor to this is absolutely Excel, there’s just no doubt about it because there isn’t another tool that does it like this. The founder, Matt Wensing, has been working on it. He’s now on the second or third version of it because he built it, people used it, and I don’t know if they hit the edges of it and then he said, okay we need to rework it, we need to rework it. It’s obvious in your parlance that he figured out early on he wanted to cater to startup founders, CEOs, maybe CFOs if they’re at the level that they have that, and what is forecasting or it’s like financial?

Jim: I was thinking about that, actually, as you were talking because Jobs to be Done is a language, and the words that you use really, really matter. Sometimes it takes a while, semantically, literally visiting a thesaurus. It’s something around forecasting. Planning though is the first thing that came—I’m not sure what they’re actually planning. Plan a product rollout, plan a company, I’m not quite sure what they’re planning, but some of the job would be somewhere around planning or forecasting.

Then I would say the who is an entrepreneur actually. I can just describe it generically. Generically, entrepreneurs are trying to plan out their company or plan out their business, and I can take those things and then dive deeper into each of those things.

Rob: It’s funny that you said planning because I haven’t looked at his homepage in a couple of months. I just pulled it up and his H1 is, “Build trust in your plans. Express your financial operations on a flexible canvas.” It sounds like you got there fast.

Jim: One of the things when I work with companies, I’ll go out to their website because through the Jobs to be Done lens, I can kind of see through the gloss of their marketing. There’s a job where that’s a nice job. I look for verbs, plan and build. You might start the main job with the word build. I have to play around with it. What we would do is we would try out a couple of different versions, kind of scope it, where’s our center of gravity, and what’s the best language to describe that? It’d be something around entrepreneurs and then the main job would be something around building a business.

Rob: Got it. If we rolled the calendar back, let’s say, two or three years, maybe before he’d even written a line of code, and he was trying to do some Jobs to be Done interviews to figure out, I know the who and the what is, we’ve just described them. He knows 20 startup founders, easy. Go to MicroConf. You can talk to 20 startup founders in two and a half days. What types of questions? What are the questions that he would have asked? There’s obviously a thread. I’m an interviewer, I know there’s a story, there’s a thread you follow. Practically, what does this look like?

Jim: There are three things that I would be looking for, three types of things. One would be around the process. I’d be asking questions like, how did you get started? What did you do before that? What do you do after that? I would want to uncover that process. Because one of the things that I would want to do is create a job map, which would show building a business or however we define that target job. I would want to show that as a sequence of steps. By the way, the steps are not tasks, they’re more like the sub goals like what are the goals in the process there?

The other thing that I’m looking for are what are the outcomes that people are looking for? These CEOs that you mentioned, the entrepreneurs. I would want to understand their pain points. What do they struggle with? What’s the hardest thing for them to get done? These are the types of questions that I would ask him.

So steps in the process, the outcomes that they’re looking for, and then the third thing I’d be looking for are the circumstances, as I call them. Under what conditions is this easier and harder? Or under what conditions does getting the job done change for you? When it’s a tech business versus manufacturing. When you have a little bit of money versus a lot of money. There might be certain circumstances—factors I call them also—that influence how the job is getting done. The interviews are open interviews, but you would be probing along those three lines, what’s the process? What are the outcomes they’re seeking? What are the circumstances that matter?

Rob: Got it. Okay, that’s a really good framework. That’s in your book, isn’t it?

Jim: It is.

Rob: Once again, that is The Jobs To Be Done Playbook: Align Your Markets, Organization, and Strategy Around Customer Needs. It’s Jim Kalbach if you want to find that on Amazon. I’ve never done Jobs to be Done interviews before having a product or idea, to be honest. I’ve always said, not always, but for about the past 15 years of doing startups, if you’re not solving a problem for a business, you probably shouldn’t build a SaaS company. That’s kind of become the mantra.

I’ve always believed in solving problems, but have never gone about finding them in this way, which I think is really interesting. Obviously, you can save a lot of time. As you said, you don’t have to build an MVP. Eventually, you do because you have to test it out, but at least, this is kind of your customer development/almost market research in a sense.

Jim: I think it’s customer development and it’s about product market fit, but looking at the market independent of the product, which you still might have to go into a couple of MVPs and cycles. But theoretically, what Jobs to be Done does is it gets you closer from the start. You’re going to have fewer cycles of your MVP testing and things like that because you’ve already constrained the direction that you’re heading at. In other words, which part of the problem are you addressing? You’ve already gotten closer there than you might have had if you just threw a dart at the board.

Rob: Now let’s switch it up. That was the kind of pre-product, pre-idea, but then there’s these Switch interviews, which I’ll give you an example. Another TinySeed company, they’re called Churnkey, churnkey.co. Their H1 is, “Personalized cancel flows for a healthier subscription business.” You can imagine, they target SaaS companies and probably loot crate type companies. Widget appears when you click I want to cancel my SaaS account, and then there’s different flows you can build of, do you want to discount, do you want to pause? It’s just a super configurable thing.

As I said, they’re a TinySeed company so they have traction, but they’re not a kajillion dollar company yet. They’re on their way there. They have enough customers. I’m making up numbers, let’s say they have 100 customers right now, and they want to find out what direction they should take their product or what’s working and what’s not. Is that what Switch interviews would be for?

Jim: Yeah, that’s actually a really good place to use Switch interviews because you have a market that you’re serving, granted small, but there are people that have switched over to your solution, even if the solution was paper-based or Excel-based before. It doesn’t have to be a direct competitor. In other words, there’s a switch that happened and they said, okay, we’re going to try this solution.

What you can then do is take those people and reverse engineer their experience to coming to your solution to try to uncover that fundamental job that they were trying to get done independent of your product brand or solution. What Jobs to be Done then it says, okay, great, you’re using our product and you have a current experience with our product, what brought you to our product? It works backwards in a series of moments.

There’s a first moment, a first thought, that’s actually the last thought because you’re working backwards before they came to you. Then you want to go abstract back further, okay, well, what were you trying to do that led you to that thought? Okay, I’m trying to prevent churn. Then you try to go back to what they call the first thought. You’re reverse engineering their experience coming to your solution to try to get back to that problem. What’s the problem in and of itself independent of coming to your solution?

You’re not trying to understand the customer journey. You don’t want to understand their awareness and purchase decision of your solution. You want to know what they were trying to solve, and the switch interview gives you a technique to do that. Once I know that fundamental job, then I can start understanding the problem in and of itself.

Rob: Got it. Let’s say with Churnkey, I did 10 or 20 interviews and I found out the job is that the customer wants fewer people to churn, that they want to save more accounts. Do I take that and figure out what features to build, or do I then do another round of interviews?

Jim: You reverse engineer. I would forward engineer. I know that’s not a word, but I would then use some Jobs to be Done techniques to say okay, what’s the process of doing that thing and use some of the techniques that we talked about in my previous answer around what’s the job map, or what are the biggest pain points there. Have that conversation independent of your solution because you don’t want to cloud your bias by oh, we tried that already, that’s going to be hard to implement, and all these things that are kind of innovation killers. You want to really understand that.

I reverse engineer with switch and then forward engineer before you get to okay, what is the solution going to be to think about that problem independent of your solution for a moment. Here’s the thing about Jobs to be Done, you’re always going to talk about your brand, your solution, and your product. That’s not not going to happen in your organization.

What Jobs to be Done says is let’s temporarily suspend our own biases of the world and think about the problem independently. It’s a moment in time. Obviously, you’re going to think about how you’re going to go to market and what you’re going to build, but it’s a moment in time. Again, what the theory says is that you can see things from a different way and spot opportunities that you might have otherwise overlooked.

Rob: Okay. What I’d love to do is a quick, almost a roleplay, just a couple of minutes of a switch interview. I want to use a decision that me and my team had to make in the past few months. What we were looking for was a simple inexpensive marketing dashboard. All we want to see is how many YouTube subscribers MicroConf has. How many Twitter followers it has, not only today, but like a graph of that. How many people are in MicroConf Connect, which is our Slack channel? How many people are in our Drip email account? It’s just basic marketing things. How many website visitors, that kind of stuff.

We were on a previous solution called Dasheroo and they shut down. They basically were just like peace out. Then I went to Google and I started looking and settled on a solution. I’m not 100% sure we’re going to use them, but we at least have loaded our stuff in and we’re kind of trying it out. It’s called dashthis.com. Anyway, let’s say DashThis or you’re trying to figure out why I switch? What would you walk me through?

Jim: Sure. Since there is a solution at hand, what I would do is talk about you, your role, and your current experience with the product. Rob, tell me about the current experience that you’re having with this new product?

Rob: DashThis does seem to do what we need it to do. It has dashboards, it’s at the right price point. I think a lot of dashboards that I’ve looked at are $200 a month or more, and it’s just not worth that much to us. It’s not that important because we have a Google sheet right now, and that frankly does a good enough job. I think DashThis is $30 or $50 a month and that’s totally reasonable.

Jim: The DashThis, let’s talk about compared to that Google Sheet. What does that do that the Google Sheet can’t do?

Rob: Yeah, that’s a good question. DashThis pulls the numbers automatically. You […] into your YouTube account, Twitter account, or whatever, and it will pull them out versus the Google Sheet. Most of that is a manual process that someone on my team does a couple of times a week. In addition, DashThis is just like a more configurable dashboard and the graphs look nice. Google Sheet graphs are not the best.

Jim: What’s the problem with that person on your team updating the Google Sheet a couple of times a week?

Rob: It just feels inefficient and it’s just grunt work. It’s work that should be automated, it feels to me like.

Jim: Okay. Tell me a little bit more about the automation. It sounds like you’re saving time. Is there anything else that the automation does for you?

Rob: Yeah, number one, it saves time. Number two, it should be 99.9% accurate all the time. Unless there’s a bug, it’s accurate versus someone who can mistype, miscopy paste. I think there are errors that could potentially come up and it’s updated. With Google Sheet, it’s once a week or twice a week. DashThis will be updated in real-time all the time.

Jim: How does that make you feel then when you’re looking at the automated dashboard?

Rob: More confident knowing that it’s up to date and I don’t have to worry about why is there an anomaly here. That there’s a copy-paste error there or something.

Jim: It sounds like there’s almost a trust or confidence issue there too. Is there something also about it being updated that provides more insight than you might not have otherwise gained?

Rob: I’m not sure.

Jim: Are you seeing things in a different way? Are you spotting details in a different way?

Rob: What’s interesting is the graphs are larger, and so I can actually see trends better and I can zoom in. Again, Google Sheet graphs are limited in functionality versus DashThis has more clickability, configuring, zooming in, and all that. I do think there’s an advantage to that visually.

Jim: It sounds like if we can maybe wrap this up, what I would do as a researcher, I would kind of come back and start retracing those steps. We started with a product that you had to get, but then I started to compare that actually with the Google spreadsheet, then we got to confidence, and automation. Then the last topic you were talking about is the inability to pinpoint things quicker as well too.

I would start uncovering that and through multiple interviews, if I talk to the next person, and they say yeah, I have more confidence and the next person more confidence. It’s actually a confidence problem that you’re trying to solve. Now, let’s understand that independent of any solution and forward engineer from that standpoint.

Rob: That’s awesome. Thanks so much for doing that with me. I think that will be really helpful for folks.

Jim: No worries.

Rob: Jim, thank you so much for joining me. If folks want to follow you on Twitter, you’re @JimKalbach. As I’ve mentioned a couple of times, Amazon, Barnes and Noble, wherever greater books are sold, The Jobs To Be Done Playbook: Align Your Markets, Organization, and Strategy Around Customer Needs. Jim, is there anything else you’d like folks to check out?

Jim: Yeah, sure. We have this great online resource called The Jobs To Be Done Toolkit. It’s jtbdtoolkit.com. We have some online video courses, also live training. We do a free webinar every month. Then there’s a library of resources. We have some free downloads there as well too.

Rob: Thanks again, Jim.

Jim: Thanks for having me.

Rob: Thanks so much for joining me again this week. If we’re not linked up on Twitter, I’m @robwalling, let’s connect. As a reminder, next week’s episode is going to have a fun announcement that I’m quite excited about, so I hope you’ll tune into that. Be back in your ears again next Tuesday morning.