Subscribe
Share
Share
Embed
Picture this: a dimly lit room where velvet-robed figures gather in secret to make decisions of paramount importance as the fate of the pitches for the next product development cycle hangs in the balance.
The "betting table” – where the formalized pitches for each six-week work cycle are selected – might seem mysterious but we're about to unravel its secrets.
Listen in as host Kimberly Rhodes sits down with 37signals co-founders Jason Fried and David Heinemeier Hansson to explore the unique inner workings of the "betting table" and how this process shapes each product development cycle.
Listen in as host Kimberly Rhodes sits down with 37signals co-founders Jason Fried and David Heinemeier Hansson to explore the unique inner workings of the "betting table" and how this process shapes each product development cycle.
Tune in to discover 37signals' approach to selecting and refining projects at the "betting table."
Show Notes:
[00:00] - Today on the podcast, the discussion focuses on the betting table and how the decisions are made about which pitches are selected and which projects to schedule.
[00:42] - Jason shares what the betting table is.
[02:26] - The betting table process: refining pitches into a kickoff document.
[03:17] - David shares the background behind the betting table and how it has evolved.
[05:51] - The betting table: passionately advocating for different views, with one person ultimately making the decision.
[06:51] - Ensuring that resource allocation decisions are made efficiently while avoiding committee-driven decision-making.
[08:56] - Decisions made at the betting table can sometimes be passed to others who are more passionate or informed about a particular project.
[10:04] - It's all about timing—unselected pitches don't automatically get another chance in the next cycle, but if they are relevant, they might.
[10:51] - Jason shares his biggest issue with backlogs.
[10:51] - Jason shares his biggest issue with backlogs.
[11:33] - David shares why Shape Up is such a powerful way of working and how the betting table process provides multiple opportunities to influence product direction.
[14:38] - Jason shares how the assignment of team members works during the betting table to ensure that the available resources match the selected projects.
[15:49] - David shares the background behind aligning pitch budgets with available resources and calendars during the betting table.
[19:55] - Why so much of the betting table process is asynchronous and done via written communication,
[22:54] - When calls might need to happen during the betting table process.
[23:57] - For more background on how 37signals manages product development, get your free copy of the book Shape Up. It is available here.
[24:13] - Don't forget you can still enter #TheUnderdogChallenge by sharing the story of your scrappy team on the 37signals LinkedIn post here for a chance to be featured on a future episode of Rework. The deadline to enter is September 15. Rework is a production of 37signals. You can find show notes and transcripts on our website. Full video episodes are available on Twitter and YouTube. If you have a specific question for Jason or David about a better way to work and run your business, leave your voicemails at 708-628-7850.
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. Last week we were talking about writing pitches, and this week we're talking about what happens when all those pitches are written and how we decide how features are going to be made in the next cycle. I'm joined as always by the co-founders of 37signals, Jason Fried and David Heinermeier Hansson to talk about this. I have to admit, as an employee, I really don't know a lot about the betting table. It kind of seems like this secret society that happens behind the scenes where mysteriously things get decided and then we find out what the pitches are going to be for the next cycle. So I'm excited to hear about this process. First, tell me who's involved in this betting table situation.
Jason (00:42):
Cigar smokers, so you got to smoke a cigar,
Kimberly (00:45):
Not it
Jason (00:47):
Very dim light, around a round table, in the back of a deli somewhere. It's got to be robes, right? Velvet robes. So the betting table basically is a continuation from the previous episode. It's basically where we discuss the pitches, the formalized pitches, and decide what's going to happen. Now, what's going to happen depends on who we have, what our general company appetite is at the moment. Oftentimes there's more pitches than we can actually do, so we narrow it down, not always, but oftentimes we narrow it down to a smaller subset. Any business goals, any bigger picture, things that we want to do now instead of later or wait till later instead of now. All those things come into play and then we make trade offs and we also refine, sometimes refine the pitches sort of at the last moment. You know what? We can't do all this, but if we cut this out of this piece, we could fit it all in, that kind of thing.
(01:41):
It's usually three or four people, but sometimes it actually happens over a few days or even a week because these pitches are posted to Basecamp first. We have a project in Basecamp. First we have a project called Project Strategy where they sort of originate, then Product Management where they're discussed amongst a bigger group. We get some technical, more technical input, design input, that kind of thing. And then there's this asynchronous conversation. I think this would work well, I don't really understand this. Here's an argument, here's a debate about this. And we kind of go back and forth that way. And then if we need to have a final conversation that's not asynchronous, but it's real time, then like three of us typically we'll get on a call, maybe four, and hash some things out at the last minute. The last betting table we had did not have a call at all.
(02:26):
It happened asynchronously and then a little bit of chat over a couple days and decisions were made. And then in that case there was a couple, small conversations did happen real time, but now with the whole group, just with two people, and that can happen as well. But yeah, it's a process. It's a process of winnowing down, a selection of things to do and weighing all the reasons why and timing and people, and then making the selection that these are the things and then a kickoff is written. That's the outcome ultimately of the betting table, the selection, and then the kickoff, which describes to the rest of the company the projects that were chosen and who's planning on working on them and how much time we're going to give them. And that's sort of how it goes. We can go into detail about specifically things we discussed and whatever, but that's the broad scope for people so they understand.
David (03:17):
I think what's key here is that the betting table and the selection of the pitches, that's going to go into production if you will. That's a job. At least it's a hat, a job hat and can't all have that on. Most of the time it is really like one person, two people who are making the final determinations. They're getting input from a bunch of different sources, and our betting table has actually evolved a bit over the years. We used to do it always on a call where we would discuss the pitches and we would do the final refinement of that pitch. But then what happened was that that call grew bigger and bigger. So we started our call with, I think we started when we started, we were four people on it, then we added one or two people because you wanted to get some different input.
(04:05):
Oh, we should hear from mobile, we should hear from someone on programming. We should hear someone from design. And then I think at one point we did a betting table that had eight people on it and afterwards, I don't know if it was Jason or me who just went like, we're not doing that again. Decision making with eight people is a complete mirage. That's just not what happens. Eight people don't make decisions about anything. A handful of people, and when I say a handful, actually that's too much. One person preferably is the final person who just makes the decision. Accepting that, acknowledging that upfront actually makes the process clearer because it makes the role of everyone else more certain. I think a good example is this last betting table we just did. There was this one pitch about adding a new feature to Basecamp that I think Brian had written it up.
(04:55):
Then someone commented on some technical aspects of it and then Pratik and I took, I think the shape of this pitch is wrong. I think actually the feature is focused on the wrong element. This was something, is it per person or is it per account? Knowing that the role for Pratik and I are to act as advisors, not that this is a power struggle, we're not going to have a freaking vote. We're not going to sit down. Well, if Pratik and I can convince two more members of the jury here, we can get it to go in our favor. Do you know what? That's just a flawed way of thinking about it. It's so much easier, including for people who have perhaps an alternative view on how a pitch should be done to know that in the end, Jason makes the choice. So I'm here to passionately advocate for my view on it ,to illuminate Jason and to some degree Brian as well.
(05:51):
The two people who have the actual hats to say product strategy on are as informed as they be. But they could also disagree as they actually did in this case, Pratik and I raised this point and Jason and Brian were like, actually, we did consider that, which is often what happens. We did consider it, but we think this other way is better. And I think having this whole betting table process and knowing who ultimately makes the choice just smoothes out a bunch of sort of weirdness, a bunch of potential conflicts because you're all in agreement upfront. What are we here to do? What are we here to inform? Who in the end makes the decision? So I think that that is a really key part of it and it's sometimes some of the critique that Shape Up gets is that it's, I don't know, dictatorial or there's just one person who decides and what does that mean for the autonomy and whatever of everyone else.
(06:51):
First of all, as we discussed on the last episode, once a pitch has been handed over to a team, they get oodles of autonomy to actually drive that pitch, but deciding on what the resources of this company should be dedicated broadly to solving for the next six weeks, yeah that is a dictatorial process to some degree. Again, it's an informed dictatorship if you will, but it's not a freaking democracy and it would be way worse off it was. There are companies who can't kind of square this idea of having a product manager, if you will, or a product decider, and instead go into this whole round around like, oh, we're going to do it with votes. We're going to listen to customers are actually going to pick the pitches if you will. We're going to count up how many people asked for X, and then we're going to do the five things that the most people ask for.
(07:44):
That's how you end up with shitty software. That's how you end up with committee-driven software. And I think that's the key part to think here. The betting table is not a committee, it's a council. It's funny, the mental image I sometimes have is this episode of Game of Thrones where they sit at, I think actually we had another thing at one point that was called literally the small council in homage to that. But that's what I sort of think about. You have this table and there's one person who sits at the end who sits and listens. This is what I've observed Jason sometimes do. He'll let other people do the argument, sit back and I will go with Brian and me and Brian would go back and forth or back in the day, me and Ryan would go back and forth and argue strenuously one way or the other. Here's the argument for this, here's the argument for that. And just go like, yeah, I'm going to sit back and I'm going to listen to all the arguments and then I'm going to make a decision on what it is and that's it. And then we move on. Right? And I think that that function, the focusing function, the funneling function of the betting table works best when that's acknowledged clearly upfront. This is not a committee. This is a way to inform the process. One person is ultimate, if there's any disagreement, going to make the call.
Jason (08:56):
Like a cabinet for the president and we're speaking at US politics here or the National Security Council. It's a handful of people, but in that case, the president makes the call, but the president is being counseled and I'm sure none of us have been privy to those conversations, but I'm sure there's heated battles back and forth. Minds are changing as you go. There's a lot of indecision, but at some point a decision has to be made and I think that's how it goes. Oftentimes it's also be someone else might make the call. Brian and I might be working on something or David might be working on something and I might go, I don't really care either way. It doesn't really matter to me, but it sounds like David really caress about this one. Let's go with David's point of view. It's not always, I mean, I'm making the decision that it's David's decision essentially, but that role can be passed around as long as, again, it's explicit. That's the key here.
Kimberly (09:48):
So I'm assuming that there's a lot of pitches coming into the betting table. Some are selected, but what happens to the ones that aren't? Are they reshaped for the next betting cycle? Do they just die? What kind of happens to those other pitches that don't make it in for a cycle?
Jason (10:04):
The first thing is that they don't automatically get a seat at the table the next cycle, but they could sometimes they're like, you know what? We decided not to do that this cycle because we just didn't have time, but we want to do it, so let's save that for next time. But just because it was brought up to the council essentially does not mean it get its opportunity again. So it gets no special treatment, let's just say. But oftentimes if it's really good, it's like the timing wasn't right, but we want to do this later or this is going to fit better with something we're doing in a few cycles because of this new promotion we're running or whatever it might be. So that's kind of how that happens. What we don't typically have is a backlog of ideas that are just sitting around on some long list that we have to work our way through before we're able to do new things.
(10:51):
That's the problem with backlogs. That's my biggest problem with backlogs is they create this guilt and it's like this thing you've got to clear out before you're able to do new things or if you're just doing new things and why have a backlog. Some people get well, so we don't forget great ideas, you probably won't if it's a great idea. It'll come back up again. Something we've talked about for years is that you kind of in a sense want to forget what customers ask for because the things that keep getting asked will remind you what's important and as time changes and as new things happen, the requests are different. The requests might be different in six months, but if it's the same request after six months and it's been the previous six, then there's probably something to it. So anyway, that's how we handle that.
David (11:33):
You can think of that almost like a moving average. You're not making something on one data point for one short period. If something keeps getting requested, that moving average will keep moving up. But I think the other part of this betting table that's so magic is this idea that it's tied to the cycles and it's coming back. You don't have to win this one betting table. You don't have to get everything you ever wanted into the product on this betting table or as Jason say, even on a specific pitch. Sometimes you just go, do you know what? Someone else feels more passionate about that. Alright, that's on you. I know it's going to come back. This is a series of games. This is not a finite game. You have one shot to select all the things that come in. And this is why Shape Up is such a powerful way of working because it builds trust and confidence between the parties that we will have another opportunity to talk about what we should build. And it'll come up quite soon.
(12:35):
It'll come up in literally in two months. We have six opportunities a year to design from a fresh plate what we're going to work on. It's not like we keep overloading, do you know what we've already decided six months into the future what exactly we're going to do? So it's so critical, this discussion right now, what's going to go into that six months because I won't get another shot for literally half a year to influence the direction of the product. That leads to super high stakes arguments, very heated arguments. What I've found is after we've settled on this shape of cadence where we have the six cycles, the temperature of the debates have just steadily been dropping. I remember when we at times would sign off on science projects at times that would take six or nine months and the debates would be pretty fierce.
(13:26):
I remember you stood outside some of those team rooms we had in Chicago sometimes you'd think like, oh my god, these people are ripping their heads off. And some of that came from the exuberance of youth and some of that came from just the idea that it was far more critical to get this one decision, right, because you never knew when you were going to have another shot. Once you've trained yourself and the company and the betting table council that you know what, we're getting another shot in two months, what's the worst that's going to happen? The worst that's going to happen is we're going to kind of squander two months because perhaps we work on some things that you don't think are the most important. Okay, reality's going to tell you that in two months and that's going to be the ultimate lesson. This is how I often look at it. I certainly have looked at betting tables we've done where I go, you know what? I don't think we're going to look in two months and go like, that was a great use of our collective times. And then sometimes I'm just wrong and we push out things and they go, actually, that was a great freaking cycle. And other times I go like, okay, yeah, it wasn't. So that's the argument leading into the next one. So just treating that as you're going to get another shot, you're going to get another chance. Calm the freak down.
Kimberly (14:39):
Okay. I know Jason, you said that after the betting table is when the kickoff is written, and I know that kickoff includes who is working on each feature. Is that something that's decided during that betting table is which programmer and designer person team is going to tackle each of the features?
Jason (14:54):
Typically? Not always, but most of the time because we have to know who we have, who's available to do the work. You can't just create work and there's not enough people to do it or someone's out on sabbatical or on a vacation. So we tend to assign people. If they want to trade for whatever reason, it's not like it has to happen that way, but this is who we think would be the right fit for that. And oftentimes we'll consult or consult those people and say, Hey, how do you feel about this project? How do you feel about that project? But that's less set in stone, I would say. Unless there's a particular skill that's absolutely required for this piece of work, it might be something really advanced that one person has a lot more experience with than someone else, but oftentimes it could be traded.
(15:36):
But the reason it's important, by the way, this is obvious. I mean I kind of mentioned it earlier, but you can be like, oh yeah, we want to do these eight things. Absolutely, let's do these eight things, and you're like, oh, wait, we only have enough people to do four of them. Now what? You don't want to go through all the work of defining the eight things that you can't do. So it is important to assign the people, and again, our teams are two people, one program or one designer. Sometimes they're small projects, so a team of two might get four or five different projects in a given cycle. Sometimes they get one, sometimes they get two. It just all depends. Typically though, the small batch team of two, let's say, they're going to stick together through all the small projects that they're going to do together. It doesn't make sense to keep shuffling the team's inner cycle. Everyone who's basically assigned to something on a cycle is assigned to something on a cycle.
David (16:26):
I think having time to do some of those considerations, who'd be a good fit for this, is also a key function of the betting table, or at least usually the stop between the betting table and the kickoff because you can go like, do you know what? Let's say Anup just worked on this six week project. It was a really long slog the last cycle. It'd be better if he worked on a bunch of small batch stuff. So having that opportunity to mix things up or this person is out on vacation, that's why they're going to be not the right fit for this. This is going to be highly intensive. It's really important that you have to have this abstract idea of here's the pitches, here's the rough budget that we have in terms of time, hours or weeks that we have associated with, and then translating that to both people and a calendar.
(17:15):
So what we often do is we line these things up in blocks and go like, okay, we have these people. Here's how the blocks and the budgets that we have assigned to them are going to line up because it also has to work around things like on-call. So all the programmers that we have will every cycle spend one week out of those eight weeks doing on-call, which is essentially being the second line of response to customers who write in about issues. That has to fit in, and we actually have to fit it in a way that fits with the pitch work that they're going to be working on. If someone is on a six week project, it's not that great if they get assigned to on-call right in the middle. We usually put it at the beginning. I was going to say, or at the end, we used to put it at the end and then we realized that was always a bad idea because if you're on a large ambitious six week project, usually you have some overrun at the end and that then sits an on-call, so some of those lessons just get folded into that process where you go, here's what we want to work on from an abstract sense of budget, which might be, Hey, we have four programmers for six weeks.
(18:16):
None are on vacation, so we have 24 weeks. We should do a little bit of slack, so maybe let's schedule 22 weeks. That's often how we actually do it. We go like, okay, here's the maximum we could do. We rarely try to max everything out because something usually pops up, leave a little reactive room, cut it down like two weeks, 22 weeks, what pitches can we fit into that? And then it is a little bit of Tetris or trade off. You go, here's a four weeker that brings us down to 18. If we're going to do the six weeker, then we're down to 12. That means we can't do these. So that's how we shuffle the board around until you go, yeah, you know what? That kind of looks good. And I think every betting table we've done in a while has that sense of there's something left over and then it spills over and do you know what?
(19:02):
The leftover part is also really interesting because it reaffirms this notion of why it's good not to plan for the future. Because so often a betting table we're really excited about a pitch. We'll go like, oh, we can't fit it in. Then the next table, it doesn't get picked, and that comes from this. You have the context of what you should work on is very determined on now, in a good way, because you have more information now than you did two months ago, or even worse. Some people do roadmaps that are 18 months out. I just go like, geez, I really hope that's somehow worth it for your sales exercises because man would I hate to be locked in 14 months from now for a decision I made in late '21. Yikes.
Kimberly (19:47):
Well, now that I know it's not a secret society with you guys in robes smoking cigars.
David (19:51):
Well, do you know?
Kimberly (19:55):
It's true. I don't actually know there are no photographs, but it's interesting that so much of this is asynchronous. It doesn't surprise me just for how we work. I would imagine for people who are listening who aren't as heavy writers as we are, they're all getting in a room and just kind of chatting this through. Kind of tell me why you think it's an advantage to have so much of this written and asynchronous.
Jason (20:16):
Well, first of all, we're spread out across many time zones and we ask for many people's different opinions. So it's just logistically very hard for us to get together, first of all, to have conversations like this. But moreso, a big part of it is one of the reasons why we're mostly asynchronous in general is because you want people to think things through. So you write something up in detail and you post it and you want someone to think it through, not hear it for the first time in a room where a decision has to be made an hour later, someone who thought about this pitch may have had two weeks to think about the pitch. Why do you only get eight minutes to weigh in on the clock before? So it's about fairness also, and it's also just about contemplation and thinking it through and sleeping on it and whatever. So there's a big part of it that, but also there's a logistic side of it. Still, even if you're a local though, I would encourage you to write things up, let people stew on it for a while, and even if no one says anything asynchronously, at least people had, they were able to consider this a few days prior to the getting together to discuss it.
David (21:18):
There's just a courtesy, I think, in that you don't spring something on someone. The funny thing is we actually changed this recently. We used to do where Brian, who narrows down a lot of the pitches that we end up working on would post the pitches like two days before the betting table, and even that was just not quite enough time. So now the majority of the pitches are posted about a week in advance to give people the time to read the pitch, think it over, and then chime in if they want to or if they have something to say or not if they don't. But we found that even two days of notice wasn't quite enough, and we used to do it on the spot in a broader sense that we'd wait to hear the pitches until we were on the call, which is also just a waste of everyone's time.
(22:08):
What I found at least is presenting work or presenting thinking is not a good fit for live unless that thinking has some controversial part or whatever, really, where you need to smooth out the delivery. That's just not relevant here. It's so much faster. For example, this last betting table, Brian had written up, I think I reviewed six or eight pitches. I think actually it was eight. I reviewed those eight pitches in, I don't know, 12 minutes maybe. It was quite short, and I could just imagine if we had gone through that and someone would have to talk through each pitch, it's not like a podcast where you can, can I just turn you up to three x?
(22:54):
That's just not how it works. It's just a more efficient way of consuming information, and I also find, at least for me, it's a more effective way when someone gives me this whole notion, I often forget, what did you talk about in the beginning? And then I only focus on the stuff you talked about at the end. When you see a pitch that's written up, there's an intent from the writer also, to be succinct, to be tight. As Jason say, often it's 800 words of like, all right, here's my thinking. That's the product of perhaps weeks of contemplation to get to this point, to be this succinct. Just better to communicate that way. And then again, if there is contention, for example, little bit of conflict we had on that one pitch where me and Pratik were like, actually, no, I don't think so. And Jason were like, no, this is how, if I would've like Jason, I think this is just totally wrong. Absolutely not. We can't do this. Here's the reasons we would've do a call. So there's something where you just measure the temperature of the disagreement and you go, if it reaches a certain threshold, that's an indication. We should do a call, and then let's just schedule a call.
Kimberly (23:57):
Okay, well, with that, we're going to wrap up. You can read more about how 37signals manages product development in the book Shape Up. It is available as a completely free download at 37 signals.com/books. You can also purchase a copy there if you would like a hard copy, flip the pages. I think we're all kind of flip the pages book people, and again, if you're a small team competing against big teams, you are scrappy and creative, then you're an underdog and we want to hear from you. We're inviting one underdog to join us for a special podcast episode. You can join that contest by looking through the announcement on our LinkedIn at 37signals and let us know what your underdog story is. Put a picture of your team, tell us your story, and we'll select one winner to join us for a future episode. You can also find more details at basecamp.com/underdogchallenge. Deadline to enter is September 15th. Rework is a production of 37signals. You can find show notes and transcripts on our website at 37signals.com/podcast. Full video episodes are available on YouTube and Twitter slash X, whatever we're calling it now. 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. You can also send us an email to rework@37signals.com.