Subscribe
Share
Share
Embed
Customer relationships don't have to last forever. Keeping your hands wrapped around every customer will only lead to trying to evolve into something you're not is the death knell for your business.
Show Notes
Customer relationships don't have to last forever. Keeping your hands wrapped around every customer will only lead to trying to evolve into something you're not is the death knell for your business.
Today, Jason Fried and David Heinemeier Hansson discuss the idea that you should let your customers outgrow you from their book, Rework.
Show Notes:
[00:32] - Why evolving as your customers do is a death knell for your business.
[01:37] - David shares why, as a software design business owner, you need to be the voice of the people who aren't your customers—yet!
[02:31] - By building in all the features your existing customers want, you are closing the door on what makes things turnkey for new customers.
[03:24] - Not every customer relationship has to be forever.
[04:55] - Jason shares why your product needs to evolve no matter your business size.
[05:39] - Why it's important to gear your improvements on behalf of everyone and not a few outliers.
[06:39] - How pricing models differ based on size - both of you and your customers.
[07:49] - We don't have whales because we don't have the sales cycle to hunt whales.
[10:38] - Keeping your hands clasped around every customer vs. knowing when to let them go (or grow).
[11:46] - We don't want to change our business to support companies much bigger than ours, but your mileage may vary.
[14:26] - The lackluster appeal of committee-driven software development.
[16:31] - Jason shares why doing anything easy requires a lot of work.
[18:13] - David shares why 37signals is in the business of designing software for an audience of one.
[19:11] - Wallet-based feedback is the best feedback you can get.
[20:03] - "The only kind of software that is out the gate great is software built for the people who've worked on it."
[21:19] - We are putting together an "ask me anything" episode. So if you have a question for Jason and David, leave us a voicemail at 708-628-7850.
Links and Resources:
Do you have a question for Jason and David? Leave us a voicemail at 708-628-7850
Do you have a question for Jason and David? Leave us a voicemail at 708-628-7850
Creators & Guests
Guest
What is Rework?
A podcast by 37signals about the better way to work and run your business. Hosted by Kimberly Rhodes, the Rework podcast features the co-founders of 37signals (the makers of Basecamp and Hey), Jason Fried and David Heinemeier Hansson sharing their unique perspective on business and entrepreneurship.
Kimberly (00:00):
Welcome to Rework a podcast by 37 signals about the better way to work and run your business. I'm your host, Kimberly Rhodes. We recently talked on the podcast about the benefits of being a small business and that at 37signals we love small businesses, but in their book Rework, Jason Fried and David Heinemeier Hansson write about the need to let your customers outgrow you as opposed to changing your offerings as they grow. They even say that's how your company starts die. Guys, that sounds a little harsh, but let's, let's talk about it. You want your customers to outgrow you.
Jason (00:33):
Well, the, I think the point we were trying to make in this particular essay is that what ends up happening is that companies start on the low end or offerings typically start simpler, um, you know, broad base and then they get customers and those customers keep wanting different things as the customers grow. And at some point you can go up market to, to the place where you no longer, uh, allow new people to come in because what you're offering now is not what you used to offer. What you're offering now is a far more complicated product for completely different kinds of customers than you had in the beginning. Um, and I think that's something we've always tried to avoid as best we can, which is basically not letting the elevator get too high, that you can't jump on the on, on the ground floor and get into the product. I think that's, that's at least my recollection of, of the primary message here. Um, there is also this sense of of wanting to chase or to keep, uh, customers. And the way you, you typically do that is by making it hard to cancel, um, with, with all sorts of retention strategies that, that just don't feel particularly good.
David (01:37):
I think the key thing for me here is that the customers you hear from the customers who've been with you for a long time are going to be your most vocal customers. That's just the nature of things and in many ways it's great. It's great. You hear from long-term customers, you hear what they want, um, you hear what they'd like to see changed. But as the owner of the business, you have to realize that if you only listen to the customers you already have, you're not listening to the ones you don't have yet. And those needs can diverge quite dramatically relatively quickly. As a business owner, as someone designing software, you always have to be the voice of the people who have not signed up yet. And it's so easy, for example, in Basecamp situation to give up on like our long-term recognized value of just being easy to use.
(02:31):
Um, this whole idea that you don't need a manual that is just, you can drop someone into a Basecamp that can get going with it right away. There's not a bunch of things that need to be explained. But if we listen to all the customers we currently have and all their needs and wants and feature requests and we built all of it, that would no longer be true. We cannot build a product that listens to every existing customer and their wants and end up with something that new people can still drop into without having learned everything upfront. So I think that's the key in terms of, uh, of features. The other thing is just sheer size ,that Basecamp's bread and butter is the small and medium size companies and some of those small and medium size companies end up being large companies and someone might have signed up for Basecamp when they were 20 people or 30 people and suddenly they're 2000.
(03:24):
And they might find that the needs of a company with 2000 employees is a little different than the needs of the company with 20 employees. And if we kept chasing that size and those kinds of customers, we'd be moving away, which we talked about this I think a few weeks ago, is actually what happens to a lot of software companies as they chase the business model of enterprise software. They keep moving, as Jason says, upmarket, they keep chasing the bigger accounts and the desires of bigger accounts and the small customers, the 20, the 30, the 50 people companies or even smaller than that, they were just a stepping stone. And now we're on to onto the next thing. We didn't wanna end up in that direction. So part of this is to have the humility to say like, hey, do you know what base can be, can be great for a company for two years, five years? But it doesn't have to be an eternity. Doesn't have to be forever. Not every single customer relationship has to be forever. And it's not always sad when it ends. Sometimes it's good. Sometimes we were the perfect piece of software for them at a current stage in their life cycle and then they ended up being much larger or needing very different things and we'd like, that's awesome. There's different software that serves that.
Kimberly (04:39):
Well, I would imagine for you guys, like there's a, a fine line between taking the stance of like, this is what we do and this is the only thing we do, but also continuing to make updates for customers who are, who are wanting that. Like how do you guys balance that?
Jason (04:55):
Yeah, this is a bit about what David was getting at, which is like this idea of innovating on behalf of the customer base as a whole. Basecamp gets better all the time in significant ways. I mean, the last year has seen just an enormous improvement in the product, as we've moved to Basecamp four and every six weeks or so we're releasing new stuff. Some of this stuff is, is improvements on existing features. Some of it is new stuff, but it's always getting better. Just because you serve a small, medium size businesses doesn't mean your product doesn't get better. It needs to get better. They're demanding customers as well as they should be. They're paying for something, they should expect it to work well and get better with them as well. But the kinds of things we're doing are, are more tailored for companies, you know, 20, 30 people or 50 or 60 or 70, but not, you know, a thousand, 2000.
(05:39):
'Cause that's a different feature set. When you're talking about a thousand, 2000 or more, you're talking about far more administrative headaches and more administrative features and more control. That's not really what Basecamp's about. It has the administrative features and the control that it needs for a smaller business, but it doesn't need significant levels of those, those kinds of things, which is what large companies really, really do need. So there's plenty of room for improvement and there always is improvement, but the improvement is sort of contextual around the customer base and the ways we can help people. For example, we just launched card table, which is our take on kanban. This is incredibly useful for a company of three or four or five people. It it's not something that only is gonna be used by bigger companies. So I think that's where you need to be careful not to keep, um, building the things that only a small fraction of your customer base can use because they happen to be the ones that pay you the most, which is one of the other reasons why, you know, typically our customer base all pays us about the same.
(06:33):
Um, and that that helps you sort of think about innovating on behalf of everyone and not a few outliers.
Kimberly (06:39):
So my question for y'all, how does this concept of letting your customers outgrow you play into this kind of pricing model and pricing experiment you guys are doing? Or does it at all?
David (06:51):
I think part of it does relate to pricing in, well, not just pricing, the whole sales cycle. The needs of that company with a thousand or 2000 employees or even just hundreds and hundreds of employees is just different. Once you get to that level, you buy software in a different way. It's a completely different sales cycle. It's much longer. It's based on negotiations, it's often based on account management. It's certainly based on sales and we don't have any of those functions. We don't have sales, we don't have negotiated prices, we don't have any of these things that fit the larger enterprises. And to be frank, we don't really want them because in part that takes the company towards prioritizing and embracing the biggest customers in terms of headcount because those are also then the biggest customers in terms of revenue. And we don't really have that.
(07:49):
And it was one of the things that for a very long time, I think scared us off trying something like per seat pricing because we were afraid what will happen if someone shows up or a bunch of, or a handful of companies show up, they're very large, they'll become our biggest, most dominant customers and suddenly we'll feel trapped. We'll feel like we have to serve them first before we serve anyone else. And we thought that's not the kind of company we want to build. But I think what we've realized both through this experiment and in general looking at our customer base, that we have natural protections against that we just don't land the whales because we don't have a sales cycle to hunt whales. And if you don't go on hunting the whales, they're not just magically showing up in your small fishing net.
(08:32):
That is not how it works. So I think the sort of fork in the road where you either serve small and medium size companies really well, or you serve the large enterprises really well, falls naturally in a way that it is not hung up so much on the pricing model specifically, even though we've now gone to per seat pricing, it's not like we've ended up with a, with a ton of whales. Um, and it's not like, even though in fact our own old pricing model was an other steal a robbery, even if a large whale signed up for it, they would get away with having perhaps a thousand users on a system that cost, uh, a hundred dollars a month. And I think that itself sent a signal that like, you know what, there's not complete compatibility here. These large enterprises can't actually buy an operating system for their whole company for a hundred bucks a month.
(09:25):
It just like, it jars with the whole self-identity of the kind of company we are. No, no, we have a purchasing department, we have people who negotiate with vendors and they sent them long checklists of whatever security questionnaires or or whatever else you have. There's a process. We're supposed to follow the process. You can't just sign up for something really important and put it on your damn credit card that's not compatible with our self-image. Like it's too cheap. And that's a thing that that exists, right? Our software is too cheap to some extent even still at the per seat model, but perhaps more so because we don't have the affordances, the the salespeople and all the other stuff just don't appeal to it. And some companies would look at that and go like, wow, that's a major deficiency. Why wouldn't you land? Want to land the biggest whales? Why wouldn't you want to hunt the biggest game? And we're like, we're fine not doing that. We are incredibly at peace as we talked about in in the small episode, we're saying like, do you know what this is our, these are our people. The the three, the five, the 10, the 20, the the 40, the 50, not the 500 so much. Not the 5,000 and uh, hundred percent not the 50,000.
Kimberly (10:38):
Well I would think there's probably some small businesses who are listening who are like, I don't wanna lose any customers. Like I know the concept, let your customers outgrow you build what you build for people who are starting out and then they might graduate to something else. But I think for someone who's listening who thinks like, I wanna keep 'em all, like do you guys have any advice or it's, I think it's kind of a fear, you know, the scarcity fear, trying to hang on to everything versus like knowing when to let go.
Jason (11:06):
Yeah, I hear that and I, you know, you feel that at times as well, like why someone's been with us for six years. Why first of all I should say we don't want anybody to leave. It's not like you want them to leave, right? Sure. So, so it's not, it's not that so much, but um, unless, unless we're just not able to serve them as well as they want to be served, you know, for x, y or Z reason. I mean, if there's a point where you go, you might be better off somewhere else if these are the things that you need and this is what you require. So that's fair. I mean you don't, again, we're not hoping people leave, but we understand why people do it. I think at the end of the day, it's also just a matter of you gotta factor in the cost of, um, everything else we've said, which is you don't want 'em to leave, but what does it cost to keep them?
(11:46):
And if it costs you a significant change in your business, that's a decision you have to make. It's not that it's the wrong decision, it's like that's a decision you have to make for your business. We've decided that we don't want to change as a business to support much larger companies that we are, we don't feel related to or connected to. And when we talk about large, you know, hundreds and hundreds or thousands of people, not like 50 or 60, 70, 80, there's zillions of companies that have fewer than a hundred people, which is what we have, which is, which is our bread and butter. You know? So I think you just gotta figure out what the costs are and if you're willing to take 'em on, and I think people typically would think there are no costs. Keep every customer you have, do everything you can to keep every customer and that comes for free. But it, it doesn't. And I think that's, that's the thing that you have to recognize. Yeah,
David (12:32):
I think you make a choice either way. You don't get to not choose by trying everything you can to, to keep everyone right. That is a choice in and of itself. And it's going to, particularly once you embrace the whales alienate the smaller companies, that is just the, the nature of things there. There's not another way. Um, so I think simply accepting that you, you have to make some sort of choice. Most software companies, particularly the ones that have raised venture capital or and are going for IPO or something else like that, they've kind of put their playbook out there. What happens is they use the small and medium sized companies as the stepping stone to bootstrap an enterprise sales cycle. And once they reach the enterprise sales cycle, that's where the focus is. And you know what I, I mean there are the Fortune 500 needs software too.
(13:25):
Great for them that there are vendors out there who I, I mean that like literally it is great for them. There are vendors out there who focuses on the big whales. That is great, wonderful. It's not us. And I think just being upfront about that is what's so startling when we talk about the Fortune 5 million. We're talking about it in contrast, in contrast to the Fortune 500 because as we said, the choices either way, where does your focus lay? What is your tribe? Who are the kinds of, uh, customers that you feel connected to that you're working on behalf on that you can intelligently design for? I think that's the other factor here that's important is we design the best software possible when we design for a situation we can relate to. I cannot relate to running a company of 5,000. It is just not the layers, the management, the processes, everything that goes into running a company.
(14:26):
I have no connection to that. I have tremendous connection to a company of, of five people. We were there for years and years and years. We built much of Basecamp at that size. I have tremendous connection to, to the company of 20 where we're there for many years and now we're at, uh, at around 80. So there's sort of that natural sphere of experiences that you've had and experiences that you relate to that you can adequately design on behalf of. And then if we were to go into trying to design software for the 5,000 or the 50,000, we'd be imagining things or worse we'd launch into the kind of software development that plagues a lot of enterprise software developers, which is sort of client, well I was about to say client driven. That sounds positive. It's, it is more like, um, designing on, on direction of someone else that tell me what you want me to build.
(15:22):
Just tell me, I can rank your feature requests in a nice spreadsheet and we'll work on the one first that has the highest number of votes. And like, do you know what that committee driven form of software is not something I generally find pleasurable to use. There's a reason why for a lot of people enterprise software has a stigma and that stigma is usually hard to use, designed by people who don't have to use the software because it's bought by people who don't have to use the software. And those are some of those core incentives that end up distorting software in a way where it's like, you know what, this is, this is not great. So we design on our behalf on the experiences that we've had and that connects really well to the Fortune 5 million, not too well to the Fortune 500.
Kimberly (16:07):
So I'm curious cuz we've been talking a lot about Basecamp and that kind of target audience, but Hey, a whole different animal as you're building a second piece of software with an a more global audience, I would say not necessarily small businesses, but individuals, are you thinking about that customer and how that customer might outgrow you at some point? I know I'm putting you on the spot with this random Hey question.
Jason (16:31):
No, it's good. I think, I think Hey personal is, is you know, for the individual, so like the individual is the individual, they don't grow out of themselves really. I mean, you know, right? I think your, your email quantity or whatever is basically pretty fixed. You know, once you've been doing this for a while, you have a pretty good sense on the business side though. Um, Hey for domains, which is the business version, um, is, is definitely still tailored for smaller companies. It would be highly unusual to have a company of 700 people move their email over from Gmail to, Hey, it's just, it's not gonna happen. Yeah, it's literally not going to happen and therefore we haven't made it easy to make it happen. Because making anything like that easy requires a lot of work and you've gotta prioritize your work and figure out what's worth working on.
(17:13):
And that's not the kind of thing we want to do. It's probably not the kind of thing another company would wanna do. So we didn't do that, but we did make it relatively easy for a smaller business, 10, 20 people, 30 people, something like that, to, to move over to Hey for domains if they want or a small company of five starting out, you know, for the first time where they don't have email yet. We always think like everyone's got everything. But if you're a small company starting tomorrow and, and you know you've got your three employees, like what are you gonna choose? Well, you can choose a number of things, but Hey is a good place to start actually. It's a really good place to start and a great place to grow. Um, unless you're again looking to be a 500 person company, which many people might think they want to be but they don't turn out to be. So anyway, that those are the choices we made for, Hey, very similar to Basecamp's choices focused on small businesses and not getting too caught up about all the things a much, much larger business would need in order to make this kind of thing work.
Kimberly (18:05):
Are these decisions you guys are making from the very beginning? Like before you're starting a new product, you're thinking who is this audience from day one?
David (18:13):
The choice that we've made with every single product we've ever built is that the audience for day one is us and us alone. Not that you don't have aspirations, that and us is actually a representation of a much larger market. Of course you do, but those are hopes and dreams to design good software, to design a great B one that you can put confidently into the market before any customer has used it. The only method that we have find found that works repeatedly is to design for ourselves first. Make something so good that we are extremely excited to use it ourselves. We made Hey, for example, to be all the best ideas we could come up with after using email for 25, 30 years. Like that's a lot of stuff. That's enough. That's more than enough. In fact that'd be one had plenty of cuts even if we were just trying to make the very best product for ourselves.
(19:11):
And I think that determination to build something that really works for someone and where you get the feedback the entire route through, you're not imagining or coming up with fantasy buyers. Fantasy customers say, oh, I wonder if they'd like that. No, no, no, no, that's way too speculative. It's fine to do that process once you have real customers and they're telling you real things, particularly when they're telling you things with their wallet, that is the best kind of feedback you can possibly get. That is whether this is worth my time and my money or not. Boom invoice, no invoice cancellation, sign up. You get all that raw data back and it's honest. It is not honest to rely on your fantasy of what someone might want. Uh, down the road. Now we're privileged in the sense that we have built software for 20 plus years within the domains that we are interested in.
(20:03):
Built an email system because we thought Gmail was just not working well for us. It was a great system back in 2004, eh, not so great a system in 2020 when we launched. Hey. And the same thing with with Basecamp. It's the operating system for our business. So we get that feedback cycle all the time and it's very short. We can build something, we can try something like is this working? Is it not working now? It's not working, let's change it a bit. And that's why when we launch something that we call a v1, it feels like a V3 or a v4. The joke with Microsoft for many years was always that their V1 sucked. Why did the V1 suck? Because it was just a fantasy. It was not driven by, by a vision of what it should be. It was like it was a, an empty canvas that customers could then react to and they'd react and you'd put out a V2 and like isn't this what you wanted? Then they'd go, I know it still sucks . And then you'd do another cycle and they'd come out with V3 and the V3 would be pretty good because they'd basically just handed over the product design to the customers, which is an interesting model. I can respect that model. It's not our model. I don't think it's the model of software that's out the gate is great. The only kind of software that is out the gate great is software that's built for the people who've worked on it.
Kimberly (21:19):
I love that. Well with that I think that's a wrap. I will say I have hopes you guys haven't told you this, but I have hopes of doing an Ask Me Anything episode with the two of you. So if you're listening, I need your help. If you have a question for Jason and David, leave us a voicemail at 708-628-7850 and we just might answer it on the show in the new year. Again, that's 708-628-7850. Let us know what you wanna hear from Jason and David and we'll address it then. Rework is a production of 37signals. You can find show notes and transcripts on our website at 37signals.com/podcast. You can also find us on Twitter at rework podcast and in case you haven't yet checked it out, you can learn more about the 37 signals, programmers and ops team, what they're up to at their new technical blog. You can find that at dev.37signals.com.