EP30 | How Basecamp “interrogate” their customers to build a world-class product

Hey, it's Andrew and today on the show we have Ryan Singer, Head of Product Strategy at Basecamp and the author of Shape Up, Stop Running in Circles and Ship Work That Matters. In this episode, we talk about how Basecamp utilizes the Jobs to be Done framework to gather customer feedback, framing it from a supply and demand angle, and how it helps Basecamp's product team to decide on which problems to tackle first. We also discussed how Ryan goes about finding the right customers to interview, his interviewing methods, or in his own words, his customer interrogation style, and why jobs to be done interviews should never be specifically about your product. Ryan also explained why the cost of running a business is parallel to customer happiness, and he shared his number one piece of advice for anyone who wants to build a product today. As usual, I'm excited to hear what you think of this episode, and if you have any feedback, I would love to hear from you. You can email me directly on andrew at churn.fm. Don't forget to follow us on Twitter and enjoy the episode. How do you build a habit-forming product? We crossed over that magic threshold to negative churn. You need to invest in customer success. It always comes down to retention and engagement. Completely bootstrap, profitable and growing. Strategies, tactics and ideas, brought together to help your business thrive in the subscription economy. I'm your host, Andrew Michael, and here's today's episode. Hey Ryan, welcome to the show. Hey there, nice to be here. It's fantastic to have you for the listeners. I think again Ryan's one of those people that needs no introduction but Ryan is currently head of product strategy at Basecamp. He's also the recent author of the book Shape Up, Stop Running in Circles and Ship Work That Matters. Basecamp itself is a project management team communication software used by over three million accounts. Ryan has worked on all levels of the software stack from UI design to back-end programming and strategy. Over his 16 years at Basecamp, he has also designed features used by millions and invented processes their teams use to design, develop, and ship the right things. He's currently focused on understanding what their customers are trying to do and how to make the product fit them better. So my first question for you, Ryan, is how? What is the very first place you start when trying to figure out what your customers are trying to do? We actually look at ourselves. from the very beginning, we built Basecamp for ourselves because the thing that we wanted just didn't exist on the market. And that's actually still true today. So the core of Basecamp is still driven by our understanding, our attempts to sort of understand the problem, the problems that we have and the problems that come up for us. And fortunately, we have no shortage of problems because we've grown and also the... the sort of software ecosystem around us has changed. So, you know, the first web version that we built for a team of three or four of us back in 2003, 2004 is different than the software that we use now with a team of over 50 and, you know, web version and iPhone and Android versions and all kinds of things. So actually we're primarily driven from that. then of course you can get a little bit off track from time to time in terms of, you know, we actually had a very, very tight, clear, obvious sort of definition of the market when we first started because we were selling to firms who were exactly in our situation. We were a web design firm and we were building this software to manage our back and forth with our clients. Just the painful sort of... you know, a game of telephone where the client gives the feedback to one person who's a different person than the one who's actually doing the design work and then you have to do the work and show it and then kind of get all the feedback in the same place again. It was too easy for things to slip through the cracks. So we built this as this kind of centralized place where all of this conversation about the work was going to happen and everyone would see the same thing, everyone would be in the loop and nothing would fall through. For a while, this was a very simple, easy to understand universe that we lived in because, like I said, all of the other people who were using Basecamp were just like us. Of course, a few years went by and then maybe it was around 2010 to 2012, we started to talk to customers and we started hearing that they were in all kinds of different industries. It had grown beyond that foothold we were hearing from. from churches, from architects, from lawyers, from all kinds of different firms and all kinds of people in different types of industries that we didn't understand. So we did kind of reach a point then where I felt in the dark. I didn't know kind of where to make an improvement or how to make an improvement because there were things that we wanted, but now we had so many customers in different types of industries that it wasn't obvious if we made a change for us that it was also going to be good for them. you know so that was actually where I reached for a tool called job to be done interviews that I learned from Bob Mesta and basically the technique is to to interview it's kind of a friendly interrogation actually there's there's no script and the whole question is you're trying to get at the chain of cause and effect that led up to the purchase so it's not you know what do you want out of out of a product. What do you wish for? What do you hope for? It's none of that. It's all what happened? What did you go through? When did you first have the thought that what you were doing wasn't working? And where were you struggling? What was going wrong? And by figuring out kind of where people were struggling and why they started to look for something different than what they were using before, and then how they eventually made trade-offs and chose Basecamp, taught us a lot actually about what Basecamp is good for and why all these different firms are using it. And so actually doing a period of that research was for me hugely helpful. It was a little bit like I was in the dark and then I put on some night vision goggles, you know, and then I could look around and see what the dynamics were and what was working and what wasn't. And so that helped to kind of clarify my vision of of what was important and what wasn't. But at the same time, there's no formula for this. So you do your best to get a clear understanding of the demand side. And here the demand side, when I refer to that, it's in contrast to the supply side. So usually we're always defining what we're doing in terms of supply. What can I build? What can I make? What is the feature going to be? And even when customers come to us with requests trying to tell us what they think that they want, they express that in supply side language. So the customer will say, can you please add a button for this? Or can you please give me a way to sort like this? Or can you please build a calendar view like this? And those are all solutions. It's all supply side language. And so the work there is to backtrack it into the demand side. And the demand side isn't about a particular solution. It's actually all the stuff, the context around the problem. So what was going wrong? What were they trying to do? What else did they try? Why did it matter then? Why did they live with it for so long before then? And why was that the moment to try and make a change? All of that contextual stuff is what we're trying to understand in order to then make some kind of a judgment of fitness between some idea we have for what we should build next and our best understanding of what is actually important to customers. Yeah, I think that's it reminds me of like that quote with Henry Ford when he says like if they asked him what they want they would say faster horses but I think that quote is really often abused and misused and it's really sort of comes down to like really trying to understand what your customers are asking for so like you say I like how you phrase it from the supply and demand side of things it's not really just about the end results, the features or what they're actually looking for, but what they're trying to get done and what are the problems they're trying to solve. Yeah, the customers, they don't have to make trade-offs when they ask for something. You know, if the customer says, hey, can you please build a calendar into Basecamp? They don't have to make the trade-offs of how much time is that going to take and what else are we going to stop doing in order to work on that? And what does it even mean? Where does it end? You know, we have limited time. We can't just build a calendar forever. And a calendar alone could be an entire business, right? This whole company could just be making a better calendar every day, all day for the next few years, right? There's so many aspects to it. What are the interaction design for dragging an event between different cells on a day view versus a week view versus a month view? Or how do you align people's schedules? And how do you do the different types of notifications to ask for permission to add something to a calendar or to see if there's availability? I mean, it is a huge problem, right? And if we want to look at that and say, okay, maybe we have an appetite to spend at most maybe six weeks on improving the calendar based on what we know about what our customers are trying to do, what percentage of them we believe this is going to... be helpful for and all the different technical issues involved then then what we're in a position where we want to understand this specific specific situation that drove the customer to ask for a calendar so that what we're building is much much less than a calendar or or it's a tenth of a calendar but the whole question is which which tenth you know which which aspects of calendaring what did they need and what was driving that request So if we dig back to the demand side, we can get a definition of that problem that says, ah, this is more about seeing free space for a shared resource at a scale that's at the day or larger versus this is about scheduling meetings and packing and playing calendar Tetris with 30 minutes at a time on a day view. It's a very different thing. Absolutely. It's almost like wanting to know how deep the rabbit hole is and then how many people that it can actually house at the same time as well. Not going down endless routes and product development cycles for a simple feature that potentially would solve the same problem. But the next thing as well that was interesting is that you mentioned that the beginning you started out and I always love the Basecamp story is that you were building a product was specifically for you. You understood the problem extremely well. And I think often this is where the premise starts is people come up trying to solve a problem of their own and in the beginning there's quite strong demand and as they start to grow they start to open up to new markets and to new audiences and then as you very well put it, you felt like you were in the dark. Building a product as well when you were four people made sense and you were building from the context end but then looking at the problems you have today at 50 people, those are vastly different problems to be solved. understand and how do you prioritize the market that you're building for as you start to expand out and not get lost in sort of too many different directions and have a bit more clarity so you talked a little bit about jobs to be done but then in the context of jobs to be done how do you sort of prioritize the actual audience and knowing which jobs from this audience you want to be going after well I don't think there's any type of an algorithmic answer to that really I feel extremely lucky that I work somewhere where we found a problem that we understood enough and that enough people had that a lot of people bought it and started using it and they continue to tell each other about it. I feel like my main responsibility is to not screw it up. And so that honestly, my focus is more about where Not the core the absolute core of the product because we we got lucky you know we found something that was a real problem that a lot of people had and I don't think there's any framework to just to just do that I think that it there's got to be an element of of circumstance and and and good fortune coming together for that to happen But how but but we could have probably screwed it up ten different times by now had everybody run screaming to some other platform you know if we had made enough of the wrong changes so so a lot of it for me is about understanding there's something here that's working you know because we have people coming to us and there's interest and we're over that initial hurdle where something about it works but there are a lot of things about it that maybe don't work or or could be working better or areas where people struggle and they consider switching to an alternative and the interviews allow me to learn where people struggle because struggle is where all new behavior starts. So if I can see why, for example, somebody puts certain pieces of work in Basecamp, but other pieces of work they don't put in Basecamp, then I'm really interested in what... Why isn't that in Basecamp? Why is that in this other tool? And then they can say, oh, well, I tried that, but I can't really do this and I can't do that. And so a part of it is just trying to learn sort of what's working and what's not and then prioritize based on that. When we did the job to be done work, I came out with, I mean, we're lucky with Basecamp because it actually does a lot of things for people. We had literally five different even six actually with a quite small, the last one was fairly small, but we had five or six different clusters of meaningfully different context and outcome that drove somebody toward Basecamp and sort of defined how they valued it. And out of those different jobs that we found, some of them were really attractive in terms of clearly if somebody has this job and they come to Basecamp. they're going to stay and they're going to embed this into the heart of the way that they work and this is going to become sort of business as usual for them, which is good for them because it means that we get to make a good impact on the quality of life, you know, for how they work and how they feel with communicating as a team. And it's good for us because if it's really embedded into their process, that means better lifetime value. So I actually did a kind of ranking of the jobs through that lens. You know, which of these... is something that a job that we're good at doing because very often you know people will reach for you for something that maybe you're not actually good at doing and then that presents an opportunity to better communicate what you're good for and what you're not good for and to kind of filter that traffic coming in and and and and looking at which of these things are make better business sense which of these things are likely to have a more you know a better lifetime value for this customer And so that allowed us to sort of prioritize which things were more important. And at least, you know, I think a lot of this is about what you don't do. So there's a lot of features and enhancements we could build that would cloud the product or start to take it kind of in the wrong direction or dilute it or make it unclear what it's really good at. And we've been working really hard. to clarify for ourselves what the core of the product is and where the work needs to happen strategically. I think it's very easy to go down that path of taking the product in a direction and just becoming a feature factory. How do you sort of gauge a pulse and is this something you're regularly checking in with customers to understand? How far off like the track you've taken your product are there any sort of interview techniques post users starting to use the products that you keeping tabs on and trying to understand people's perceptions and understanding of your tool? Hmm. I think that there's different phases that come and go. You know, I really think of it as as a So for me the job to be done interviews that I did and then the analysis That was a tool that I reached for because I felt lost So when I was in the dark I needed something I reached for a tool and then I used that to get more clarity about what's going on in terms of demand and then I was able to make some priorities Strategically from the supply side if I don't always feel like that, you know, there's so like I'm in a period right now for example where I have I have a lot of ideas about what I'm hoping that we can do in the near future. A lot of things I'm really excited about. It's the opposite of feeling in the dark. I feel almost like a feeling of urgency, like, oh man, this thing, I really want to start building this, really want to work on that thing. And in that phase, I'm not going to drop what I'm doing and go do some research because I've got stuff to build. And as a team, we have a lot of exciting ideas together that we can just go and we can do stuff. But who knows, maybe six months from now, maybe a year from now, who knows, maybe we'll feel differently. Maybe we'll build some of those things and then we'll feel like we won't know what to do next. So I think a lot of it just has to do with sort of taking the temperature and feeling what's going on. at the higher level of the company in terms of where do we have a lot of confidence? Where do we have uncertainty? Because this thing about customers struggle and that's when they look around to get rid of their product that they're using and try something new. The same thing is true internally in terms of how we work as a company. If nobody's struggling at a C-level or a senior level, we're not going to change what we're doing. We're not going to drop what we're doing to go and try and learn. You know, but and this is where I think a lot of people who who are focused on research really have a hard time because they're trying to do research all day and then they're running around the company waving their papers at everyone and everyone says, okay, look, I got work to do like, you know, interesting, but whatever, you know, and then the researcher, the researchers thinking, yeah, but this is so important and nobody wants to listen to me, you know, but then as soon as something happens, maybe, maybe a growth, a growth curve starts to flatten or or something troubling appears in the data or there's a gut feeling of we don't know what to do next or a perception of risk that if we make the wrong move, there might be some ripple effects that we don't understand. It's only when you get into that situation where there's something kind of pushing you toward research that then I'll clear the calendar off and I'll make some calls with customers. And doing this, the jobs to be done method that I learned only requires talking to about 10 different customers. You have to do some thoughtful recruiting so you get a nice variation in who you talk to, but because the interviews go so deep and there's so much data per interview qualitatively, it's like each interview is like a whole terabyte of film, you know, and it's amazing kind of how much you can get with a quick dive back into the customer base when we need that. Let's go a little bit deeper on that. So you mentioned like around 10 people you don't need to speak to. You're very thoughtful in terms of who you're targeting. Like what would your targeting process look like? What would some of the criteria that you'd wanting to be pulled out to get this audience? Well, so the first thing is we need to have some sort of a sense of what is the question that we're framing. We have to know what we're going after to some degree, right? We're not just gonna go talk to anybody and say, you know, what happened? Like, why did you buy Basecamp? So for example, we had a, when we, when we did the, when I did an earlier round of interviews, maybe a few years back, a huge question for me is, I want to understand what is, what is the same across industries? that's leading people to Basecamp. So I don't want an explanation of why a web designer uses it and why a lawyer uses it. I'm looking for the overlap. What is it about Basecamp that's drawing both of these? And that's sort of the high level, like what does Basecamp do for them? And what is the competitive set even? What are they even switching from? So I had very broad questions there. And so when we did those interviews, I wanted to actually try and talk to some people who were from some different, who were in different industries. So, you know, we were talking to a doctor, we were talking to somebody who runs a vet, we were talking to somebody who does restoration from people's homes were damaged by fire. We did, when we talked to some web design people, we talked to some contractors of different kinds. I mean, it was really a big spread. Later on, we had some different questions coming up about iPhone behavior. We had some very tricky questions about the UI. You know, it's interesting. You get down to that really tiny real estate on the phone and you have to make even more trade-offs about sort of what to elevate and what to push back in the interface, you know, because there's just isn't that much room for stuff. So you have to figure out what's a feature. And we had some questions about when, in what situation is someone reaching for the phone to add a to-do on the phone? And why would you add it to do on the phone instead of on your computer? And because we wanted a deeper understanding than I'm not at my computer, right? Because you will be at your computer later. So which tasks do you kind of hold back for when you get to a computer? And which tasks don't wait for that and they happen right there and then? And then where do they struggle with that? Where are the struggles around that? and so for that case we we needed to specifically recruit people who who were using the iphone you know who um who who had been we didn't necessarily need to speak to people who bought the app so before we were recruiting people who we knew were the the account owner versus here we it wasn't necessary to recruit based on whether you bought the app or not the the mere fact that you were um that you had the app and you were adding to-dos was enough. And then there we really wanted to get a good spread of, we didn't only want to talk to people who were adding to-dos all day from their phone. And we also wanted to talk to somebody who added a to-do maybe once on their phone or a handful of times, and then didn't do it again. And then there's also the question of how often do they do it on the desktop. not and that gave us that plus a little bit of a mixture mixture of talking to people from different industries and stuff like that we ended up with something like eight different dimensions actually that we were recruiting on which sounds a little bit fancy but it wasn't that big of a deal it was just a few different things to make sure that we considered in our surveys when we when we when we sent those out to customers to ask them to talk to us Very interesting. So really starting off with something specific that you want to understand and from that just looking at the dimensions that you want to be able to break down that problem or break down that understanding by. You've mentioned a few times now interrogations and I like it as a concept as well of like really trying to get insights out from your users and really being thorough in the research methodology. What is your typical process sound like? What are some of the questions that you're asking that you tend to find or be able to get some of more of those meaningful insights out of so you're not asking just generic questions like you said of Why did you purchase base camp? What are some of like your go-to questions in an interrogation? So This is a whole subject of actually learning how to do these interviews the thing that is I'll make a comparison. If you think that someone performed a crime, let's be dramatic and say murder, you don't have a standard question. You don't have a list of questions that you ask. Did you do it? Why did you do it? These aren't the questions. The questions come from trying to to figure out what actually happened. So where were you the night of the 13th? You know what I mean? This kind of a thing. On Friday. Yeah, were you at home or not? So it actually, it's all about figuring out what the actual story was. So we start with, there's a fundamental criteria that if we want to learn about purchase, then we only talk to people who actually made that purchase. So we're not doing any speculative behavior, no hypothetical behavior, only people who've actually been through the process of making the trade-off and deciding. Because before you actually buy, what you think your needs are and what you think you want is very different than what you end up buying very often. You go looking for a car and what you think you want changes as you go through the process of learning. So, um, so we only talked to people who actually did the thing who actually made the purchase. And then the first question is simply, um, so where, uh, you know, when did you buy, you know, and it was, yeah, I think it was, you know, maybe about a month ago and what was going on around that time? You know, why, why then? Right. And, uh, and then when did you have the first thought and, uh, and then we kind of build up a timeline from first thought to, cause nothing happens randomly. There's a whole series of dominoes that have to fall for somebody to change their behavior or make a purchase. So it starts with the first thought. Then from the first thought, you go into a phase which is like passive looking. So first thought with a car would be, you've got a car that has quite a few miles on it. It's starting to get older and it starts to make a funny noise. You think, hmm, not sure, am I going to want to repair it? Is it time to get something new? But something... something is not the same as it was before. So you have the first thought. Then you start to actually notice cars again on the road. There's this period where you don't look around at them at all and then all of a sudden you're noticing which brands you like and which ones you don't and colors and you're seeing all kinds of things and you remember your friend gets a car and you ask them a few questions about it because suddenly you're interested. So this is like passive looking. You're not actually going to a dealer. You're not actually doing setting aside time in your life to do research but you're noticing right yeah and then and then some kind of an event happens that that kind of kicks it up that that that makes you uh more interested in solving it so it can be um that the sound starts to get worse or it could be that you hear about a sale that's coming up but something happens that's that's sort of time bound where you think uh you know what i really should actually figure this out. So then you go and you go into active looking and that's where you might do some Google searches or you go to a dealer or you talk to a friend who's very knowledgeable and you're trying to actually shape for yourself what the outcome is that you want and what trade-offs you're going to need to make to actually get this thing done. But then you still haven't decided and usually there's a final event, there's a second event that needs to happen to really create a time pressure. So that might be that There's a friend is getting married and you want to go visit them and you were planning to drive there, but now that your car is making this funny noise, you're afraid that if you make this long drive to this wedding and this, you know, you're gonna maybe drive a few hours that you're gonna get stranded along the way and you think, I can't let that happen. Like, I've got to make a decision here. I've got to get this done before the wedding. So now you have a certain kind of urgency that pushes you to make the trade-offs. Because until you have to make a decision, you kind of want everything. You want cheap and you want fast and you want horsepower and you want style. And you know what I mean? But then once you actually have to make that decision because you're running out of time, then you say, okay, what's actually important to me? And that's where you make the trade-offs. And then you decide. And then after the decision comes, actually all leading up to the decision is where satisfaction gets defined in the mind. So you're making a lot of trade-offs in your mind about what you think this is going to do for you and why it's going to be better and what the outcome is going to be. And then you actually pull the trigger and you make the purchase, you make the decision, and then you have the final phase, which is consumption and satisfaction. And then in consumption, you get to compare, is the outcome what I thought it was going to be? And then that's the definition of satisfaction. So this is a process that... I learned this from Bob Mesta in his work and he's done work with Clay Christensen on this. The best book that is a short intro to it is called Competing Against Luck. And there's also, I mean, it's a big subject. There's also a variety of forces that people experience that kind of pull them through this process. But the thing is that there's no question to ask in particular. You actually learn kind of how to dig the story out by when was the first thought, okay, and then what happened, and then okay, but you know, you didn't, there's a hole in the story here. I'm not understanding it. Like how did, why that day? You know what I mean? And kind of pushing and pulling and interrogating and then through that we can get a sense of what went wrong. what were the so-called pushes, the things that were happening to them that they didn't like, that they were hoping to get rid of, like the, you know, I've got this wedding coming up, I don't want to get stranded on the road along the way, this noise is making me nervous, like all these things. And what were the pulls? What were the things that they wanted as the outcome, you know, that I'm going to be able to... is it might be more social it might be like i want the bigger vehicle because then i'm going to be able to road trip with my friends and we're going to have this time together or it could be more emotional like this the car is the place that i go to be alone and i want actually a very tiny little car and i where no one else will fit and maybe that has a little extra horsepower and this is going to be my place that i'm going to um to get my peace of mind, right? Like very, very different criteria, different definitions of value depending on the circumstance that they're in. And so that's kind of what we're pulling out of the interviews. And then by doing that over a series of interviews, we can actually code out the different pushes and pulls and habits and anxieties that were present or not present in each story and then do some clustering on that to pull out patterns. And then What we'll always find is that there are definitely patterns where there are different reasons that bring people in and different outcomes that they seek and those cluster them together into different jobs. And then we come out of that with that's where the analysis work is. And that's when they arrive on your website and they see a header on fire and saying, we've been expecting you. Exactly. Yeah, that's where that came from. I love that. So it's as well like what you're describing as well over and above like the jobs to be done is really like the full buyer's journey and I think this is often like something that's it's pretty difficult to map out but the way you laid out in terms of like the interrogation process really like understanding what is that like initial thought process what triggered it to begin with and then just pushing harder and harder to find the exact steps that led to the process. And the key thing is that we're not talking about the product. The whole thing is about their process of figuring out what progress is for them and what trade-offs they're going to make. It's not about the product. And that allows us to create this kind of empty space where the product is going to go. And that's what it feels like to have real design requirements. they're not telling me I want you know I want this button and that button and I wanted to do this and I wanted to do that they're saying when I'm in this situation these are the things that matter right and this is what progress is and then when you understand the situation and the progress in the situation that they're trying to make then then we can take that as design criteria and go away and come up with all kinds of different solutions and try and put them into that slot to see if they fit or not We actually doing product strategy and not just churning out feature of the feature totally I Love this process and it's definitely something like we have also followed base cam quite closely and seen how the jobs to be done framework has really been pushed to the max with you guys but The next thing I want to think about this then is like looking at it through the lens of churn and retention now, so How can the jobs to be done framework help when it comes to looking at churn and retention and trying to turn things around within a business? Well, I have to say that I haven't been in the situation where there's been a churn problem. And so I haven't had to solve that. So I'm aware of the fact that Bob and some other folks have done Really deep work on that using using them using that methodology, but I haven't been part of it So I can't really speak to that you can't yeah So you've been in lucky a fortunate position where you've like you say you've really found and nailed that product market fit to begin with Although at times maybe you strayed off a little bit you always managed to pull it back into to get to the point where it wasn't impacting Yeah, I mean we we have people I am working on that proactively So through the interviews and through talking to people, I'm trying to learn where are the things that go wrong in the app that lead them to think about other options or what are the things that they're complaining about? It just hasn't reached a level where it's like we have a churn problem and we have to go attack that. We're kind of working at it very proactively. So it's not that we're just floating around in the sky. you know, just half asleep because everything is fine. We are constantly paying very close attention to how things are going and trying to make the right next move about what is the right thing to build next and what is the thing to improve. We're very, really focused on that. It's just that it's from a proactive place. Absolutely. I think like and through all the episodes that I've recorded so far the podcast I think the absolute best place is like the prevention is better than the cure. Like so with the way that you focus as well like I'm really trying to understand what to build like who is our target audience like really having that clear clear crystal picture. you're able to then go and sort of almost eliminate churn on the other end because you've really spent that time like trying to understand who these people are what are we building for them and not just focusing on features and like becoming a feature factory and the other aspect of that is and here i'm i'm kind of quoting jason base camp's founder because this is more from his experience than mine but he often talks about how important the cost side is that if costs are low, then the urgency is going to be lower if there's a challenge. But if you hire a bunch of people you didn't need to hire and you have a whole bunch of complexity that you didn't actually need, now if your costs are too high, then as soon as there's a problem, man, you have an instant crisis. Versus if costs are low and now you're seeing that the the charts are starting to tip a little bit in the wrong direction you've got time yeah that's huge that is so important and so undervalued you know i mean base camp could be 10x or way more than the head count that it has right now yeah easily and and we'd be in a whole different world and we'd be feeling an entirely different urgency whenever we see uh the the the the derivative of that of signups or whatever tilting one way or the other you know And so that's huge. Yeah, I think it's incredible what Basecamp has been able to achieve with the team size that you are and over the years being able to stay so nimble and small. Well, that brings us, I think, to another really important aspect with all this, which is that there's no cookie cutter answer for strategy, right? We all have to figure out for ourselves what's going on in the market and where the demand is and how we can address it and what we can offer. At the same time, if we don't have a really strong shipping muscle, if we can't reliably set a target and then go after something and build it and finish it in the amount of time that we wanted to spend on it and ship it and move on to something else, if we don't have that muscle, then it doesn't even matter how good our strategy is. We can have the best idea in the world for what's going to reduce churn, but if it turns into some never-ending project or we have too much technical debt and then we have all kinds of quality issues, then we're not going to be able to reach that outcome. It's really important also. I think the cost side is a condition that needs to be in place so that we can be healthy and we have room to think. At the same time, we need to have this shipping muscle. my new book Shape Up is all about. How do we actually define projects? How do we choose what to bet on? How do we set the expectations around our bets so that we actually work on the thing that we said we were gonna work on and we don't work on something else? How do we stop when we say that we were gonna stop and not have these kind of never ending projects? And how do we give the teams the autonomy to actually build this stuff themselves without having to hold their hands the whole time? And that frees us up as people who feel responsible for the strategy or where the product is going to keep thinking about what to do next, you know, instead of kind of being stuck in the day-to-day operations of trying to get stuff built and trying to make decisions on the ground all the time. Yeah, I'm not going to ask you how do you do that because I think everybody should go out and listen to the book and read it themselves. But I'm going to ask you one last question, I think as well for today, Ron, because it's been... Pleasure having you running up on the time now. If you had to give like one piece of advice to somebody going out now in this new market in the today's age with sort of the ability to build and create products very easily like what would be your number one piece of advice for somebody wanting to build a new product today and compete in this today's markets? I don't know if I can reduce it to one point. I mean, there's quite a few things to bring together, I think, to do well. If there is one point, I think it is don't follow what the big companies do as your model because a bigger company is not... Very often, you know, you think of a, you look at a Facebook or you look at an, at, at, at whatever, some huge company and, and you, you think that they're successful. So you think that you should do things the way that they do it. And that is a huge mistake because they are in a completely different universe with totally different constraints, with totally different problems because of their scale. And when it comes to scale, more isn't better. More isn't even more. More is different. It's a different world. And if you try to use what they used, whether it's how you organize the business, whether it's the technology choices you make, whether it's the process choices you make, you're going to fall on your face because you're incurring all kinds of costs that you don't need to bear at your small size. So just for example, a lot of people are... A lot of engineering teams are using feature flags. So they have a single code base and then all the development work that they're doing is all together in the same master code base and they have to constantly manage kind of which features should be displayed to customers and which one should be hidden because they're still under development. You don't have to do any of that. So many teams are doing that because giant teams do that because they have a hundred different teams that are all working in parallel and it's not possible to integrate otherwise. but we use very long-running separate feature branches that we merge at the end of six weeks and there's no problem with that and life is way simpler and it's way easier to manage because we're not copying them, we're doing what's appropriate to our size. Same thing with all of this stuff with single-page apps and React. I see so many startups building in React or some other sort of single-page tech stack, and they are paying a huge penalty for that. That is not for no upside. If you use a technology like that, you are blocking yourself off from having designers work directly on the app because the designers can't just provide, let's say, HTML and CSS for a web app if it has to get turned into this complicated components JavaScript stuff. So you're putting this big wall between the designers and the programmers for no good reason. HTML over the wire is perfectly fast and perfectly suitable for 90% of projects. And for us, that's a technology choice that we've made that has a, I'm sure it has a 10x difference in our productivity, massive. Same thing with phone apps. We don't need everything that we do to be super native with a fancy animation. Our apps are actually... 90% hybrid where we use a little bit of native code and interaction in the most essential places where you really need speed and responsiveness. But those are just a few places that mainly have to do with navigation and notifications. And for most of the app, we're reusing the web views and we've built a lot of glue to enable that. And that again is at least a 10X difference in productivity. So there are so many things and also the way that we're organized. We don't need to have a whole lot of complicated charts and dependencies and roadmaps. We're a relatively small company. We can just put a few people together and trust them by shaping the work and giving them clear boundaries and then leaving them alone, uninterrupted to build that thing. So find a model that's your size that's successful and do the things that make sense at your size and that way you don't handicap yourself with a lot of complexity that isn't valuable. I love that. I think it's amazing advice and it's definitely something I've never really said to think about before, but it makes total sense in the way you describe it and the way you run through it. So, Ryan, I just want to say a huge, huge thanks for joining the show today. It's been a pleasure. Before we go, is there anything you want to leave the audience with? Maybe you want to let them know how they can keep up to speed with your work and how they should be following what you're doing at Basecamp. Yeah, the best place to keep up with what I'm doing is just on Twitter I'm rjs on Twitter and then the book shape up is at base camp comm slash shape up you can read it online on the web there you can download it as a PDF right now and we don't even ask for your email address and We're having so many interesting stories from people who are Changing the way that they that they define projects and build projects and how they schedule work and everything like that as a result of that And if you're one of them, I'd love to hear from you. You can email us about your experience trying all this stuff at shapeupatbasecamp.com. And it's been really fun to have this back and forth with everybody as they improve the way that they work. Awesome. Well, thanks very much, Ryan. It's been a pleasure having you today. I wish you best of luck now going forward. Thanks so much. And that's a wrap for the show today with me, Andrew Michael. I really hope you enjoyed it and you're able to pull out something valuable for your business. To keep up to date with churn.fm, and be notified about new episodes, blog posts, and more, subscribe to our mailing list by visiting churn.fm. Also, don't forget to subscribe to our show on iTunes, Google Play, or wherever you listen to your podcasts. If you have any feedback, good or bad, I would love to hear from you. And you can provide your blunt, direct feedback by sending it to Andrew at churn.fm. Lastly, but most importantly... If you enjoyed this episode, please share it and leave a review as it really helps get the word out and grow the community. Thanks again for listening. See you again next week.

