Subscribe
Share
Share
Embed
Throwing more at a problem just makes the problem bigger. So, do less!
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.
Shaun Hildner (00:01):
Welcome to Rework, a podcast by Basecamp about the better way to work and run your business. I'm your host, Shaun Hildner. And this week we're talking about the chapter, Throw Less at the Problem. Joining me, as always, are Basecamp's co-founders and the authors of Rework, Jason fried. How are you today?
Jason Fried (00:17):
I'm good, Shaun. How are you?
Shaun Hildner (00:18):
Wonderful. And David Heinemeier Hansson, how are you?
David Heinemeier Hansson (00:20):
I am good. Good.
Shaun Hildner (00:23):
Well, good. Lately we've been talking about adding fewer features when building a product. And this is a little more about solving a problem by spending fewer resources. Is that right? Spending less time on something, less people, fewer people.
Jason Fried (00:36):
Yeah. David and I just got off a call about kind of this very thing, actually. We were talking about pricing. We've been considering playing with different pricing models for Basecamp 4, which we're finishing up. And there's some very appealing approaches based on some data modeling that we've looked at. And there's a lot of product changes that have to come from that. And then there's also other versions of this, which is like, don't change this and don't change that. Instead, solve it in another way, which is just more sales.
Jason Fried (01:04):
There are all sorts of different ways to approach any problem. And they're all a bunch of different trade offs. And I think our general approach, not always our general approach, but our general instinct, at least I would say maybe our hopeful instinct is, what's the simplest way to solve for what you're aiming for?Because there are definitely complicated ways, and there are definitely more involved ways, but can you get roughly the same effect by doing less? The reason for that is then you can do more elsewhere. That's the thing. It's not about overall doing less. It's actually about having more things that you can do in a given year, because the nine things you're doing are simpler than the seven things you could have done that are more complicated, and would've taken the same amount of time. So that's sort of the bigger idea here, I think.
David Heinemeier Hansson (01:52):
Yeah, the merchant in me always looks at this, do you know what? Anyone can buy a hundred percent for a hundred percent. There's no skill in that. But if you can buy 80% for 20%, there's skill in that, because now you have five shots of getting five things at 80%, rather than one thing at a hundred percent. And I think that really encompasses so much of how we've approached so many things at the business. You look at Basecamp itself, Basecamp is essentially five products. It's the 80% of all of these five different solutions, right? Hey, you don't need a separate Slack. You don't need a separate Asana. You don't need a separate Trello. You don't need a separate Dropbox. You don't need all these other things. Here's a version that includes the 80% that most people actually need in that situation together. And that's the value. The value is that you get it sort of all integrated together.
David Heinemeier Hansson (02:42):
The other thing I'd say is that, throwing less at the problem is a mindset of how to analyze the solution space. It's very easy to get locked in on tinkering at the margins. Okay, we're locked into this definition of the problem. Let's just tinker at the margins. That's just not where the big leaps are made. If you think of this other concept of the 10X programmer, for example, very few of the 10X programmers are 10X as effective because they write 10 times as much code.
Shaun Hildner (03:14):
I'm sorry, what is a 10X programmer?
David Heinemeier Hansson (03:17):
10X programmer is this concept from studies on old software organizations. That there'd be these individual programmers who would be 10 times as productive as the worst programmer, not as the average, but as the worst programmer. They'd make 10 times as much progress. But the bulk of that progress, the bulk of that impact was from analyzing the problem and then coming up with a totally different way of doing it. We can also just not do that, right? This solution we're looking at, do you know what? Maybe I can write it a little bit better than you, but that's not where the big gains are. The gains are by writing something totally different that solves the same hurt.
David Heinemeier Hansson (03:56):
Which connects to this notion of why you should never accept customers and their suggestions for features. Customers are excellent at telling you their problems. They're not excellent at designing solutions to those problems, because if they were, you'd be buying their software, they wouldn't be buying yours. They're buying your software because you are solving their problems. So constantly being able to step back and go, no, no, no, wait a second. This path we're on, is this right? Is there a totally different way, left field version of it, a less version of it? And the less is the guiding principle here, which usually comes up whenever Jason and I, we were just on this call about pricing. And we are analyzing, or we're talking about this broad analytical product that we've done internally, multiple pages, reviewing things to doing it. And sometimes some of those things in itself gives me this sense like, eh, I suspect there's a less version of this.
Shaun Hildner (04:51):
But it's easier, right? It's so easy to run into a problem, and say, "Oh, let's just throw more money at it. Let's throw more people at it." So how do you flip that in your head to, "Oh, let's reframe the problem"? Which I think is what you're saying, David.
David Heinemeier Hansson (05:03):
Yes. I think part of it is aesthetically. I aesthetically just have an attachment to this idea of doing something efficiently. Again, this whole thing of getting a hundred percent for a hundred percent of the effort. Just not interesting. There's no creativity there, and just mass blasting through it. There's no, "I want a deal. I'm here to wheel a deal. I want a deal on the best parts of this feature. I want to pay 20% of it, and I want to get 80%."
Shaun Hildner (05:33):
Yeah. Can you think of any examples of maybe products or companies that you've dug, and when they ran into some hard times, they did end up throwing a bunch of money at it or throwing too many people at it, and it created a poor solution?
Jason Fried (05:47):
I feel like there's probably a number of examples in the automotive industry where a company's struggling, and they come out with a whole new platform or new car. And this is so ambiguous and whatever. It's not even a good example. But basically where they think the problem is one thing, but it's really not that. And by the way, that could be our problem too. Every company, for example, if you're talking about increasing marketing expenses, increasing sales, how do we get more customers in the door?
Jason Fried (06:16):
It could be that there's not a good product market fit. That actually could be the problem. The product could be bad. That could be part of the problem. But you sort of assume, oh, the product's perfect. We just don't have enough people coming in the door to sign up for it. You don't really know necessarily. And I think that's one of the areas where you can find yourself throwing a lot of money at something when you're not really selling the thing people want to begin with. So that's maybe a better example than that incredibly vague car example, which wasn't even a full, complete example. But maybe David has one. I just couldn't come up with one off the bat.
David Heinemeier Hansson (06:47):
I think part of the car example that works for me is actually Tesla. That Tesla threw way less at the problem when it came to putting cars together, which is how they were able to catch up basically being a hundred years behind. There was no way Tesla was going to produce a wonderful internal combustion engine car, because that requires 5,000 parts you all have to get right. Tesla came up with a model that required less than 500 parts, an order of magnitude fewer parts to put a car together. And they didn't even put those 500 parts together particularly well.
David Heinemeier Hansson (07:23):
Tesla is probably some of the worst built cars I've ever had the misfortune, at times, of driving in. And it just didn't matter. The less they threw at the problem was this, "Hey, what if we just made the floor out of laptop batteries? What if we just did that instead of this awfully complicated micro explosion management that is a gasoline engine? Let's not manage explosions. Let's just put a bunch of laptop batteries at the floor of a car." It reduces the overall complexity of building the thing by an order of magnitude. We can then dazzle people with some things that are easy and cheap for us Silicon Valley types to build like a nice user interface, something that's been historically neglected like crazy.
David Heinemeier Hansson (08:08):
All these German car makers, they'd be like, "Oh yeah. But look at whatever, all the tolerance gaps. A lot of cars were evaluated on how big is tolerance between the panel gaps? And Tesla just went, "What if ours are just totally crooked and no one gives a shit? And then instead, I'm going to put in a game on the menu. You're going to play chess on your car while you're sitting." Which is actually something I did with my son, which was really fun in our Tesla. We sat down and played chess in the parking lot.
David Heinemeier Hansson (08:39):
And that's a thing where you're throwing less at the problem. We can't fix the hard problems, panel gaps. Pretty hard problem. You have to spend decades to really perfect that model. Elon goes in like, "None of this matters. That's not why people buy a car. They buy a car because no longer they have to fill gas in it. They can just fucking charge it at home. They buy a car because it's an implied to get them from A to B. They buy a car because it's got humor." When was the last time you talked about a car that had humor? I think pretty much the only car in the industry that has humor is the Tesla. You can make it look like funny thing. There's a fart app that my eight year old son had a blast with for a while. And you compete in a completely different arena. This is what's interesting to me. That's why I have such respect for Tesla, even though I also kind of completely hate it.
Shaun Hildner (09:32):
I do think the Beetle was funny.
Jason Fried (09:34):
Yeah. Well maybe that was the last time. But what was interesting about the Beetle was there was a couple things you had the daisy little holder.
Shaun Hildner (09:42):
The flower holder.
Jason Fried (09:43):
The flower holder. And then it was mostly the advertising, also though, which was, we're not going to take ourselves too seriously. We're going to have some fun with that. And they set the tone there. The thing that's interesting about what David is saying is that while Tesla, of course, does technically throw less at the problem in terms of having fewer parts, they just chose a different problem. And that's actually kind of the reframing the problem, bringing humor into it, bringing a different user interface into it, bringing a different expectation of what a car is. It's more of a computer on wheels for Tesla, even though they're fast as hell. They don't handle very well.
Jason Fried (10:15):
They realized that people don't give a shit about that. Most people are just commuting. And if they can create an environment that's fast enough and novel enough and fresh enough, and you can plug it in. That's what's going to be different about it. So it is technically less, but it's also coming from a different point of view, which is, it's not less of an internal combustion engine. It's entirely different idea for what a car really represents versus everyone else.
David Heinemeier Hansson (10:41):
This is the key insight. The key insight with throwing less at the problem is that you have to give up some things. You don't get to throw all the same stuff everybody. You don't get the same quality. You have to say, you know what, these things we're not doing. Which connects to this other great book, I think maybe we reference somewhere in Rework, Blue Ocean Strategy. Blue Ocean Strategy is a methodology of approaching problems of how you're going to solve it. And it maps out by basically having you rank like, here's 5 or 10 things a potential car owner might care about. If they care about panel gaps, if they care about finesse handling, if they care about the fidelity of the controls, they're going to buy a German car. Let's just put it like that. That's where Audi and Porsche and BMW, they excel at that stuff.
David Heinemeier Hansson (11:30):
And Elon goes in and is like, "What if we took all those sliders, and we put them through zero? Make the shittiest stuff we possibly could, because it's not what we're going to invest. And on these other things, we're going to totally over index. First of all, we're going to make the floor out of laptop batteries so you don't have to refuel it anymore. That connects to the fact that you can feel good about the environment. That connects to the fact that we have this sense of humor." So throwing less is choosing fewer things, but you got to do those well. You can't just throw crap at the problem. You got to throw less at the problem. And that less has to be good.
David Heinemeier Hansson (12:05):
So the exercise that's so interesting is deciding all the things this is not going to do. What features will this not have? What qualities will it not have? Which people who like those qualities and those features will we not appeal to? In fact, we just had this discussion on this pricing call, where we were talking about large companies. Hey, there's a reason why a lot of software as a service is sold on a perceived pricing. Because if you land a few companies that have 20,000 employees or 50,000 employees, that's a huge account. And you got to care about them. And we could go like, you know what, what if we didn't care about those? Which is also sort of our historical stance on the question.
David Heinemeier Hansson (12:42):
But again, when you're reviewing prices, you should look at the whole thing again. You're like, why do we believe the things we believe? And we went like, you know what? We probably just don't care about that end so we can make some different choices here than someone else would do. If they were like, "Oh, juicy 20K account here that we really need to land. Let's throw less at the problems by choosing what we're not going to pursue. We're not going to target what qualities we will not have."
Shaun Hildner (13:07):
Can you think of any other examples where you ran into a problem and decided, and I think decided is key, to throw less at it? Not, well, we only have these resources, so now we have to reframe the problem. But are there any examples of, you know what, I only want to throw two people at this. I only want to give this the six week budget.
Jason Fried (13:27):
Kind of everything. And we don't always nail it, but our aim is most of the time, if not 90% of the time. Basically in everything we build today, there's two people working on it. There's one programmer, one designer, which prevents us from doing all sorts of things. On top of that, we timebox it with what we call an appetite, not a budget, but an appetite. We have an appetite for four weeks worth of work on this. This feature we think is worth four weeks. Not that it can take four weeks, because it could also take 12 and 16 and 20. But we only have an appetite for four.
Jason Fried (14:01):
And the combination of the appetite, plus a small team, you're forced into figuring out where the real value is, what not to do. It's more about, like David was saying, it's more about what not to do. Those are all the decisions, almost, what not up to do. And then the things that are left are the things you do. And you do them in a very, again, not a crappy way, in a very high end, straightforward way, but only a few of those things. Those are the conditions we put in place because we understand human nature. It is just the opposite, which is, you don't want to give up on something. You want to put more people on it and put more money behind it and do more stuff. And if we don't prevent ourselves from being human here, we're just going to never get anything done. And so, that's sort of the constraints we throw in front of us. As we delve into projects.
David Heinemeier Hansson (14:46):
This is why so many good, interesting ideas come out of scrappy startups in proverbial garages that only have two people. Because those are the conditions where you do not get to choose. You're just starting out. You're in this proverbial garage. Fair fact. I've never worked from a garage. It sounds like a weird thing. But let's just go with the metaphor for a while. Just to constrain, you can't afford an office. You can't even afford a proper desk or whatever. You're only 2, 3, 4 people. Super hard constraints. It forces you to think less, less, less, less, which forces you to think all about the things you're not going to do, which forces you to think about how you come up with something radically different.
David Heinemeier Hansson (15:26):
How can we get 500 parts in instead of 5,000? Everyone else is putting their product in this space together with 5,000 parts. We can't compete with that. If we were competing head on, if you just go in a garage with three people and you decide to take on a huge conglomerate head on, with the same product in the same space, you're going to get squashed. You're going to get squashed immediately. They have all the advantages in their favor. You have to play this guerilla warfare here of not facing the enemy head on. You're not going to face a tank with a slingshot. You're going to sort of go a different way around it. And you're going to find a different angle on it. And you're going to find something clever that they haven't thought about. And you're going to find that because you have to. Because if you were this person who sat at this major other company, and you had a hundred people and two years to do it, you too would come up with the kind of product that took a hundred people two years to do.
Jason Fried (16:24):
This is really about initially figuring out, what could you do? And then deciding what can you do? And those cannot be the same.
Shaun Hildner (16:33):
This is the curation process we talked about in the last episode.
Jason Fried (16:36):
Can has to be less than could. And the problem is that, if you come up with your could list and you go, we're going to do all the things we could do. That's the recipe for forever and too much and not enough. And it doesn't go well. So that's the art. It's figuring out, going from could to can, and getting there with as few people as you can, I think. And it's a little time technically as well.
Jason Fried (16:59):
Now look, there are, of course, people I know, you listen to these things and they go, "What about?" Again, we had this, I think it was in Rework, or maybe Getting Real. You're not fucking air traffic control. You're not building an airplane. You're not building semiconductors. Some of those things are enormously resource intensive. Although, of course, I think the semiconductor example is interesting with Apple and Intel, just taking very different approaches and whatnot. But these are very resource flush companies, both of them. So it's not like one had less. One had less of a head start, but no one has less there. But those examples are such outliers. Most people are not facing those kind of situations or conditions.
Shaun Hildner (17:38):
Yeah. Well, perfect. I think that's a pretty good place to wrap up that conversation. We do have another listener question.
Jason Fried (17:44):
Yeah. Let's do it.
Shaun Hildner (17:45):
This one's coming from Paul.
Paul (17:48):
Hi, Jason and David. This is Paul from Norway. I got the sense that you guys love coding. So first, I'm wondering if that is the case. And secondly, how much time do you spend coding these days? Thanks. Bye.
Shaun Hildner (18:06):
I think that might be more for David, as far as the coding goes. But Jason, maybe how much time do you spend actually playing with the HTML?
Jason Fried (18:14):
A lot less than I used to. More of my time is spent on sort of helping others come up with solutions for problems and working through, and being more of an editor actually on the design process. The initial instigator and then an editor, is sort of my current thing. I can get in there when I need to, but I typically don't anymore quite as much. So David's in a different boat though. He's coding away like a mad man.
David Heinemeier Hansson (18:39):
Yeah. I enjoy the act of coding an awful lot, to the point that it's almost one of those sustaining activities that makes the rest of it work. Because if I go too long without getting my hands into the code, I just get grumpy and then I'm not good at the other stuff. So I need to do that. I need to have my hands in it. And that's a thing I enjoy. And I happen to work at a place where I could do the thing I enjoy very much, and it actually helps the business and it moves things forward. And yeah, I wouldn't give that up for pretty much anything, which is also why we've tried to design the company in such a way that both Jason and I can continue to do the things that we really like to do.
David Heinemeier Hansson (19:22):
Oftentimes what happens to entrepreneurs and founders as the company grows is they do just the things that have to be done. And then they're not doing the things they really want to do. And then they end up miserable and then they can't go the distance. We've been able to stick with it for 20 plus years because we've spent an awful lot of the time doing the things we really like to do, whether that's writing or designing or being an editor or doing code. And then finding either ways of throwing less at the problem when it comes to the administrative side of the business or getting someone else to do it.
Shaun Hildner (19:59):
If you could, I don't know, guess at the breakdown of your day or your week, how much of time is spent coding?
David Heinemeier Hansson (20:06):
It's very up and down. Sometimes it's literally a hundred percent. I almost go off the grid sort of for a while because we have a problem and I'm really interested in that problem, and I want to solve that problem. And I do that. And then there are other weeks at a time where I don't get back into the code. And usually once it's been weeks, I do start to get a little grumpy. And then I realize, I got to do something. Which is so funny too, because sometimes this has sort of that energy of differential value. There are certain things I'd like to believe that if I'm in the code with, it really makes a big difference. But sometimes I can't wait for that thing. So I'll just fix a bug that anyone at the company or any program at the company could have fixed that bug. They could possibly have fixed it better than me, possibly could have fixed it faster than me, but I simply need to write some code. So this is a way to be productive, then just go like, "Ah, that was something I just needed to do."
Shaun Hildner (20:57):
Perfect. Well, thank you, Paul. Keep these questions coming in. If you would like to ask a question of Jason or David, leave us a voicemail at (708) 628-7850. Or better yet, record a voice memo on your phone and email it to me at hello@rework.fm. And that will do it for this episode. I know you're both on the road, so thank you both for joining me today. Next week, we are going to talk about focusing on the things that won't change. But for now, I will say thank you to David Heinemeier Hansson.
David Heinemeier Hansson (21:30):
Thanks, Shaun.
Shaun Hildner (21:32):
And thank you, Jason Fried.
Jason Fried (21:33):
Thank you, Shaun. See you next time.
Shaun Hildner (21:34):
We'll see you next week.
David Heinemeier Hansson (21:35):
Bye.
Shaun Hildner (21:46):
Rework is a production of Basecamp. Our theme music is by Clip Art. We're on the web at Rework.fm, where you can find show notes and transcripts for this and every episode of Rework. We're also on Twitter at Rework podcast. If you're following along in the book, next week we'll be discussing the chapter, Focus on What Won't Change. And if you liked the show, I'd really appreciate it if you would leave us a review on Apple Podcast, Spotify, Overcast, or wherever you're listening to this.