Subscribe
Share
Share
Embed
When you first start building something, don't spend too much time in the weeds. You may never get out.
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:02):
Welcome to Rework a podcast by Basecamp about the better way to work and run your business. I'm your host, Shaun Hildner. I may sound a little bit funny in this recording. I have just moved house and the details that we'll be talking about this week are the acoustic baffling that is still stuck in supply chain purgatory. So I apologize for of that. But this week we are going to talk about the details. Last week we talked a lot about where to start when you're building something new. And this week we're going to be talking about where to continue on from that. And joining me, as always, are Basecamp's co-founders and the authors of Rework, Jason Fried, how are you?
Jason Fried (00:37):
I'm good, Shaun, how are you doing?
Shaun Hildner (00:38):
Wonderful. And David Heinemeier Hansson, how are you?
David Heinemeier Hansson (00:41):
Good, good.
Shaun Hildner (00:43):
I guess the crux of this episode is, you guys see a lot of people trying to add the smaller details a little bit too early on. Is that about right?
Jason Fried (00:51):
Yeah. I mean, including us. It's an easy thing to get caught up in, right? Which is you build something new, let's say new feature, you got a few weeks to do something new. And you can find yourself getting in the circular pattern of obsessing over stuff that doesn't matter yet. Like the fit and finish of something may not matter yet until you just get the basics in place. And you can blow a week or two or more circling around just some fit and finish that's just not important yet. It's not that it doesn't matter at all. It's just, it doesn't matter yet. You need to make more progress early on before you start to layer some of that stuff in. So that's kind of what this chapter is about.
David Heinemeier Hansson (01:26):
I think one of the key reasons here is that these details, these refinements you're making, may get thrown out. If you're refining something that doesn't pan out, because the idea's not quite right, the order of the screens needs to be different, we actually need to approach the problem from a slightly different angle, you've wasted all that time. And you won't know if the design is right, if the flow is right until you have it essentially working. So getting something that's the real flow in its rough state, working as quickly as possible, allows you to verify whether you even have the feature by its tail, or whether it's still elusive.
David Heinemeier Hansson (02:07):
We talk often about uphill work and downhill work. This comes out of the hill chart feature in Basecamp three, where on the uphill, you still have uncertainty as to whether you're on the right path, whether you've identified all the aspects of the problem and whether you're ready to simply just get it done. The downhill path is the detail path, is getting things right and making them good. But on that uphill path, it's really important not to get sucked into the refinements of the details.
David Heinemeier Hansson (02:38):
The example we use here, which I've always loved, is this idea of which size pencil do you use? The mock ups, if any of the pitches that Jason will make that I'll look at to review for flow or for technical ideas, they're always made with this thick marker. And you just can't be that precise when you have this thick marker. So the boxes are really chunky and you can't tell anything in it. And that's exactly the right level of abstraction when we're trying to figure out, is this the right direction or not? The flip side of course, is that if you don't get back to the details, you'll ship something shitty. So as Jason said, this is about timing. It's not about whether the details are important or not. It's about when you dive into them.
Jason Fried (03:22):
I think David makes a great point about, I'm glad you made it because I forgot, about early on. You're almost going to redo everything, kind of, anyway. There's a good chance. Whatever you work on in the first week is not going to be set in stone and you're going to be moving around and playing. And so you had to spend time on stuff that's to be redone anyway, just doesn't make a lot of sense.
David Heinemeier Hansson (03:41):
I think another way of looking at this is to think about the uphill part of the project, the early part of the project, as a way to dispel uncertainty, things you are not sure about yet. Those are the things you need to figure out now. And then once you're sure. Okay, we're good. Let's get into it. Let's sweat those details. Make them really nice. But you got to get rid of the uncertainty first.
Shaun Hildner (04:06):
And so what is that cutoff? How I think what you said last week was, how adequate does the epicenter need to be before you should start diving into the details,
Jason Fried (04:17):
You kind of get to this place where everything works the way you expect it to work, but then you're, you're not satisfied with how it looks or how it feels or maybe how fast it is. Or you might find that there's a more efficient way to do this. Here's a good example to get concrete. We're about to ship a feature in, HEY, called send later, which lets you schedule an email to be sent at a future date and time. And initially we had played with this idea of being really precise that you would pick a date by pulling up a calendar, literally like a calendar view. And you know, you could pick a date in the future and then you could pick a time, I think, based on five minute increments or something like that. It was pretty precise.
Jason Fried (04:59):
And we were going to use the built-in browser pickers and depending on the platform you're on, some are good, some are not so good. And we just started going down this path of like trying to massage these calendar pickers and get this stuff looking just right. And then we're like, you don't need to be this precise. This is really about writing something on Sunday and sending it Monday morning, or sending it tomorrow morning or whatever day it is today. And so we just basically, hey, there's only seven days in the week. And what if we just let you send it basically the top of the hour? So 8:00 AM 9:00 AM, 10:00 AM, 11:00 AM.
Jason Fried (05:28):
Literally, we could have spent weeks designing this precise interface to pick exactly when you wanted to send it, but we just dialed it back because as we started using the thing and started playing with it, we realized that we didn't need as much as we thought we would've needed. And we didn't get to that until nearly the end of the project. But we hadn't spent that much time on the calendar, the precise UI, but we could have. And then at the end we would've thrown it out anyway. And that's what you want to avoid.
David Heinemeier Hansson (05:54):
The funny thing with that particular feature was I did the implementation and we had a really nice design, actually, the more precise version, or I forget where we were exactly with it, but it was mapped out and we'd all signed off on it in theory. And then I went to implement it and we hit this one state where you were going back to revise whether a sent later thing needed to be sent at a different time and so on. And the design, as nice as it was, just didn't work for that. It was just a huge amount of complication. And I'm just, I'm allergic to that. I was like, I'm spending my own time writing the program for this. I'm not going to write it this way because it's going to be like twice the amount of work I've already invested. We're almost there already. We have to change the design.
David Heinemeier Hansson (06:39):
And this is this other fact. And I think we talk about this in another chapter, the trading of concessions. That sometimes you'll arrive at a design where you think it's all good and then you go to make it and you realize it's really actually difficult to make it that way. And that difficulty in and of itself has bearing on whether that's a good design or not. A good design is not just good because the user likes it. A good design is also a design that's easy to implement, it's easy to maintain, less likely to have bugs, less likely to have edge case states.
David Heinemeier Hansson (07:12):
I was just reading this thing about the bake off that they had for the iPhone operating system, which got into all the details of how to design the hardware. And the experiences that Apple had around design of the iPod before that, and that a key optimization was is this easy to build? Can we get high yields with this design? Does the wheel click in such a way that people can assemble it at a high volume, so on. And you go, you know that someone like Steve Jobs would totally sweat the details of how it feels to use, but they also sweat the details of what it would take to implement it. Can you get the yields out of it? Is this an efficient way of producing it?
David Heinemeier Hansson (07:54):
And I think this is something that's often forgotten when we talk about interface design, that you can get to this maximalist state that is very easy to say, just like whatever's best for the user. Go to a hundred percent. We never build like that. And I think that's part of those details is that even those details need to be negotiated too. Sometimes the details are trivially easy to do, and we'll totally like, let's do them, great. And then another, the times there's a little refinement that feels like, oh, this is nice to have. And it's like, yeah, but that's going to take me like a quarter of the time to make the whole thing. Is it really that important? So sometimes you even need to ignore the details later on when the price isn't right.
Shaun Hildner (08:34):
Have you ever fallen into that trap of going a little bit too far focusing on the minutia too early on?
Jason Fried (08:41):
Oh yeah. I mean, it's hard to ignore or hard to avoid sometimes. Which is why I, as David was suggesting or mentioned, I tend to, especially early on, I tend to use imprecise methods to come up with ideas. So big fat marker sketches, or if I'm using an iPad sketching app to work on some interface design ideas, I'll use the thickest pen option. You want to do everything you can to fight against the instincts of trying to over refine too early. And sometimes I'll find myself doing this, I'll try to draw some interface thing. And I'm just sort of simulating like a screen. So I'll draw a square. And I find myself like not drawing a really good square and I'll erase it and I'll do it again, I'll erase it. I'm like, what am I doing? It doesn't matter. It just doesn't matter.
Jason Fried (09:24):
So my sketches are, are pretty crappy, if you look at them. I could make them better, but I'm intentionally not focusing on the shape of the square. You get the point, this is a screen or a modal dialogue or a button or words. In fact, most of our sketches don't even have words they have squiggles where words will be because I don't want to get into what the words say yet. I don't know what they're going to say, or we're going to change them a bunch of times. But sometimes, like right now, I'm redoing the Basecamp.com marketing site with our designer and I'm obsessing over the copy too much on some screens right now. And what I'll do is I'll get in this, this loop where I just, literally, I've rewritten the headline probably three or 400 times, literally. And it doesn't matter yet because I know whatever I pick today will not be what we ship in eight weeks from now, because that's just how it goes. I know a day or two before I'll come with something else.
Shaun Hildner (10:15):
But you still don't want lorem ipsum or some nonsense. Right?
Jason Fried (10:18):
No, no. Never. You don't want that. You still want something that's pointed in the direction you're headed, but there's no reason for me to... Literally I've rewritten this a few hundred times. And I have, because I just kind of keep playing with it and keep messing with it. And I just know it's not going to matter anyway, there's no chance what I have today is what's going to ship in April or whatever. Whenever the site goes out. And rewriting a headline only takes a few seconds. It's not like a big deal, but it's still misdirected effort. There's other things on the site that I want to get refined, like the pricing page or something. I want to get more value and more leverage out of those right now. Or I could, if I spent my time there. So I have to remind myself, sometimes, just leave something alone for a while. Like literally I've, I've walked away from that project for a week because I was obsessing over the wrong things.
Shaun Hildner (11:04):
David, what about from the coding side? Do you find yourself sort of niggling at the small little details?
David Heinemeier Hansson (11:09):
Oh, very often. And it's one of those things where when you do, when I'm getting too hung up on making the code just right, just perfect on that initial implementation, and we then have to change it later, I kick myself because I get annoyed. And I get invested in this path because I already made it and I already made it nice. And now you're asking me to throw it out and that's really fucking annoying because it's just, I'm allergic to wasted work.
David Heinemeier Hansson (11:39):
The problem with investing in those details early on is that they feel like investments. You don't want to lose those. You don't want those investments to go to zero. You are now invested in that path. Even if it turns out that reality tells you that's not the best path. And then you become stubborn, sometimes. I mean, I've found that too. Like, I just really like this implementation. I don't want to change it. I don't want to change it. Even though I like begrudgingly can realize that, okay, fine, actually this better, the other way. And that's just an unhealthy way to do it.
David Heinemeier Hansson (12:10):
And we should all just realize that this notion of both sunk cost and endowment effect, they're all real psychological pressures on you. So don't put yourself in that situation where you don't feel like killing your darlings, right? You got to be constantly ready to kill your darlings when you came up with a better idea on how to do it. And it's not just details in that sense, it's also just polish. I mean, details stand in for that kind of polish, right? Which, for example, with the implementation, I feel like I'm pretty good on that end. Don't do the error checking upfront until we've committed. Don't do all the edge case paths and all the other stuff, just scaffold it out so you have a perfect path through it. There's one path through this where you click everything and it'll work. All the other ones, they don't work yet. And if we change direction, I won't have wasted my time.
David Heinemeier Hansson (13:03):
I feel the same way about testing by the way. So I'm a big fan of automated testing. We do a lot of automated testing, but I don't do this thing called test driven development where I drive my backend design by writing all these tests first, because that's another way of getting too invested in a certain implementation that I might want to throw out five minutes from now.
Shaun Hildner (13:24):
I kind of want to finish this off by talking about the process of finding which details to work on first. So you have your epicenter done. And how do you go about, in your head, prioritizing what's the next most important thing?
Jason Fried (13:38):
It's similar to like walking down a path that's not formed yet.
Shaun Hildner (13:42):
Got to cut the brush. Yeah.
Jason Fried (13:43):
Where's the next step that feels solid, that feels like the right place to go? And a big part of this comes from using the thing, of course. So for example, if we're making a message board or something in Basecamp, and the first thing is simply getting the B audio of a message, or maybe the subject, because one of those two things is all you need to get somewhere useful. And then you fill in the next, what's the next thing, what's connected to that would either improve what we have or let you do something you couldn't do before? And you just kind of keep walking and you see where the path leads based on what's useful and the utility a year after. And things just sort of come into view.
Jason Fried (14:19):
This is why we don't like write or plan out a bunch of, let's say, tickets ahead of time that people can take and say, well, I'll work on this, and I'll work on this, and I'll work on this, and I'll work on this. We don't really know exactly all the work that's going to be required to do what we want to do. We have an idea. And then the team that's doing the work, they blaze the trail, they blaze the path. They clear cut and they figure out where to go next, based on what this thing needs to do. That's usually it.
Jason Fried (14:43):
Sometimes it's a lot more obvious than other times. If it's something's really exploratory. For example, we shipped a feature in the last few cycles called lineup, which is a brand new idea in Basecamp, which lets you see projects with start and end dates, plotted on a timeline, essentially. We had a sketch idea of what that could look like, but how do you set that up? And where do you specify the times and the dates? And can you modify the dates from the lineup or only from within projects? There's a bunch of questions and we didn't have any answers to those upfront. As you use the thing you realize, you go, gosh, I would really want to feel like I want to click that thing to move it. Let's say this is going to be late. I need to be able to do this here. And you didn't know you needed to do that here when you first thought of the idea, but you just felt like you needed to do that.
Jason Fried (15:26):
Just like I need to walk down this path because I'm not going to get around the corner unless I go around this way or I won't be able to get this way because it's too loose and I have to find some solid footing. You kind of just feel your way around. I know this is not like great advice, perhaps, and people are like, what do you do exactly next? But I do think you pay attention to what you need and you don't define what you need up front. You define a direction that you're headed, but you figure it out as you go.
Shaun Hildner (15:55):
Yeah.
David Heinemeier Hansson (15:56):
And that's really the key is, once you have something that works, you get the priorities for free because it's obvious in almost all cases, is it obvious what's next. And this is one of the reasons, too, that when I started an implementation, I love just getting the first screen rendering something. And there's the buttons are halfway broken and the thing doesn't work. And then, what's the next thing that needs to happen before I've taken a step forward. And it's always very obvious. It's not a big mystery. Oh we have 20 different things we could do. No, there's one thing that's more important than everything else and it's totally obvious that they that's the thing because I'm trying to use it.
David Heinemeier Hansson (16:34):
And that also comes in with the refinement, which is almost as important on the other end is when to stop. When are you done? I get that sense. I'm done when my energy and motivation for working on this feature is waning because I can see we're into the diminishing returns. That this is actually good and enough, I'm perfectly happy using it as it is. Do you know what? We could just ship this. And I think sometimes, I mean, we'll go back and forth and we'll have different ideas of whether that means it's done or not, and so forth. But listening to that internal voice of, actually I'd rather work on something else more novel than this, is a canary telling you that you're into the land of diminishing returns and you could stop now. If you're not motivated to work on it any further, it's because it is essentially good enough in one version of good enough.
David Heinemeier Hansson (17:25):
That also comes with this idea of not trying to plot it all out. Usually when we line up a project, we'll have all these ideas, oh, it needs to do this. It needs to do this. And we'll always end the project with a relatively long list of stuff that just kind of fizzles because it just wasn't important enough. We reached the end of it. We were like, eh, let's get it out there. Right? And then there's this list of essentially just abandoned ideas because it turned out they weren't pivotal to whether we could ship this or not. And that's just as important, to realize when to cut your ambition and cut the details and just go.
Shaun Hildner (18:00):
Well, I think that's a fantastic place to stop. We have a few minutes here. You want to take a listener question?
Jason Fried (18:06):
Sure. Let's do it.
Martin Desal (18:08):
Hi. This is Martin Desal from the UK. I'd be interested to know more about the life cycle of your customers in terms of how long they typically tend to stay with Basecamp. And also whether there are particular industry sectors they tend to come from.
Jason Fried (18:23):
The majority of our customers are smaller businesses, fewer than let's say 20 people who work in these come companies, of which there are, I mean, it's the biggest business market there is. It's funny, because a lot of companies are afraid of small businesses. They want to go for the enterprise. You sell to one company that has 5,000 employees and you can charge for 5,000 people. It's a big deal, right? That's never interested us. And it doesn't bear out in our customer base either.
Jason Fried (18:49):
We some very large companies that use Basecamp, quite a few, thousands, that are quite large. But the majority of our customers are smaller and they're all over the board. I mean you've got design firms, which is sort of where we started. You've got architecture firms, you've got publishers, you've got dentists, you've got teachers you've got construction. You've got pretty much everything. Churches, synagogues, mosques. We're always surprised to hear how people are using Basecamp in all sorts of different ways. But it's not even the industry, we don't target specific industries, but mostly it's a size thing. It's smaller businesses, growing small businesses, let's say under 20 people. Of course that's not the be all end all because we have many that are larger, but that's where most of them are.
David Heinemeier Hansson (19:30):
One of the consequences of dealing with small businesses is that they go out of business, as all businesses do. But a higher percentage of things that have just been started will go out of business, versus a large business has been around for a long time is more likely to stay in business for a longer time. So there is more churn at that end of the business, that goes for anyone who sells two small and medium size businesses compared to those large enterprises. But they're also easier to sell because you're selling directly to the person who's going to use it. You're not selling to a purchasing manager. You don't have these long cycles. You don't need the romance part of the enterprise sales cycle, with weeks of negotiations and discounts and this, that, and the other thing. We sell directly, mostly, to the people who use it. And it's a very satisfying way of developing software and selling software.
David Heinemeier Hansson (20:22):
When you know that the person you're trying to convince on the marketing side is convinced if the product is good, not if the product is easy to you integrate with something, something, something that's a checkbox on the purchasing manager's list of things that he or she has been sending to town to figure out. There's an honesty about that type of direct sales. That really appeals to me. I think the other thing that appeals is it's a sense of selling to the next generation that you're not selling to the established players who've already gotten thing... How much are we really going to impact how some huge companies going to operate or not? I mean maybe, kind of whatever, but probably not as much as some small company that hasn't yet still figured out what the operating system for their business is going to be like. Large companies that have become large over a long period of times are just traditionally more set in their ways.
David Heinemeier Hansson (21:19):
We have a greater opportunity to make a real and meaningful impact on these small businesses that are just starting out, that are willing to learn, that are willing to try something else, which is a good idea because a lot of our products are quirky in ways, if you compare them to the rest of the market. That they don't line up so well with just necessarily a checkbox list of, oh, do you have this feature? Do you have that feature? Do you have that feature? And you know what, that's not really what we're trying to compete on. So I think that sense of openness is greater with those small and medium sized businesses that we've ended up with. And it also just flows together. This conversation that we are having now, there are going to be more of those small and medium size businesses who listen to that. Those are the ones who read our books, the starters and so forth. So all the sort of, the flywheel, if you will, of everything that we do spin around these smaller businesses.
Shaun Hildner (22:15):
Well, perfect. Thank you Martin, for your question. If you have any questions for Jason or David, you can leave us a voicemail at (708)628-7850, or better yet, record a voice memo on your phone and email it to hello@rework.fm. Next week, we are talking about decision making. So I will see both of you next week. For now, I want to say thank you, David Heinemeier Hansson.
David Heinemeier Hansson (22:39):
Thanks, Shaun.
Shaun Hildner (22:40):
And thank you, Jason Fried.
Jason Fried (22:42):
Thank you, Shaun.
Shaun Hildner (22:43):
We'll see you next week.
Jason Fried (22:44):
See you then.
Shaun Hildner (22:55):
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 @reworkpodcast. If you're following along with the book, next week we'll be discussing the chapter, Making the Call is Making Progress. And if you like the show, I'd really appreciate it if you would leave a review on apple podcast, Spotify, Overcast, or wherever you're listening to this.