Subscribe
Share
Share
Embed
In our recent episodes, we've been talking about the principles of Shape Up – the cornerstone of 37signals' product development philosophy. We've explored the art of crafting a pitch and the decision-making process that takes place at the betting table.
Shape Up acknowledges that there's always more work than time allows, and on today’s episode, we’re zeroing in on a critical aspect of the Shape Up philosophy—when to stop tinkering and take the leap and ship.
Join Kimberly Rhodes and 37signals co-founders Jason Fried and David Heinemeier Hansson as they share their wisdom on the ever-present dilemma of shipping on time versus shipping perfect, and the fine balance between must-haves and nice-to-haves in product development. Plus, the value of Hill Charts in Basecamp to keep you tethered to the reality of where your project truly stands.
Listen in as Jason and David provide practical strategies to master the art of timely product delivery that doesn't sacrifice quality to ensure your team stays on the path to success.
Show Notes:
[00:00] - There's always more work than there is time, and at some point, you must stop and ship and that's the topic of our conversation today.
[00:44] - Jason talks about the importance of shipping on time without sacrificing quality.
[02:29] - David uses a racing analogy to explain how viewing work through a budgeted timeframe helps you prioritize (and shed excess scope).
[03:21] - The effectiveness of constraints in achieving better results.
[04:18] - How embracing constraints leads to better software.
[05:23] - How the two-person teams decide on "must haves" vs. "nice to haves."
[07:51] - Constraints allow for reevaluation of the problem statement, highlighting that even the "epicenter" of a feature can be redefined, leading to scope reduction.
[10:08] - How timelines keep you honest and keep you from chasing bad money.
[11:47] - The value of "Hill Charts" in Basecamp
and why complex issues on the other side of the hill pose a greater challenge.
[12:44] - Jason explains that in the Shape Up methodology, if something isn't completed within the timeframe, it isn't automatically reintroduced—it has to fight for its relevance.
[14:08] - How to avoid the "too big to fail."
[14:21] - David explains how to use the "penalty box" concept to keep yourself honest in product development.
[15:08] - The importance of guidelines and guardrails in getting you where you want to go.
[19:08] - When should a project transition to a more formalized approach like Shape Up using the example of HEY.
[20:45] - Why you should allow for experimentation in the initial exploration phase of new product development.
[21:50] - You can read more about Shape Up, 37signals philosophy around product development in the book Shape Up. A free copy is available here. Rework is a production of 37signals. You can find show notes and transcripts on our website. Full video episodes are available on YouTube and Twitter (also known as X). If you have a question for Jason or David about a better way to work and run your business, leave us a voicemail at 708-628-7850 or send us an email.
Links and Resources:
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 37signals about the better way to work and run your business. I'm your host, Kimberly Rhodes. The last couple of weeks we've been talking about the Shape Up principles, which is 37signals philosophy behind product development. We've talked about writing a pitch and then taking those pitches to The Betting Table to decide which features get worked on. But as Shape Up mentions, there's always more work than there is time, and at some point you have to ship. So this week I'm joined by Jason Fried and David Heinermeier Hansson, co-founders 37signals to talk just about this – when you know when you have to stop and move something forward. Jason, I'm going to start with you. Something in Shape Up says "Shipping on time means shipping something imperfect." Tell me your thoughts about that.
Jason (00:44):
Well, this is the whole idea behind budgets, which is we're giving it this amount of time, so you're shipping something or you're not. Now, that doesn't mean you ship garbage, it doesn't mean you ship stuff that's broken. What it means is, this is an old adage I think from, I dunno if it's Getting Real or Rework, but basically half, not half-assed. This notion that whatever you do choose to do in this allotted period of time needs to be good, it needs to work, it needs to be clear, it needs to do what it needs to needs to do, but if you need to cut out scope to get something out that that's what you do. You don't cut quality, you cut scope. When do you do this? Not on Friday before at the end of the six weeks, not Thursday before the end of the six weeks.
(01:25):
But as you go, especially towards the middle, you have a pretty good sense of like, are we going to be able to do this or not? Do we need to rethink this or not? That's probably the right time and sometimes it's even a week in. Let's say you're doing a six week project, it could be a week in, you could find out pretty quickly. We do these things called spikes sometimes where you explore an idea, but this is going to be way easier than we thought, or this is actually going to be much harder than we thought. And it's at that point you have to maybe renegotiate what you're about to do, what you're about to take on, but you just don't want pileups. That's what you don't want, which is a lot of work left towards the end to rush through and do poorly or push the deadline out and overshoot the budget.
(02:03):
So you want to avoid those things. So it's a balancing act. There's some intuition here. There's asking the right questions at the right time. It's getting honest takes from people who are in the work doing it. Everyone wants to feel like, oh, we can get this done, we can get this done. There's a bit of a hero complex there, but being realistic about this, can we do this? Do we need to cut something out? Is there a simpler way to do it? These are the kinds of questions you want to start asking pretty early on and make sure you're not just finding out at the end.
David (02:29):
What I think is so interesting about looking at the work through the lens of the budget is that it reminds me of racing where there's this saying of you'll go where you look and turn into the slide. So your body when you're driving a car has some intuition at least once you familiarize yourself with a machine like a car and how it works that if you are looking at the direction where you're going, you're going to end up there. Your hands are somehow magically going to turn to steering wheel just right degrees and your feet are going to help the pedals to get you there. If you're looking at the barrier, you're going to hit the barrier. So when we say, hey, there's six weeks to do this and you are two weeks in, you're three weeks in. This idea that we're looking at where we want to go, we want to ship in another three weeks is so clarifying for shedding the excess scope.
(03:21):
And it's actually a natural process that I find that most people don't have a lot of difficulty with. Reality is compressing, the timeline is burning down, and they know, okay, this is not too important, we can leave this out, or if maybe there's a short discussion about it. But it's very, very different from the traditional approach of trying to estimate your way to it. Oh, we have all these things, how do we fit them in? Oh, I don't know. It'll probably come together. Maybe things will go faster at the end, they never do, which is why projects that are driven by estimates invariably are late and often fail. You're not looking where you're going to go, you're looking towards the wall and you're going to hit the wall with those estimates. So looking through it with the budgets is just the kind of constraints that actually help you get to where you want to go and cuts with the grain of human nature and what we're designed to be able to cognitively do and it makes all the difference.
(04:18):
But even so you have to go into this accepting that you're not going to get everything you want and that that's actually a good thing. I think this is the second order effect of this. You will end up building less software, less complicated software, less software full of clever little darlings if you're enforcing these constraints on yourself. I've seen this time and again at 37sgnals. When we've given ourselves too long to noodle with something, it becomes overly fussy, it becomes overly clever, it becomes overly complicated. When we are embracing constraints, we're setting on ourselves, but we're embracing them nonetheless and we don't have enough time to do everything that we possibly would, we end up with better software. And this is one of those hard to internalize ideas, which is why you need the constraints, which is why you need the limits to do it, to force you to do it because in the moment you always think, oh, if I had just a little more time, we could make it a little better. We could polish it a little more yet. You know what, you'll probably end up with a gold platinum mess.
Kimberly (05:23):
Well, it's funny they say that same thing in cycling, even with a bicycle, you go where you're looking. So I love that analogy for sure. I do have a question for you though, because in Shape Up it mentions things that are must have versus nice to have when it comes to features. And so I'm curious, we talk a lot about these two-person teams. Are those the people that are deciding the must haves versus nice to haves or is that decided at some other level or some other part of the process?
Jason (05:49):
There's no real yes or no answer to that or these are them kind of answer. It just depends on, initially there's a suggestion of what we think is essential. Some of that really is essential and it's pretty obvious that it's essential. It just is. And some of it we would think is kind of essential, but it turns out not to be. And some of it is clearly optional. But those definitions can be reworked during the project depending on how we're doing. Part of it is like we just can't do this in this amount of time, so I don't care how essential you think it is, it can't be done for some technical reason or some whatever reason. So then you go, okay, well what are we trying to get out of that thing? Is there another way to kind of get the same thing in an easier way?
(06:38):
So sometimes we'll figure that out where we get 80% of the way there or 90% of the way there quickly and we'd say that extra, the idea we thought was essential, it turns out it's only 90% of it really is, or 80% of it really is, and the other 10 or 20, that wasn't really the important part. It seemed like it was, but we can get away without having it. That's one of the things that we look for when we're running into these situations. I wish I had a concrete example, maybe David has one off the cuff, but there's all sorts of features where we're building something and we're like, you know what? It'd be really nice if you could drag and drop this right into this place, but it turns out that tends to be quite complicated. But if you can drag and drop it in a general area and they can ask you where you want to put it that we can do by tomorrow.
(07:23):
But the other one is if you're dropping into these little notches of time, that could take two weeks because of just the way things are done and the way things are built. We would say it's important that you should be able to drag and drop. That is essential, but the way we execute that drag and drop is up for negotiation. So that's kind of a one way to work around these situations where the drag and drop is essential, but how you actually do it and to what degree of fidelity is negotiable. So that's sort of my quick response on that.
David (07:51):
I think that's actually a great example because you can look at something like drag and drop and go, is that actually the problem we're trying to solve? We're probably trying to solve ordering. You have five items and you want 'em in a different order. A nice way of getting something in a different order is drag and drop, but drag and drop, especially on the web can be a little fuzzy and there can be other complications and it means it takes longer. Sometimes, do you know what, an arrow pushing things up one at a time or one down at the time is just fine, just good enough and you could have that done in 30 minutes rather than perhaps a week of drag and drop stuff. So I think that's a great example of even when you think you have the problem definition, very often if forced to by constraints, you can go back to that problem definition and restate it.
(08:39):
No, actually what we thought is the problem is not really the problem. The problem you're trying to solve here is ordering. We could solve ordering in different way or we could even decide ordering doesn't matter. We've had cases with this where we wanted something to be orderable and we just go like, do you know what? There's actually not going to be that many items on this list. We can just alpha. Alphabetically order this by default upfront, or we could have a toggle where it's either alphabetically sorted or it's sorted by date. That's a way of arriving, approximating that order that someone would manually drag around that allows you to cut scope immensely if you have to. So treating this whole exercise as one that treats the problem statement itself as open for renegotiation, and as Jason says, sometimes when we do the pitch we think we have the problem definition narrowed down.
(09:30):
This is what we like to call the epicenter. If the feature didn't do the epicenter, it's not the feature anymore. It might be something else, but it's not the feature anymore. But even that epicenter can be looked at from a different angle and sometimes you think, oh, the epicenter is track and drop for reordering. No, it's presenting a list of information and actually as we're developing this, we're realizing there's only 10 of them. It doesn't matter that it's user orderable, it could just be pre-programmed in the system with three different ways of doing it. I think that is exactly what we found time and again, that the constraints leaders, we get into it, we get into it, we really want this thing. We thought this was a must have, but constraints and timeliness have this wonderful capacity to transmute the must-haves into nice to haves when you're looking at the alternative. And that's the alternative you always need to have to keep Shape Up honest is that this is not going to ship at all.
(10:25):
If we do not finish this by the end of the time we've allotted, we will cut it. We will absolutely cut it. We've done that several times with marquee features. A handful of times we've even announced those features, oh, this is coming. And then it gets to the end of six weeks and we go like, do you know what? We're going to cut it. We can't get to where we want to be with last minute alterations to the scope. So it's just not going to happen. And I think you need that threat to keep yourself honest. Because otherwise you could always go like, oh, it's six weeks, but really it could also just be another six weeks and then if it can be another six weeks and it could be another six weeks and before you look at it, you spend three months chasing bad money.
(11:05):
I think the point here is this is really hard to do and the few times we've found ourself in this situation, we've had a difficult time doing it. And what usually needs to happen is if we have a six week project and we're not quite there at the end, we always end up giving it at least another week. But if it can't happen within that extra week, then it is time to just bring down the hammer and give up something you value because you value something else more. You value the integrity that we have a methodology and if it's to be believed by the team and by yourself that these budgets actually matter, then you have to be kind of sort of militant about enforcing them.
Jason (11:47):
One thing I want to add too about the extra week, because yes, we do do that sometimes. This is the value of hill charts and the concept behind hill charts, which is you could say we're not quite there yet, but you have to say we're not quite there yet with what? If we're not quite there yet with something really fundamental that we haven't figured out yet. A week is not going to make it happen and you cannot lie to yourself that we'll get that done in the next week. This is all about stuff that's over the hill, meaning things that we just couldn't finish, but we know what we're doing and it's almost done. We know the whole thing. It's more of an execution thing and the execution is straightforward. That's something that you can fit into another week if you need to, but it can't be another week after that, another week after that. But it also cannot be a big unknown, a big thick unknown that's sitting there, this heavy unknown on this side of the hill where it's like, I don't even know where we're going to go with that because it might be Thursday until we actually figure out what the hell we're going to do with it and then we only have one day left. So if that's the case, it's a no go and we've had that happen before too.
Kimberly (12:44):
So in the Shape up methodology, is there ever a scenario where something is taking longer than you think and you're like, okay, well we're not doing it and it gets reintroduced for another cycle. Is that something that happens or it's just like it's not happening, period.
Jason (12:59):
It can happen, but it's not automatic. This is the most important thing. It's not on a repeat. You don't get another shout at it automatically because it didn't get done. It has to fight for its relevance against all the other things you want to do next time. And sometimes it does win out. It is worth doing, trying again. And we've also done things that we've tried again and we still didn't get it done. And these are sort of the worst possible outcomes ultimately. But again, the beautiful thing about Shape Up is at the end of the day, let's say you blow 12 weeks, two cycles, it's not that big of a deal. I mean you don't want to do it, but it's not like you blew a two-year plan and this thing you spent everything on is now not going to happen. That is a big problem.
(13:43):
Again, you don't want this to happen, but limiting your downside exposure here is really important and at the very worst it's going to be two cycles at the very worst. And again, that has happened maybe twice in 20 years where you've given something like two goes and didn't do it. So it just almost never happens. But even if it does, again, it's not the worst thing in the world. What you just don't want to do is completely destroy a long-term project and you don't want to put yourself in a position where you can't ship something. There's this place where it's too big to fail, you'd never want to get there. You want to always be fine with something small failing that you have to be there otherwise you're in deep trouble.
David (14:21):
One of the ways you can keep yourself honest in that regard is to use this concept that I like to call the penalty box. So let's say you've been working on a long project in one cycle, it's not going to happen. There is stuff on the left side of the hill unknowns, you really want it still, right? So it's so tempting to put the project right back into the next cycle and I think preventing that and actually going, you know what? We want this, we really want it. But if it's that important, it can sit out for a cycle. It can be in the penalty box for one second. We failed here. If we get to the end of a cycle and there's something we wanted to build and we just didn't get it done and we wasted, in the sense that we did not ship the project after the six weeks, it hasn't deserved a chance at the betting, at the very next betting table.
(15:08):
If it's that important, it can wait one. And I think what we found so often is that you confuse your annoyance and your enthusiasm of trying to push it over the line and failing with, this is really important. So several times we put something in the penalty box and then it just kind of hasn't been that important and we have not wanted to pull it back out of the penalty box once this cycle has passed. So I think that penalty box, keeping yourself honest is really what Shape Up is about in many ways that your core instincts for product development and how you go about dealing with things that are late or things that have too much scope, they're not great. They need some guidelines, they need some guardrails to be able to really get where you want to go ultimately. And you have to know that about yourself that there are these cognitive pitfalls that you will fall into as well.
(16:04):
Jason and I fall into it all the time. We as a company fall into it all the time. We've been building software this way for 20 plus years and yet still human nature. I just had a little more time, we could squeeze it out. Maybe I can't get done in a week. What if I just throw one more week after it or one more week we will get it done. Hope springs eternal. So you have to have these guard rails that say like, alright, cool, easy. We're just going to put it over here in the penalty box because we've decided that upfront, right? It's in the moment when your passion is so high for making this project happen that all these other things fall apart if you don't have some concepts of how do we deal with these situations.
Kimberly (16:42):
Okay, so we've been talking about this concept of knowing when to stop or when something is complete for product features, but kind of talk me through how this relates to developing a new product. We've mentioned a couple times that we're working on something brand new. Does that same philosophy apply here when you're starting something from scratch knowing when is the product done and ready for customers? How do you balance that?
Jason (17:06):
So when we start something new, there are no formal cycles or time boxes really, but there's an approximate sense of within a few months we should know where we're going if we're going anywhere at all after this kind of, and different products are different sizes, so sometimes it's much sooner than that. Sometimes it's a little bit longer than that, but we tend to try to more sort of tetrasize our time. I would say fit things. So there's no gaps in between. If we're dealt with four or five things, let's just start the next batch of things right after that versus doing the six week cycles and the cool down kind of thing. During new product development, which of course we rarely do, we only build a few new products. We've built a handful of products over the last 20 years, so this is not the common thing, but typically as we approach a shipping date, a launch date, we do put one down, there is this deadline, we're going to ship this in October or we're going to ship this in January or whatever it might be.
(18:07):
Or we have to ship this before Christmas or something cause it's just that month is shot, December shot, whatever it might be. There is a line that we draw and then we begin to formalize a little bit more as we approach that line. But typically for us, Shape Up is more about continuous feature development for an existing product or sort of the tail end of the wild west exploration phase. I do think it's important early on just to basically it's like freeform exploration. It's kind of how it has to be, but then it does get formalized. I mean there's not like when people, when is it half, all this stuff is a feeling of when it can serve the process best. There's a point where it doesn't serve it because free flowing and free association time and there's a point where you need that structure to meet what you need to get done in a certain small period of time before this actual ship date happens. So it morphs into that is the best I can explain it.
David (19:08):
A good way for me to look at that tipping point is, do you have something you actually want to use and are you using it with real stuff? If we take the example of, HEY, once we got to the point that Jason and I could actually use Hay to send and receive emails back and forth, we were at a point where we could tip over and go into more of a Shape Up style territory. But before we got to that point, all of it was wild explorations. All of it was trace of bullets, bunch of it was half built because we were trying to arrive at something we actually wanted and you don't know what you actually want in many cases until you've got it. So being in that exploration phase feels very much like this grand Hill Chart where all of the work is on the left side, all of it is unknown, unclear whether it's going to be valuable or not.
(19:59):
You try a feature, I don't want it all, boom, just scrap it. Scrap it when it's 30% built or no, no, this one has promised it's only 40% done. Let's just get it done enough. And then you arrive at that point of like, okay, now I'm actually using the thing. We still know we need a bunch of stuff to be able to fully productize this and make it more or make it ready to sell. That's the point where you've tipped over the hill and you're starting going downhill and you can be more formal about it. I think it's worth realizing that any methodology, even a lightweight one as Shape Up imposes some cost. When we look at, for example, the pitches we're going to do and we have a team of reps, three programmers. I often think intuitively because Jason and I have been through building so many products from scratch, that's not very ambitious.
(20:45):
It is not actually that many things, but when you have a real product that's out there being used by real customers, you've got to go through things in a bit more of a methodical way. You don't want to overload it. The joy of green field product development where you're only dealing with your own data is you can break shit all the time. So your confidence for trying things, experimenting, shipping half finish things needs to be quite low. You can really go wild west on it, not with quality in terms of implementation because that's just how you end up with long-term mess, but in terms of the product and the shape it's going to take, you can try crazy experiments and you can just let them fold and it doesn't matter. Okay, so the app is down right now, who cares? It's Jason and me sending emails back and forth. Oh, so I lost a couple of emails. Kind of annoying. Not the end of the world. We're not inconveniencing any customers. So I think that initial phase, that initial exploration phase actually has to be as free of formality as possible. Just a tiny handful of people going wild with this until there's something there.
Kimberly (21:50):
Okay, well with that we're going to wrap it up. You can read more about Shape Up, 37signals philosophy around product development. You can get a completely free download at 37 signals.com/books. You can also purchase a physical copy there as well. REWORK is a production of 37 Signals. You can find show notes and transcripts on our website at 37 signals.com/podcast. You could watch full video episodes on YouTube and Twitter, also known as X. And if you have a specific question for Jason or David about a better way to work and run your business, leave us a voicemail at 708-628-7850 or you can send us an email to rework@37signals.com.