Today on Churn.fm, we have Ryan Singer, Head of Product Strategy at Basecamp and the author of Shape Up: Stop Running in Circles and Ship Work that Matters.

In this episode, we talked about how Basecamp utilized the Jobs-to-be-done framework to gather customer feedback, framing it from a supply and demand angle, and how it helped Basecamp’s product team deciding on which problem to solve.

We also discussed how Ryan goes about finding the right customers to interviews, his interviewing methods, or in his own words, closer to “interrogation,” and why jobs-to-be-done interviews should never be about your product.

Ryan also explained why the cost of running a business is parallel to customer happiness, and shared his number one advice for anyone who wants to build a product today.

As usual, I’m excited to hear what you think of this episode, and if you have any feedback, I would love to hear from you. You can email me directly on Andrew@churn.fm. Don’t forget to follow us on Twitter.

We covered:
- Finding out what customers really want by using the Jobs-to-be-done framework 
- Seeing customer’s feedback as “supply and demand”, and honing on the precise problem to solve 
- Ryan’s mindset when it comes to prioritizing the “jobs” gathered from Jobs-to-be-done interviews
- The targeting process Ryan used to recruit Jobs-to-be-done interviewee
- How a product success team handles different feedback from various buyer personas
- Ryan’s go-to method when “interrogating” customers for feedback
- Using an analogy of “buying a car” to elaborate a buyer’s journey and analyzing the customer interview
- How Ryan constantly monitors customer happiness to prevent churn 
- Why the cost of running a business is parallel to customer happiness
- Ryan’s #1 advice to someone who wants to build a product.

Mentioned resources available here:
https://www.churn.fm/episode/how-basecamp-interrogate-their-customers-to-build-a-world-class-product-using-the-jobs-to-be-done-framework/

Subscribe to our newsletter to get exclusive updates:
https://www.churn.fm/episodes/

or follow us on Twitter: https://twitter.com/churnfm