Product Strategy Q&A with Jason Fried and Ryan Singer

CEO Jason Fried and Head of Strategy Ryan Singer talk about the Shape Up approach to product development that we use at Basecamp. They discuss organizing work in six-week cycles, how to handle disagreement, and how so much of the process boils down to making trade-offs. You can also watch the full video of this Q&A session.

• Going Remote Q&A videos on YouTube - 00:57
• Basecamp’s remote work resources - 1:00
• Jason Fried | Ryan Singer on Twitter - 1:09
• HEY , Basecamp’s forthcoming email product - 1:23
• Shape Up: Stop Running in Circles and Ship Work that Matters - 2:17
• Q1: How do you go about planning something from scratch? What are the different milestones in the product-planning process? - 4:59
• An explainer of six-week cycles - 6:10
• An explainer of finding the epicenter from Getting Real, Basecamp’s earlier book on product development - 11:50
• Q2: How do you decide how far to break down projects? Can you be so granular that you reach a point of diminishing returns? - 13:31
• Shape Up chapter on scopes - 16:10
• Q3: How do you decide which pitches to execute, and how often do you disagree? - 19:32
• Spikeball - 27:55
• Q4: How is potential value creation assessed in the betting process? - 27:58
• Q5: How do you alert someone about work that needs to be done by them? - 34:45
• Q6: How do you do a 6-week cycle for a whole new project? - 37:10
• Inverted pyramid - 38:36
• Q7: How do you pitch the Shape Up process to someone who’s not technical? - 39:28
• Q8: How do you train team members to learn the work process? - 42:28
• Q9: How do conversations with customers fit into the shaping and strategy? - 46:22
• Q10: What do you do about people who ignore the breadboarding and fat marker techniques? - 50:33
• Q11: Is there a utility in using software? - 54:49
• Q12: When approaching features like two-factor authentication or encryption, how do you balance what’s most secure with what’s most convenient for users? - 55:22
• Q12: How did you decide to work on Hey? What’s the bet and how did you structure the team separate from Basecamp? - 1:03:10
• Highrise - 1:03:26
• “Highrise is back with Basecamp” (Signal v. Noise ) - 1:07:22

Transcript

(00:00:00) Anyone You Meet Normcore Remix by Clip Art plays.

Shaun: (00:00:03) REWORK is brought to you by Basecamp. Basecamp is the all-in-one toolkit for working remotely. Remote work is especially challenging when stuff’s spread out across emails, file services, task managers, spreadsheets, chats, and meetings. Things get lost, you don’t know where to look for stuff and people tend to put the right information in the wrong place. But when it’s all together in Basecamp, you’ll see exactly where everything is, understand what everyone’s working on, and know where to put the next thing everyone needs to know about.

(00:00:33) Learn more and sign up at Basecamp.com.

(00:00:39) Broken By Design by Clip Art plays.

Wailin: (00:00:41) Welcome to REWORK, a podcast about the better way to work and run your business. I’m Wailin Wong.

Shaun: (00:00:45) And I’m Shaun Hildner. As many of you know, a lot of folks here at Basecamp have been doing these live Q&A streams all about working remotely. We’ve been playing some of those here on the podcast and they’re also available on YouTube, and at Basecamp.com/remote-resources.

Wailin: (00:01:02) This week, we’re moving one of those live streams into our main feed. It features Basecamp CEO Jason Fried and our Head of Product Strategy, Ryan Singer, talking about just that, product strategy.

Shaun: (00:01:13) Yeah, this isn’t so much focused on remote working but instead, it’s a really unique peak inside how we at Basecamp develop new products, like the upcoming email app, Hey.

Jason: (00:01:31) Hey, everybody. I’m Jason Fried and Ryan, say hi.

Ryan: (00:01:34) Hey-hey.

Jason: (00:01:36) Ryan Singer. Ryan and I have been working together for 17 years? 16-17 years?

Ryan: (00:01:41) Yeah. 17 years now.

Jason: (00:01:43) 17 years. Ryan is the head of strategy here at Basecamp and me, Ryan, and David are the three people remaining who worked on the original version of Basecamp. And we want to take this hour or 90 minutes, or however long this goes to talk about product strategy. This seems to be a really hot topic. People are very curious about how companies, or how we make decisions about what to do and what not to do and where the ideas come from, and how we shape up an idea, how we pitch an idea, how we think through an idea, how we say no to things. All that stuff, including the book that Ryan wrote called Shape Up, and all the ideas in there as well.

(00:02:20) And I want to start, before we take some questions, we’ve got a bunch queued up already, but the thing I want to kind of start with, which is something I think people get confused about, is that product strategy is not about attaining certainty. We’re not out to figure things out for sure. We’re not out to do something only when we know it’s going to work for sure.

(00:02:41) It’s certainly about improving our odds. Sometimes it’s about taking a gamble, making a bet, and all these things that we’ll talk about. But it’s not about certainty. So we’re not out, so people sometimes ask us about research and how do you know it’s the right thing to do? We don’t know it’s the right thing to do. We never know it’s the right thing to do. We know it feels right and we’re comfortable with the risk that we’re taking, but we’re not out to know for sure if something’s right or wrong or going to work or not going to work.

(00:03:08) So I want to sort of set the tone that way, because it is a different approach than I think most companies follow which is that they’ll research and research and research and second guess over and over and over to try to get to 99% certainty on something before they take the leap. And we think that’s very expensive, very slow, and just as likely, probably, to be wrong as being 75% sure-ish.

(00:03:32) So I wanted to start with that. I don’t know if you want to add anything to that, Ryan, before we jump into questions, but I think that’s an important point.

Ryan: (00:03:35) Yeah, a huge piece of that is we’re able to do that because we cap our downside. So if we just had no idea if anything was going to work, but then we blew a year on it, and did nothing else, then that would be a problem. But most of the things that we’re doing, we’re doing six weeks at a time and we’re very conscious of, if it takes longer than the amount of time we were willing to give it, then we fire the circuit breaker and we cut the thing.

(00:04:02) So it’s okay to be wrong if we know what we’re going to lose. It’s not okay to be wrong if it’s a never-ending, open-ended quest to nowhere. So that’s a big piece of it.

Jason: (00:04:13) Which is why I like the bet language so much, that we place bets. And if you place a bet and you know what you’re betting, like, I’m going to put $100 on black, or whatever, and I’m playing roulette. I can’t lose $101. I can’t lose $5,000. I can lose $100.

Ryan: (00:04:26) Yep.

Jason: (00:04:27) And I’m comfortable losing that. That’s an important part here, and the difference—

Ryan: (00:04:31) And you set that up front.

Jason: (00:04:33) Yeah, you set that up front, versus, well, there’s this idea we’re going to go for. I think it’s going to take three months, well, it’s taken four, now it’s taking nine, now it’s taking 12, now it’s taking 18. We basically, another company my have bet three but lost 18. We never want to be in that situation. If we want to continue, that’s fine, but we have to put down more and I think that’s a really nice way to think about these sorts of things.

(00:04:54) So, anyway, let’s jump into the questions, there’s a ton of them.

(00:04:58) Vivek says, “How do you go about planning something from scratch? Let’s say, for something like Hey.” For those who don’t know, Hey is a new product we’re about to launch. We’ve been working on it for a year and a half or so. “What are the different milestones in the entire product planning process?”

(00:05:13) Okay, I’ll start this one. We don’t plan out the product up front. That’s number one. So this is not about laying out all the milestones. This is not about knowing everything on day one. What we know is we’ve become comfortable with the idea. We’re willing to put some R&D time into it. Maybe it’s a few months of puttering around with some prototyping. And then at that point, we’re like, is there anything here?

(00:05:39) And if there’s something there, then what we do is we begin by kicking off the first few things we know this thing needs to do. Not everything it needs to do, because we don’t know everything it’s going to need to do. But what are the first few things so we can begin to use this thing as we’re starting to build it. And as we go, we discover new things and we undiscover stuff, as well. We thought something was going to work, turns out it doesn’t. Or we thought this approach might work, it turns out it doesn’t.

(00:06:03) And we’re doing this typically six weeks at a time. We can talk about six-week cycles as we get into this. I think there’ll be more questions about that, but every six weeks or so, we’re working on a handful of new things and we go and we go and we go on that cadence planning six weeks at a time until we get to a point where we feel like there’s enough here that the idea is well-rounded enough that we’re not feeling like anything really fundamentally is missing. And then we feel like, we’ve kind of wrapped this into a product now. That this is ready for v1.

(00:06:33) And I know I’ve jumped over a big stretch of time here, but really it’s about a little bit of R&D, getting comfortable with the idea. Thinking that there’s a business case here. Of course, we have to build things that are going to make money or make sense for the business. And then beginning with the few core things we know it needs to do, and then branching out from there until we feel like the tree is full of enough leaves that it can basically feed itself is kind of how we think about it.

(00:07:00) Once we launch the thing, after that, we then get more feedback from the outside world and we start to adjust from there. But that’s, in a nutshell, in a very broad sense, how we think about planning a product.

Ryan: (00:07:09) Yeah, there’s basically three phases that we go through where we’re doing different kinds of work and we’re working together differently. So in the first phase, which Jason mentioned that we call it the R&D phase. This is the phase where we don’t actually know what the product is. We can’t see the actual tentpoles and load bearing structures of the project. The product. The core architecture isn’t figured out yet.

(00:07:39) So we’ve got some hunches and we think, like let’s say, early days Basecamp. In the early days of Basecamp, it’s like, this is going to be a password protected place just for this project and it’s going to have a message board and some kind of, maybe a file thing and some milestones. We didn’t even actually have to-dos in the very, very first cut of Basecamp because it was all about communication. What we’re doing in this very first R&D phase is we’re not carefully shaping something that is supposed to get built in delivered by a certain date. Instead it’s like, we’re going to commit, let’s say six weeks, to exploring and trying to build a few of the most important things, that we think are the important features. In that R&D phase, the shaping and the building are happening together in kind of a slightly confusing mix. You’re going to try something, and then four days later, you’re going to be like, oh, that’s totally not the right way at all, let’s try this other direction instead.

(00:08:36) And then you’re going to be a week in and you’re going to rip up all the database modeling that you did because it wasn’t the right approach and you’re going to try something else. That kind of busting concrete and ripping things up? That’s part of doing a completely brand-new product from scratch. You can’t work like that forever because you can’t give a team a project and say, hey, in six weeks, this is supposed to ship. But they’re going to be ripping up the concrete halfway through? That doesn’t work.

(00:09:01) So there needs to come a point where the architecture is clear, the basic features are actually built and working, and now you say, we believe in this and we think that it’s going to do, in macro, what we hoped it would do. But there’s a million things that are still kind of left to do. The things that are undone and cracks that need to get filled in.

(00:09:21) Then we switch to production mode. So this is the second phase of the work. This is where, now, we’re still working in six week cycles, but instead of just kind of exploring and building stuff as we go in the six weeks, we’re making very deliberate bets on very specific feature concepts that fill in the missing spaces between the tentpole features.

(00:09:43) So this is where we can switch from… in the first phase, we only have one team working and it’s a very small core team who are the main decision-makers for the product. Like, Jason and David are going to be involved in the very, very first rounds of the R&D phase because this is their idea and they’re trying to figure out how it should get to what it should be.

(00:10:06) But then, once the core architecture is clear, they can open it up for other teams to start doing projects because it’s easier to delegate because the boundaries are there. So then this second phase, the production mode, is when we’re using straight Shape Up methods. All of that applies to that second phase. And then this runs for most of the course of building out the rest of the product, once the core architecture is there.

(00:10:28) And then finally, there’s a third phase which we don’t have a name for it yet, but we just started to identify it. And I think Jason just started to point it out as we were working on Hey, which is that there’s a phase toward the end where, actually, we dedicate time, but we again don’t know what it’s for. So it’s kind of like, look, there’s just so many random things coming up, random loose ends, little things you want to polish, things that nobody expected that need to get filled in in the last, maybe, final six weeks before shipping, or maybe a couple cycles before shipping. And it’s just kind of a mishmash of all kinds of stuff that needs to get filled in. And it’s nice to allow that freedom.

(00:11:06) So, again, we’re sort of moving away from a very specific shaped bet to, we have an appetite of another six weeks of just kind of filling in anything we can find to get this into the best shape we can before we launch.

Jason: (00:11:17) And let me add one more quick point about something really concrete about Hey, since you asked. The first thing Hey had to do was, it had to be able to receive an email so that was the first feature. We didn’t have to know if it was going to have folders or if it was going to have this, or have that to build, let’s just let it receive an email. And then the next thing is like, well, naturally, I want to reply to that email. So that was the next thing we kind of built. I don’t even think we built composing a brand new email from scratch. I think we could only act on something that was sent to us. We kind of start from this really core thing it has to do, which we call the epicenter and we work out from there. We don’t need to know where there is yet, but we eventually figure out the shape of this thing as we’re going.

(00:11:57) And we know, in my head I know there’s seven or eight features, right now, I can think of, that I’d love to have in this thing. It’s not going to have that v1, because they’re non-essential. They don’t need to be there. It’d be nice, but you have to draw the line somewhere and there’ll be an infinite amount of time ahead of us to add more things as we go, and we’ll discover new things as other people start using it.

Ryan: (00:12:16) That’s another key point that we actually, we start also with the most important unknowns. So it’s also, planning kind of isn’t the right word. It’s really like, unknown attacking.

(00:12:28) When we built Hey, the first cycle didn’t have a username and password management system. The first cycle didn’t have sign up. The first cycle was the core things of interacting with the email, and especially the things that started to touch on our unique opinions about things we wanted to do with the email. Those were the things that we needed to figure out first and stuff like signing in, and user management, all that stuff was kind of hardcoded and hacked in because that’s not the stuff that we had to learn.

(00:12:57) So that’s a huge part of this. When we were first doing Basecamp, the first version, it’s like, can we make this kind of message board comment thing that’s behind a password. Is that going to work? Is that something we’re going to want? So we built that with that question mark hanging in front of us and the whole goal of the early iterations is to sort of answer those questions. Is this what we think it is? Can we build what we think we want? And can we figure out the technical things we have to figure out so this things starts to hang together?

Jason: (00:13:27) All right, cool. Let’s take the next one. Next one, from Kenny: “How do you decide how far to break down projects, tasks, lists, groups, tasks? Can you be so granular that you reach a point of diminishing returns?

Ryan: (00:13:41) Yeah, I’ll speak to this. So the first thing is who is actually involved at what level of granularity? In some companies you have a kind of architect person who’s creating tasks and then sort of putting those tasks up in a queue and then developers are grabbing those as tickets and saying, kind of, okay, I’ll take this one, I’ll take this one, I’ll take that one.

(00:14:06) We have a very different approach. We’re not actually defining the tasks at the level of task granularity for anybody else. We never define tasks for other people, actually. So from the shaping side, so from myself and Jason and David, when we’re sort of figuring out what the project is, we’re going to figure out what is the concept of the project, what are the main pieces of the solution, how do we think it’s going to work, and then we’re going to give that project to a team. And when we give that project to the team, there are no tasks at all and nothing below tasks, either. Just here’s the thing to build, here’s the concept.

(00:14:45) Then the team is going to actually start to build out lists and tasks. And the main thing that they’re using those for is actually to capture. So it’s not a plan, it’s not like we’re going to come up with all the tasks and then we’re going to build all the tasks and we’re going to be done. It’s more like, they’re going to try and start building something that’s in the concept. And actually the tasks come from trying to build it. You have to totally flip the way of thinking. It’s not that we create tasks and then we go build the tasks, it’s that we try to build something with no tasks and then by trying to build it, you go, oh, I’m going to have to connect this to that. Oh, we’re going to need a screen to make this setting. And oh, I’m going to have to remember to make a mobile view of this button that appears on the left corner of the screen, right? And then as you bump into these things, then you want to capture them.

(00:15:39) So the tasks are a way that the team basically can put all the things that they discover that they have to do into a place so that those things aren’t going to get lost. And then as far as the level of granularity goes, we have two levels in Basecamp. There’s the list, which is a collection of tasks and then there’s the individual tasks. And we can get into that more, but we have a method to that. And that’s where, actually, the lists correspond to what we call scopes, which are meaningful chunks of the project that we can finish independently of each other. And that’s something that we go into quite a bit of detail in Shape Up.

Jason: (00:16:18) Yeah, one other thing about that is whenever I show our own Basecamp projects, people are surprised that… like they’ll look at a to-do list, they’ll go that’s it? Where’s all the tickets? Where’s all the other stuff? What they’re expecting to see are hundreds and hundreds of to-dos, or tasks for features that need to be built. And it turns out, there’s like, on any given list there’s a dozen, or two. It depends. I’m generalizing here. But to your point about granularity. If there’s nine little tiny steps involved in hooking up the sign in button to the log in form, we wouldn’t break those out into nine separate things. It’d be like, make the sign up button work.

(00:16:57) That’s kind of enough for the person who’s doing the work to know what they need to do to get that done. And then if there’s a discussion about it, we talk about it in the comments below the to-do. Versus trying to break out every individual thing, because then you end up with super long lists and super long lists collect dust. They’re intimidating. It feels like you’re not making any progress and the act of having to break things down into that level of sand, it’s too much hitting of a rock. You don’t need to break it down into tiny granules all the time.

(00:17:28) So anyway, I think that a few dozen things for an individual feature seems to be about right, max, anyway. And that’s about enough. Of course, I’m generalizing here, but really it’s not—if you feel like you’re adding too many individual tasks, you probably are. There’s probably too many, you’re tracking too many small things. Then you forget to check something off and it’s late that you’ve already done, and now you’re setting up work for yourself. You don’t want to make this hard on yourself, but you also don’t want to make it so general that it doesn’t communicate to other people on the project what’s left to be done. Because to-dos aren’t just for you, they’re communications so other people can see where you are in the project, and where things stand.

(00:18:06) So the thing is, is that when you work this way and when you use a tool like Basecamp, this is everything. There’s not hundreds of tickets laying around somewhere, there’s not a separate app you need to track every tiny little piece of work. There’s not one place where you collect all the work that needs to be done in a separate product and then another place where you discuss it and another place where you share status. It’s all right here in one place.

(00:18:28) And yeah, of course, I’m pitching Basecamp in a sense, but it’s deeper than that. It’s a different philosophy of work which is when everybody can see the same stuff and they use the same tool, communication becomes a lot simpler. Anyone can jump in, check out where things stand. Anyone can ask a question in the right place and you don’t have to wonder, is there this whole mountain of work I haven’t seen somewhere else? And I don’t have access to that thing because I wasn’t given access to that thing and I don’t even know that thing exists, but shit, there’s 30% of the project’s not done because it’s over here somewhere else.

(00:18:56) They sound like subtle nuances, perhaps, but they have significant impact on what you’re capable of doing and the amount of time you’re capable of doing it in. Team morale. The ability to keep a team small and the ability for the team to self-manage itself.

Ryan: (00:19:11) That’s huge, the self-managing. The other thing is that our teams don’t need to have product managers or project managers because we’re assigning the project to the team as a whole and the team is self-organizing to figure out what needs to get done and how to track that amongst themselves.

Jason: (00:19:28) All right, next one. All right, Demetrius: “When you discuss your pitches and you decide what projects to execute, how often do you disagree and how do you reach a decision? You, David, and Ryan vote?”

(00:19:41) This is good. So, we’ll disagree often on fundamental core ideas and then we have a discussion about them, sometimes via comments in Basecamp, sometimes we’ll jump on a video call to discuss it. The goal here is not consensus. That’s not what we’re after. We’re after a shared understanding of the idea, the fundamental pitch that came out of it. Maybe we each contribute some different ideas to it that reshape it in different ways and mold it, and push in a different direction. And oftentimes that’s enough for us to all, not get on board, because that was the goal, but for us to actually see the same thing. Go, yeah, yeah, that’s actually the right thing. Not like, no, I wouldn’t do it this way, but I’ll come along for the ride begrudgingly. Not that. Just, like, let’s find what this should be together, we’ll kind of get there.

(00:20:30) And then when we don’t, sometimes we don’t. And when we don’t, we have this notion of disagree and commit. That there’s a point in a discussion and a conversation where, if you’re someone who disagrees with the direction but the other two people think it’s the right direction, or the one person who’s making the final decision thinks it’s the right direction and willing to bet on it. You go, look, this isn’t how I would do it, but I’m all in with you. Not begrudgingly, that’s the key. It can’t be begrudgingly in. You’re like, I may not want to see this work well, and you get this one. It’s like, when two friends go out for lunch sometimes you split the bill, otherwise someone pays for the whole bill, and you’re like, I’ll get the next one.

(00:21:06) And you kind of trade concessions, you trade agreements, you trade disagreements, but the idea here is not to bend people’s arms to get them to agree with you. It’s to make your case. To put that case out there. To have the other people who agree or disagree help mold that case and come to something that you can either all agree on because you all think it’s the right thing, or at some point, one or two people agree, someone else doesn’t, and you go forward anyway because you have a shared understanding that maybe you’re wrong, or I agree with this, or, I’d do it a different way, but this seems fine to me, as well.

(00:21:35) So we’re not trying to bat 1000 here. We’re not looking for perfect records. We’re just trying to make progress and trying to get everyone to agree to everything is a really bad way to make progress because you tend not to get anywhere if that’s the end goal.

(00:21:50) Some of this is relationship-based. The fact that Ryan, David, and I have been working together forever makes that really helpful. It’s probably much harder to do if you’re three people who are a year in at a company and jockeying for position and all those sorts of things. But getting to that shared understanding and realizing that you can’t have everything you want all the time and other people have great ideas that you might, perhaps, have missed, or maybe do it differently but this is fine. Coming to that is I think, a really important maturity step for an organization and the people who are working together on something.

Ryan: (00:22:18) Yeah, a couple things that are important here. Again, the fact that we’re capping our downside to no more than six weeks is huge because you can’t say, look, you get the next one if the next one comes a year from now.

Jason: (00:22:28) Right.

Ryan: (00:22:28) But if the next one comes six weeks from now, not as big of a deal. So that’s a huge part of it. The other thing is, I find it very helpful that when Jason and David and I are talking about something, I feel like we’re always having sort of two different debates when any idea comes up. One debate is, is this the right solution? The other debate is, does this matter? And it’s really important to be able to separate these two discussions of is it the right solution and do we actually agree on the problem.

(00:22:59) If I were to pitch something and David shoots it down because he has a bunch more context on what it’s going to take to do it technically, that idea might not happen because he says, no, I’m concerned about this, that, and this on the technical side.

(00:23:13) That’s very different from David saying, this problem doesn’t matter and I don’t think it’s valuable to try and solve that. Because if there’s a technical issue with it, I can go back to the drawing table and try to find another angle on it. And then come back and bring that conversation again, in a future cycle. Versus if Jason and David were to say, we don’t care about that, that’s not something we want to improve, then I know to just let that go and focus on something else.

(00:23:37) So I feel like there’s always sort of these different, there’s the moment when you come together and you bring whatever you have that’s actually clear, as a proposal. But then there’s also all the things that you’re working on, based on your… especially if you’re an employee. You need to be able to read what the owners actually care about and where they want to go with things. So you have this sense of, what are the areas that are worth working on and what are the things that seem to be solutions that they’re going to go for, and how do I keep those things separate and clear in my mind?

Jason: (00:24:09) Another thing I would add to this is that I’ve found it helpful to think that, I don’t want to get so attached to an idea that if it doesn’t happen, I’m going to be flat-out pissed. That’s just not a good place to be, either. And so, I think coming into it realizing, first of all, most of the ideas we pitch don’t happen. That’s true to begin with. So coming at it from that perspective, it’s like, everything’s a long-shot anyway. And when you come at it that way, disagreements don’t matter so much. You’re a little bit more motivated to go, well, how can we make this, maybe not such a long shot. Maybe a shorter shot. Maybe a little bit closer to reality. And then it’s more of a collaborative effort, versus, here’s my idea, this shit better fucking happen, [crosstalk] four years working on it. No, no. That’s where you get into these conflicts and people get upset. So we tend not to do it that way.

Ryan: (00:24:56) I like to go into it with a sort of, like, here’s a kind of a mindset. If I bring an idea in and then Jason can cut it in half and be like, look, I think all we need is just this one little part. We don’t even need the rest of it? That’s actually an exciting moment. That’s not like, oh, you killed my thing and you made it smaller. It’s still like, wow, that’s awesome that we can do that with just half of it. It’s also like having this sort of feeling and trust that because we each represent different points of view that we can actually really improve an idea that somebody brings to the table. If we consider it to be sort of still like wet clay when we bring it in.

Jason: (00:25:34) And speaking of that, most of the ideas that are brought to the table end up smaller.

Ryan: (00:25:40) Yeah.

Jason: (00:25:40) They rarely end up bigger. They end up smaller because David cuts it back or I cut it back or Ryan cuts it back, and that’s because we’re seeing through to something else that maybe the person who wrote it doesn’t see, or we have a different perspective. So yeah, it’s not about ownership of these things, and it’s not about, I want this whole thing to happen. It’s like, what are we trying to do here and can we all figure out a way to do it together, and can you see something I haven’t seen?

(00:26:02) And then sometimes, yeah, there’s disagreements and it all comes down to the degree of it, as well. How important is this?

(00:26:07) For example, let’s concrete for a second. Yesterday, David and I had a conversation about what project we’re working on for Hey, which is a demo account. Right now I’ve been demoing Hey for people I know, using my own personal account. My own personal email. Not good, it’s just not good. But putting together a demo account takes time and there’s different approaches to it. Do we generate all fake information? Do we have somebody internally write fake emails or real emails that are fake? Do we pull sample emails from individual accounts that aren’t consequential if someone sees. What’s the approach? Also, is this spun up fresh every time? Is it a constant demo that I just jump into and I pick up where I left off? There are all these different versions of this thing.

(00:26:53) And David and I had a little bit of a disagreement yesterday about how to approach it. He didn’t understand what I wanted to get out of it, so he came at it from a different perspective. But then when I said, well here’s actually how I want to use this thing, he goes, oh, okay. Well, given that, then that makes sense. Or, given that approach then we can do it this other way. So a big part of this is coming to understanding and not coming at it ready to butt heads about defending your idea.

Ryan: (00:27:21) This is what we call appetite.

Jason: (00:27:23) Yeah.

Ryan: (00:27:23) Right? How much do we want to put into it.

Jason: (00:27:28) So hopefully we hit that one from a bunch of angles, but there’s, the thing is with this product strategy stuff, there is no here’s how you always do it kind of thing. Ideas are different, timing is different, market conditions are different. You may disagree with yourself tomorrow, your own self tomorrow about something you pitch… it’s just about thinking things through and being fair and having conversations about it and not bringing ego to the table, basically.

(00:27:55) Spikeball, our friend Spikeball in Chicago, here we go. “I know you don’t really use goals, but is part of making a bet trying to quantify the impact or what the impact might be? How is potential value creation assessed in the betting process?”

(00:28:08) Ryan you want to shoot that one?

Ryan: (00:28:09) Yeah, sure. So, first thing is I’m going to be a broken record and talk about capping our downside again, because the main way that we look at everything is, look, if we suspect that something good can happen out of this, that’s all going to come as a happy surprise. So any upside we get out of this is, awesome, something worked. Because we know that the downside is very limited because we’re making pretty small bets, six weeks at a time. That’s the first framing.

(00:28:37) Then the second is sort of, of course we want things that are going to have a bigger upside instead of things that have a smaller upside, right? But we don’t need to have, necessarily, a quantitative measure or a KPI, or an OKR or something like that in order to do that. My favorite way of thinking about this is I want to look at not the idea of what we’re building, but the struggle that the thing that we’re building addresses.

(00:29:02) So if there’s a pain point of, man, I keep wishing that we could do this. I keep wishing that we could do this. Then, that’s going to drive it and we’re going to feel like, man, this is going to be such a big improvement if we solve that problem. And sometimes we’re going to have something coming in from customers where they are all complaining about the same thing and we don’t expect it to make a huge jump in satisfaction in the product, or sales in the product. But it is something that’s going to quiet down some unhappiness in support. Then we might dedicate a small batch project to that.

(00:29:35) There might be something, like some things we’re doing for BC4 right now, that we’re talking about, that we think could actually meaningfully increase the addressable market. That there’s people who we think are turning away the product because it’s missing something and that if we put that in, that there’s going to be a meaningful chunk of people who are, the product is going to come back into the consideration set for them. The way that we work here, we don’t need to quantify that with a hard number. I think it’s much more about looking at we’ve got maybe four ideas that we’re all sort of interested in, and can we rank those in terms of which ones we are the most excited about, about the pain that they solve, or the opportunity that they unlock.

Jason: (00:30:17) And sometimes the impact is we just wanted to do it. There’s some ideas that we just want to do and the impact is, we needed to scratch that itch. It’s not even something we’ve ever measured, it’s like, is it done? Does it exist now. Before, it didn’t. That’s enough sometimes. So it kind of depends.

(00:30:37) I think every time we ever tried to pick a number, like, if 20% of people use this, then it will have been worthwhile. It’s like, why 20? Why not 18? Why not 22? Why not 19.3? You start chasing these false numbers, these false round, even numbers, and then you either hit it or you’re disappointed because you don’t. And then you think, well, was it worth it, again? What did we do wrong? How did we do this wrong, and you go down this rabbit hole of trying to figure out how you did it wrong. And it doesn’t really tell you anything about the next time you’re going to do it.

(00:31:11) it’s like, oh, if we only would have done, interviewed 15 more people, we would have figured this out. Well, maybe. Maybe not. And how long would that have taken? And if that would have pushed the thing off four months, would it still have been worth it? You can’t look at things so independently. Everything’s a system and everything moves everything else. So it’s like maybe instead of 20%, if your number’s 20%, and you only get 15% or whatever? For whatever reason? Yeah, maybe you could have gotten to 20 if you would have talked to 20 more people. Or 30 more people. Or done this, or done that. But at what cost? What’s the trade-off for that, too? We could have spent four years and we would have gotten to 20. Would that have been worth it? You would know that no, of course that wouldn’t have been worth it.

(00:31:50) So you can’t set up these fixed points, I think, without considering the trade-offs of what it takes to get to those points to begin with. And also, why are those points… it’s like, it feels like a lot of busywork to me. Versus, if you really know the product really well, if you really listened to the customers, if you hear a lot of things from support. Like, right now we’re working on some stuff for Basecamp 3 we know is going to hit for people because we know what they want. We’ve been talking to them for a long time. It doesn’t matter if it’s 37% or 22%, the people who really want it, and we know there’s a lot of them. I don’t know what the number is, but it’s enough. They’re going to be thrilled with it, and we know that that’s going to be true. And that’s a feeling that’s enough for us. Versus measuring the quantitative version of that feeling. I don’t know what that means, so.

Ryan: (00:32:36) I would even throw out another way to think about this. Now that I reflect on it for a moment, I think, actually, I’m actually trying to quantify the downside, not the upside. We can quantify the downside. We can say how many weeks are we going to spend.

Jason: (00:32:51) Yeah, that’s a good point.

Ryan: (00:32:52) Which means, how many weeks are we going to lose. And actually, I will do data analysis. If I’m afraid that the thing that we’re touching is going to screw up an existing flow for people, screw up, not improve, then I’ll actually look at traffic data on a specific feature and I’ll say, you know, we’re maybe interfering with… So there’s something we’re working on right now that might impact a report in Basecamp, which is the to-dos completed report. And I’m a little worried about the impact on that report of this new feature, so yesterday I looked at the usage data of that report and I saw that the usage data on that report is about a quarter of the usage of the other main parts of this feature and it helped me to relax because it made me think, okay, even if we’re kind of wrong, this is not the high traffic area of the app. The stakes are a little bit lower.

(00:33:45) The thing is, you only have so many ideas that are actually compelling at a given time. Based on your theory of the market, of what you understand customers are doing and what you think is working, what doesn’t work. You have a theory of the market. You have a few ideas that are compelling and then you can’t measure how they’re going to do but you can sort of measure the cost of what could go wrong. So I think that’s a way to think about it.

Jason: (00:34:07) That’s actually, I’m really glad you mentioned it, because that is really how we think about it. It’s like, is this worth doing? Is this worth fixing? Is this worth setting up some time for? And if we spend this time, will we be disappointed in the way we spent it?

Ryan: (00:34:22) Yeah. There’s opportunity cost in time and there’s opportunity cost, or sort of loss of options in space. I don’t want to put some giant honking thing on the homepage that I’m not going to be able to take away if I don’t really believe in it, because I’m going to need that space on the home page for some new thing in the future, right? So I think it’s really about options and preserving your options. Jason: (00:34:41) Yeah. This one’s coming in from Twitch. “If no one can create tasks for another person, how do you alert someone of a need you’ve discovered that needs to be completed by them?”

(00:34:50) Oh, people can absolutely create tasks for another person and we do that quite a bit in Basecamp. The point is, is that it’s not someone sitting up on high who’s imagining everything that has to be done and then writing 200 tasks and assign those out to people. But people who are working together will often create tasks for one another. So that happens all the time.

(00:35:14) Or, if you’re working cross department, like you need Jane, Jane’s our Data Analyst. If you want Jane to look something up, she has a to-do list set up in her team, in her data team project inside Basecamp that says requests. And you can put a request on that list to ask her to look something up for you. So we can ask each other things like that. But most people who are working together will create to-dos for each other. The point was there’s not this central task-creating person who’s just doling out work for everybody else. That is not how we work, nor do I think it’s the right way to work.

Ryan: (00:35:46) There’s a big difference between tasking a person with a thing and discovering and capturing something that has to be done for you all to be successful as a team. If there’s a piece of design work that needs to happen for a project, that thing either needs to happen or it doesn’t need to happen for the whole team to be successful when this thing ships. Because if they forget that thing then there’s a hole in the project. So there’s a team that’s working and they are a team and they’re the ones doing this work when we have cycles. Inside of that team, if somebody catches something, they’re going to capture and add a task regardless of who it’s for because they discovered something that has to be done. That’s what’s important. It’s not like, I am the project manager tasking you to do this thing for me. It’s like, hey, don’t forget, this thing has to get wired up, or we need to have a mobile view of that thing over there.

(00:36:41) That’s when you’re working together on the same thing and you have the same goal of this has to be whole and complete when we ship. If you’re not on the same team and you aren’t together working on the same project, then it’s not so much about tasking, it’s more about asking. Like, hey, can you help me with this? Do you have time for this? Are you the right person for this? When would be the right time to collaborate on this? And that actually starts off with conversations most of the time.

Jason: (00:37:06) Next, Tim: “You do this six weeks betting process for features in Basecamp, but for a whole new product that would likely take longer than six weeks, it wasn’t clear how Shape Up would apply?”

Ryan: (00:37:18) I think we answered that at the beginning so I’m not sure if Tim joined after the very start.

Jason: (00:37:21) Yeah. Real briefly, a whole project, a whole new product is a series of six-week cycles. We wouldn’t build Hey, we can’t build Hey in six weeks. It’s taken us 18 months-ish, or whatever it’s been. That’s eight or nine or ten, whatever it would be, six-week cycles. Plus, the time ahead of that to decide if we even want to do the product at all. So that’s kind of how that works. Everything is one after the other, but one at a time. So we don’t plan, just to add a little bit more color, we don’t plan the next six six-week cycles, we only do one at a time. And we’re starting the next one April 20th, I think, is our next six-week cycle. And we haven’t fully even planned that one and we have ten days to go. But we don’t have anything planned after that.

(00:38:06) So this is not about lining up everything that needs to happen over the next 18 months in six-week chunks, it’s simply the next six weeks and at the end of that we take two weeks to look around, like, look up again and go, how do things look here? Where are we? What’s going on? What else do we want to work on next? What’s the most important next thing? What are we feeling like working on? And we kind of literally make up as we go every six weeks at a time until we’re done.

Ryan: (00:38:32) Journalists have this thing called the inverted pyramid, and the notion is that the very most important things have to go at the front of the story that goes in a newspaper and then, because they don’t actually know where the editor is going to cut the bottom of the story so they can fit it into the layout of the paper. So you don’t want to have something important in the story at the bottom of the story because it might get cut out. But something at the top of the story isn’t going to get cut.

(00:38:56) So the way that we think about six weeks at a time is like that inverted pyramid. What are the most essential unknowns that we have to solve, or the most important tentpole features that we have to put into place, and we’re very disciplined about getting those important things fleshed out first, early in the series of the six weeks. And that way, if we start to feel like, you know what, this thing has got to ship soon. Or, we don’t want to put more cycles into this, that those things that are waiting at the end should be more like, polish and minor improvements instead of major pieces of functionality.

Jason: (00:39:27) Ryan, this would be a good one for you. Do you have advice or tips on how to pitch the Shape Up process to an executive team that’s not technical.

Ryan: (00:39:33) Yeah. So, the only reason to ever change the way you work is because you’re suffering. There has to be some struggle on behalf of the executive team that they can relate to in order for them to be interested in any kind of a change at all. Why change if they’re not experiencing a problem? So the main problems that I identified for people who are adopting Shape Up so far are things like, we never seem to have time to think strategically. We’re so busy micromanaging that we can’t get ahead and think about the visionary things that we need to think about in order to take the product to where we want to take it. This is one thing.

(00:40:10) Another thing is we’ve grown and it used to be that we could just decide what we wanted to do and then it happened, but now it seems like whenever we set direction the times kind of get knotted up into a big tangled ball. And why doesn’t the thing that we wanted to do ship? Why can’t we ship like we used to? Right?

(00:40:30) This feeling of a lack of control, a lack of being able to steer the ship, that’s maybe something that they can relate to. If you’re not having those problems, then there might not be a reason to change. But if those problems are there, then the practices are going to map directly to solving those. The shaping and betting process, removing discovery from the teams and putting that up into the shaping and betting process that senior people do is the equivalent of putting the hands of the executives on the wheel and allowing them to steer where the product goes in a more intentional way, cycle by cycle.

(00:41:05) Giving the teams more autonomy by shaping the work and then giving them latitude inside of the shaped work to figure out the details is what frees up leadership to have time to think during the cycle because they don’t have to micromanage the execution and come up with small tasks and stuff like that. But they get to give the product to the team, trust that the team is going to get somewhere on their own, and then while the team is building, think about the next thing.

(00:41:28) So those are maybe some ideas for where to start.

(00:41:30) Anyone You Meet Normcore Remix by Clip Art plays.

Shaun: (00:41:35) We’ll get back to Ryan and Jason in just a moment. But first, how about a work from home tip from Basecamp’s head of marketing, Andy Didorosi.

Andy: (00:41:43) My work from home secret is that I listen to James Brown pretty much all the time. It helps with the background noise. All of his songs are pump-up jams, every single one. I think, without fail. And he just keeps the energy going and so even now, especially with all that’s going on outside, James Brown is more important than ever. So, pump it up.

Shaun: (00:42:07) If you have any tips for working from home, give us a call and leave us a message at (708) 628-7850. Or, even better, you can record a voice memo on your phone and email it to hello@rework.fm.

Jason: (00:42:27) Cool. Let’s go to the next one. “How do you train team members to learn the work process?”

Ryan: (00:42:31) You hold them by the ankles and you walk over and over to the pool and then you release.

Jason: (00:42:37) What Ryan’s—

Ryan: (00:42:37) You know, it’s the—

Jason: (00:42:39) What Ryan said. We—

Ryan: (00:42:39) Learn by swimming.

Jason: (00:42:40) Yeah, this is, how we’ve done it is a little bit more of an apprentice-y model which is that we don’t, when we hire someone new we don’t force them to read anything or… we get them involved in a real project. And getting them involved in a real project helps them see how people who know the process do it and I think they pick up a lot that way. That’s different, though, from starting a new process company-wide or in a team with no one who has any experience. That’s a totally different thing.

(00:43:08) But I think if, let’s say there’s three people working on something and two of them are very experienced and someone is new and junior. The new and junior person, everyone understands that they’re new and they’re junior and that person observes and they learn by watching and then they learn with gentle course correction and reminding them of this and reminding them of that and seeing other examples of things.

(00:43:27) Which is one of the real benefits, too, of writing things up. Especially if you use something like Basecamp, people can join a company and look back over the decisions that were made. The descriptions of work that was done. The ideas that were pitched. Versus, if you’re a verbal company and everything’s happening in meetings and stand ups and stuff, and you’re brand new, how do you learn anything about the institution that you’re joining?

(00:43:49) You have to take people’s words for it because they’re telling you through verbal history of what kind of happened and how it happened, versus when it’s a written history, you can study. You can study up. You can read, yourself. You can see examples. You can follow examples, and I think that’s a really wonderful way to learn something. It’s really beneficial for new people to be able to look at the past that way.

(00:44:10) But as far as learning a whole new thing, Ryan, you probably have more experience with this because you’ve been hearing from more teams who are adopting Shape Up. What have you heard?

Ryan: (00:44:16) Yeah, so the mechanics are kind of the easy part. This is where the to-dos go. This is where you put your update. This is how we kick off a project. Those are the things that are easy to see. The thing that is actually important is that people learn how to make judgment calls. So people have to make calls of, if I bump into a piece of work, is a must have or is it a nice to have? When do I ask myself that question? And then now that I’ve identified it as a nice to have, or a must have, how do I capture that and where does that go? And a lot of this has to do with, the way that we work in Shape Up, is all about giving people actually more power and room to make decisions themselves.

(00:44:59) So a huge piece of this is actually that you give people more room to decide for themselves but with harder walls. So, the thing has to ship at the end of the six weeks and we’re doing this and not that. And I’m not asking you to do discovery, I’m asking you to do the hard work of figuring out what the right execution is, and I’m valuing as the leader, how hard that work is to come up with the right execution.

(00:45:24) When you make really firmer walls and softer space in the middle, actually a lot of this is about leaving them alone instead of trying to train them in something. And then, because they’re going to have those walls where they have to actually solve it before they hit the end of those six weeks, it’s going to create struggling moments where people are going to be able to say, hey, how do I handle this, how do I handle that? I’m not quite sure where I need to be. And then something like the Hill chart, for example, gives you an opportunity as the person who’s training or mentoring or leading, to sort of see where the teachable moment is.

(00:45:59) If something isn’t moving over the hill, if the to-dos aren’t getting completed, if something, if there’s a lack of motion in that six-week cycle, then you can come in and have a quick little workshop moment and say, where does the work stand? Anything you’re struggling with and then help to make the right judgment calls to unlock that, to unblock that, and then step out again.

Jason: (00:46:18) Cool, next one. [inaudible]. “How and when do you talk to customers correctly and how does that fit into the shaping of strategy?” So this is definitely Ryan’s area of expertise, here, so why don’t you take this one.

Ryan: (00:46:28) Yeah, we talk to customers as much as we can, but it’s hard to do that every day all day because you have to do other work, too, right? So for me, I’m trying to fairly regularly do interview projects and then the interviews that I do inform our model, or sort of our story about what people are trying to do out there in the market, and what else they’re considering and what works and what doesn’t for the situations they’re in.

(00:46:56) So we develop a sort of picture of what’s going on out there and what works and what doesn’t by talking to customers regularly. That picture that we develop of the truth of what’s going on out there for people in the market and who use our product. That becomes a kind of selection criteria or a filter for new ideas. So, we don’t know what idea’s going to come tomorrow, for what project to do. Jason might come tomorrow and be like, check this out, I’ve got this amazing idea for Hey, or for Basecamp, or whatever. And now we can use our understanding of what’s going on out there in “nature”, in the world of the customer and say, okay, this idea that just came up, is that compatible with what we know about what’s going on with customers through our years of experience and from talking to them regularly? Or not?

(00:47:49) And I think that’s a way to think about it. There doesn’t have to be a perfect one to one mapping between this thing we want to do and then we have to research exactly that with customers and everything. But if we have a broader idea of what’s in and what’s out and what matters and what doesn’t matter to customers, then we can use that as a very general fitness test against anything new that comes up. We do have cases where we’ll dig in on the more micro level and I’ll just give a short example.

(00:48:15) Support keeps hearing about people asking for recurring tasks, let’s say, in Basecamp, and we have this sort of feeling, yeah, that would be a good thing to do. So we start to talk about it but then we start to get into a conversation where it’s hard for us to agree about what’s important and what is a good solution, and what is a bad solution.

(00:48:35) In a situation like that, we can actually step back and do some customer research to get a clear sense of what circumstances people are in when they ask for that particular thing. So we actually did a series of interviews with people who were asking for recurrent tasks about what they were trying to do when they asked. And by doing that, we started to discover, ah, all the people who are asking are more in this situation and less in that situation. Because we were just imagining something. Now we have a little bit more clarity about what they’re actually trying to do, and it actually allows us to make more trade-offs in the future and say, it doesn’t need to do this and this, it’s more about just doing this and this. And now we’re coming to a point where we can actually bet on something with more confidence because we did that background.

(00:49:20) But we don’t do that as a procedural thing. It’s not like any time we want to build something we have to go do customer research. No, no, no, no, no. Customer research is a flashlight when we feel like we’re in the dark. If we feel like we’re in too risky territory or we don’t know how it’s going to go, we can go use the flashlight and look around and learn some things. But if we feel confident, or we just want to build something because we want to build it, we just go ahead and do it.

Jason: (00:49:43) This gets back to the point, also, about we’re not seeking certainty.

Ryan: (00:49:48) Yes.

Jason: (00:49:48) And sometimes you feel like well, if we just talk to enough people, certainty will come for free. But that’s just not how it works, and a lot of companies spend a lot of extra effort seeking out certainty that they’ll never find and it’s always, well, if we talk to one more, and we talk to one more, and what ends up happening is, actually every additional opinion you get makes you second guess things even more. You don’t get to certainty by asking more and more and more people, actually. What you get is more and more and more opinions, more different perspectives, which is valuable to some degree, but it’s not how you find out if it’s time to do something or not, in my opinion at least.

(00:50:25) Anyway, we can talk about that one for another hour, so let’s jump into this one, here. This is another one sort of for Ryan but I want to take it first, here. Mike asks, “I really like the breadboarding technique.” Breadboarding is a technique that Ryan pulled from electronics, actually, the way people put circuit boards together. He can talk a bit about that. “However, some stake-holders ignore it completely, they want to see a prototype and then they comment on it. Same goes to fat marker sketches.”

(00:50:52) So, I understand this, I can’t decide on a rough thing, I just want to see the real thing to decide. I understand that impulse, but what you can ask them back, somehow, is would you like to see 20 ideas this year or would you like to see two. Because if you want us to do a full, massive, high-res, high fidelity prototype of this idea in order for you to okay it or not okay it, we’re going to spend a lot of time on that. You’re only going to see a couple things, maybe, this year. Think about all the progress we’re not going to make on other things. And what if we don’t do either of them? That’s a whole year’s worth of work, or a whole bunch of work and a bunch of people doing a lot of work that could be done for a lot less.

(00:51:34) I can sketch out dozens of ideas in a month or many many dozens of ideas over a year and we can talk about them and discuss them and I think, my gut is, is that most leaders would say, I want to see more. I want to see more ideas. I don’t want us to waste time with things we’re not going to be actually doing. I want to see some stuff. Because there might be other ways, and maybe Ryan will hit this from another angle, but from that perspective, I think it’s an easier sell to say, well, we can put all this time into something that might not happen, and also what is a prototype? How in depth is a prototype, and does the whole thing need to work? Does this little thing need to work? What are we actually evaluating here? Are we evaluating the entire concept or a part of it? Is there enough here just to give a sense of what we need to do?

(00:52:20) Oftentimes you’ve got to figure out why they want to see what they want to see? What are they trying to understand? And if it’s just a concept, you can probably present it in a much simpler, low-fi way, and then you can probably sell the speed pitch on that versus, well, this is going to take a long time to do, are you sure we want to spend all this time so we can’t do all these other things at the same time? That’s kind of how I would think about it, but I’m curious to see what Ryan has to say about it.

Ryan: (00:52:44) Yes, so there’s a very big difference between pitching a concept to someone to get resources and shaping a concept so that other people can build it and reach the best outcome. So if the person that you need to get the resources from won’t be able to give you—you won’t be able to sell it to them unless they see something more concrete, then I think it’s totally fine to make some BS high-fi mock-up that doesn’t even necessarily reflect the best design but is going to make the sell. As long as you don’t have a dotted line you’re signing off on that says the finished product will look like this, you know what I mean?

(00:53:29) But if you say, look, this is the best thing I can show you as a very early concept to indicate the kind of thing we’re trying to do, and I think it’d resonate better with them because it’s more concrete. That can be a more effective way to sell them. I would see no problem with that.

(00:53:44) The thing is, then, you don’t want to give a high-fidelity mock-up to a team because then they’re just going to build it, and I think if you’ve looked into breadboarding, you understand all the faults with that approach. So I think you could actually do a hi-fi mock-up and a pitch to a stake holder to get the bet made if you need to make that pitch. But then, actually go back into abstraction and turn that into a breadboard for actually giving it to the team. And say, look, team. I know that you’re going to come up with a better way of doing this and I want to give you the latitude to do that.

(00:54:16) And then in the end, you get a better concept than what was pitched to the stakeholder, but of course, it’s doing the same fundamental things, it’s trying to fulfill the same goal. So I would untangle those two, because a pitch is doing both. It’s specifying work to be executed, but it’s also trying to make the case for a bet and you may need different approaches to succeed in those different domains.

Jason: (00:54:41) Ryan’s answer was better than mine so listen to him. Let’s take at least one or two more and see where we’re at at that point. This is kind of a follow-up. Ryan, you want to talk about this one? Is there utility in using software and worrying about how you [crosstalk].

Ryan: (00:54:55) Yeah, short answer, I tried using software and I ended up going back to hand-drawing. I think hand-drawing is the best way to go for breadboarding. It’s the fastest and it also communicates the roughness of the process so I haven’t seen anything better than that. I think it’s possible to make a tool for breadboarding, but it doesn’t exist yet. It needs to be fast, it needs to be really, really fast for it to compete with hand drawing and all these diagramming tools require too much fiddling around.

Jason: (00:55:21) “When approaching a feature like two-factor authentication or encryption, how do you balance what you know is the best / more secure way versus what’s most convenient for users?”

(00:55:31) This is a really interesting one. We’ve talked about this a bit, but I don’t think they have to be either-or. Because if you’re talking about something like security, and if it’s really hard to use or hard to do, people won’t do it so it’s not secure. So if your goal is security, you want to make something that’s very convenient and very easy to do. Otherwise, you’re not going to get buy-in, you’re not going to get adoption unless you force it on people, and there’s going to be all sorts of problems, probably, with that.

(00:55:55) So I actually think that convenience is a feature of security and is one of the reasons why the best, most secure things typically are really easy to do. Like, you think about fingerprint technology or iris scans or facial recognition and stuff. That’s easy for anyone to do. Behind the scenes it’s incredibly complicated to build but you get more people to buy into it because it’s easy for them. That’s kind of the best way to approach this, I think.

(00:56:25) Let me give you some concrete examples. Two-factor authentication. We’re going to require everyone who pays for Hey, every customer of Hey to turn on two-factor authentication. It’s not going to be an option. Therefore, we had to make sure that it was not something that we can push back into the settings screen somewhere because it’s a technical thing that only technical people know how to use, but that everyone’s going to have to use this. And if everyone’s going to have to use it, it has to be very convenient and very clear and very straightforward.

(00:56:52) And so I think we built a really, really nice flow around that. We spent a lot of time making sure that it made sense, and it was a very straightforward flow where you get choices. So when you look at our flow in Hey, the first question is, have you ever done this before? Do you even know what two-factor authentication is? Because if the answer is yes, you don’t need to be told a whole lot else to do. It’s like, here’s the QR code, scan it with your thing. Good.

(00:57:13) If you go, I have no f— idea what two-factor authentication is, there’s a different step-by-step hand-holding process that explains what this is and why it’s good for you and why you need it and how to do it and how to set it up. There’s two very different outcomes, or I should say, two very different paths for the same outcome. And so that was a conversation we had internally about how do we make sure that, because if I want my mom to use Hey for email. She doesn’t know what two-factor is. I know what two-factor is, we can’t just have a thing like, turn on two-factor and then throw a QR code, because even a QR code is intimidating to some people. So you really have to think these things through, I think, if you want to get adoption and to make something particularly secure.

(00:57:49) As far as encryption goes, there’s, obviously some speed downsides and some things you can’t do if data is totally encrypted at rest. Searching can be difficult. There’s some trade-offs there as well, and you have to figure that stuff out and figure out again, this is all about trade-offs. It’s not about, you can’t always have everything you want the way you want it. It’s like, what are you going to trade off for this, for that? And so we have had discussions about that and there’s always ongoing discussions about that as well.

(00:58:14) I think when you see security being adopted, it’s because it’s convenient. I just don’t think you can make inconvenient security work for people.

Ryan: (00:58:20) I think this is a really juicy nugget, this question, because it touches on something that we broadly have to deal with in product strategy all the time, which is the fact that people often frame things as being absolutely good or bad. Security is always good or encryption is always good, when it always boils back to the situation you’re in and what you’re trying to solve and that’s where the trade-offs come from.

(00:58:46) Security people are a lot like lawyer. Every time you go to a lawyer with something you think you want to do, they will tell you why not to do it. Or they’ll tell you all the ten pages of fine print you have to add before you do it, right? Because their job is to just only think about problems. So if we only did what security people said, then everything would constantly be absolutely secure and we would have retina checks on all of our houses instead of keys in our locks.

(00:59:09) But if we look at the circumstance, we can start to make judgment calls. So for example, there’s a cost side and there’s a value side. Here’s a value side explanation. Let’s say you’re selling a tool which is a keep your secrets. And this is a journal for only writing your most dangerous secrets and that’s the product you’re selling. If you sell that tool and you put extra padlocks and three levels of 2FA on it, and a retina scan, people are going to perceive that as actually more valuable, not an inconvenience, right? Because, it’s the same thing like people who buy a safe for their house, right? To put the valuables in. It’s not an inconvenience, it’s why they’re buying it.

(00:59:47) Then the other side is the cost side where the customers don’t care, but if there’s a blow-up and a bunch of customer data leaks, we’ll never recover from that or they’ll never recover from that. Then that’s a question of looking at how valuable the information is. And not all information is equally dangerous and equally valuable. If you look at a Zoom call, we’ve been experiencing this tension. Zoom calls by default have a short hash string at the end of the URL, and that was enough. And then all of a sudden Zoom decided that they needed to enable passwords by default, but we’re not doing 2FA to sign into a Zoom call. It’s really important to look at the context of what people are trying to do, what the data is, and whether they value security or whether it’s to prevent a blow-up.

Jason: (01:00:30) I think that’s a really great answer, too. It does touch on everything being a trade-off, which we’ve talked about. We’ve mentioned this word a few times, but it really comes down. That language, the language of trade-off is what we probably use most frequently at Basecamp when deciding to do anything. It’s not like, is this the right thing to, the wrong thing to do? Should we do it, should we not do it? It’s like, what are the trade-offs? Is it worth doing it because these are the costs, too? You’re always trying to think about what the costs are as well, and not just the outcomes. Otherwise, yeah, you always want the best of everything, but that’s just not realistic. And I think that’s what happens sometimes. Especially in product companies where they feel like everything needs to be incredibly high fidelity. There’s a bunch of dark, dingy corners in Basecamp that I don’t think, objectively, if you put the in front of me, I’d be like, that’s amazing. I’d be like, that’s kind of shitty.

(01:01:22) But we’re like, that’s okay. We’re okay with that there because it means we can spend more time somewhere else. So this is kind of to Ryan’s point, too, which I thought was great, which is if you’re selling a really secure product, these inconveniences are actually convenient. They’re like, I trust this thing. This is what I wanted. I wanted to open my door and have to do like seven different locks. Ch-ch-ch-ch-ch-ch-ch, because that’s what I want. But in the case of Basecamp, they’re like… Basecamp has well over a hundred individual screens, there’s going to be cruft in some places, just like in your house there’s some corners that just aren’t dusted all the time. It’s fine. It’s okay.

(01:01:55) you make the judgment call here and there. Maybe you want your kitchen to be spotless because you care about that and you’re there all the time. Maybe you want your bedroom to be spotless, but that guest room? Maybe you clean that once a month instead of every other day. Or whatever you do. You make judgment calls all the time and you make trade-offs with your time and your attention. I think that’s kind of the fundamental part here that threads through everything that we do.

Ryan: (01:02:15) Convenience is not an objective measure. Every time you go into some design meeting or engineering meeting at most companies, you’re going to find everybody saying, no but it has to be convenient, it has to be easy, it has to be fast. It doesn’t. Look at Emacs or Vim, these text editors. These things are impossible to use. They’re totally inconvenient to learn. They’re like, a nightmare to… there’s not even any commands visible, right? But people go through… or learn to play the cello. Is a cello convenient? It’s like [inaudible] you can’t even find the right note because there’s no frets on the neck.

(01:02:50) So convenience is not an inherent good. We need to trace it back to the context and the outcome of why the person is using this thing and then that’s actually where the fitness measure comes from, and then that’s where the trade-offs flow down.

Jason: (01:03:04) Cool, let’s take one more. Tucker, number one, that’s a nice cheat. Like, one question? Here’s two. But that wasn’t your fault, Tucker. “How do you decide to work on Hey?” Or, “How did you decide to work on Hey? What’s the bet? And two, how did you structure the team separate from Basecamp?”

(01:03:18) Good, so we actually started working on Hey not as an email tool. We were actually initially working on Hey as a brand-new version of Highrise, which is a CRM tool that we built and launched in 2007. It’s been upgraded many times since then. We were looking at redoing Highrise, like we did with Basecamp. We had Basecamp Classic, then we did Basecamp 2, then we did Basecamp 3. Highrise is essentially Highrise 1, Highrise Classic. It’s been adjusted many times over the years but it’s fundamentally the same thing. We’re like, let’s do something new here. We have some new ideas.

(01:03:48) So as we began to explore those ideas what we realized was that we were actually building an email thing. We didn’t know it was going to be an email service yet, we didn’t really know what it was going to be quite yet. But it became clearer and clearer that that’s where it was headed. And so, Jonas and I were working on this thing early on and then I brought it to David, and I said, hey David, here’s this idea. Because I know we talked about working on Highrise, and we were like, here’s what actually came out.

(01:04:15) And as we got into it, we started getting more excited about this idea that email is something that, it’s the only other way we communicate as a company, primarily. We communicate with the outside world that way. Internally, we communicate 100% basically in Basecamp. But with the outside world, accountants and vendors and new business opportunities and marketing people and all sorts of things we communicate outside via email, and we just had some new ideas that were brewing through this exploration of Highrise, and then we kind of started to think about, this actually should be an email thing, full blown. And then we started thinking about it differently because we opened our mind to new opportunities here.

(01:04:52) This wasn’t CRM. CRM was actually holding us back. It was like, this is actually email. What can we do with email? What are the struggles we have with email? Man, we struggle with email all the time. Email is one of those things that’s been with us for so long that you don’t even remember the struggles. But the fact that you have to star an email to remember to reply to someone later is a completely broken set-up. That star can mean 15 different things but that’s the only hack that you have. Or you mark it unread. So you don’t want to forget it, you mark it unread. We just put up with these things and we shouldn’t have to.

(01:05:22) So we started to come at it from that perspective and then got really, particularly got really excited about it. And excitement continued to drive the momentum on the product and then we started having it do other things. Initially it was just going to be a business tool for email, but then we decided that it should be a personal thing as well, so it kind of went a bunch of different directions. But it didn’t start out this way. It started out as a new CRM product originally.

(01:05:43) The bet is, that we want to provide an alternative to basically the only email system that really exists for the mainstream, which is Gmail for the most part. There’s also iCloud, and there’s Yahoo, and there’s some other things, but basically everyone you know has a Gmail address and we think that there should be an alternative to that. We have a different take on this. So, the bet is that we’re going to find enough people who, when we show them the things they’re struggling with that they may not even recognize that they’re struggling with with email are going to want what we want to put out there. And we think it’s going to be worth our time and we’re excited about it.

(01:06:14) There’s no… it’s not like this is going to be bigger than Basecamp, we don’t even have a number on it. This needs to do X million a year to be successful, that’s not where we’re at with this kind of thing right now. That’s not what we think about when we build new products. Are we excited about this? Do we think we have something here? Do we feel like we’re onto something? And is this a big enough addressable market that it’s worth putting time into, and email is, of course, a very very large market. [crosstalk]

Ryan: (01:06:37) Jason, how did it work out in terms of, you didn’t come up with the idea and then bet 18 months, you know what I mean?

Jason: (01:06:44) Right. Sure

Ryan: (01:06:44) Where did that tipping point, and what’s that transition?

Jason: (01:06:48) Yeah, it was pretty loose. So when we first started, again, we were dabbling with some stuff for Highrise and as we kept building it, we kept looking at email conversations and were like, this is just email. And then, this is probably a few months of just back and forth, Jonas and I messing with some stuff.

Ryan: (01:07:03) So you kind of carved out Jonas’s time for a couple cycles. Like, one cycle after the other, because you felt like it was promising enough to sort of explore this thing, to see where it goes?

Jason: (01:07:18) Well, I mean, it goes back even further, right? Highrise is a tool that we started in 2007, we then kind of spun it off, had another team running it for a few years. We then took it back and then we had it in our hands. And what are we going to do with this? Well, let’s thinking about making it… what could we do if we made it better? What would it look like? What would a really clean, new Highrise look like? And so, let’s take a few months to think that through. Not the whole company, but two people, basically.

(01:07:44) So yeah, it was a couple months, so a couple cycles, basically, ish. And then it got to a point where I showed it to David, David got kind of excited about it and we started messing around with it some more. Probably another month or so messing around until we decided to actually begin to build it for real. So all, before that the prototype was pure HTML mock-ups so we could click through it and play with it and imagine using it. That kind of thing. Then we started dedicating some basic resources to it. Not full cycles yet, but David got involved and started building some of the back end and started building some stuff so it could kind of start to work.

(01:08:17) And then probably a few months into that, we finally said, we’re going to do this. We’ve made a call to do this and that’s when the official cycles began.

Ryan: (01:08:25) There’s a really interesting escalation here of you can carve out some time for Jonas, and between the two of you, there’s no programmer there. And there’s this sense of like, it has to be compelling enough for David to be willing to carve out his time.

Jason: (01:08:38) yes.

Ryan: (01:08:38) To do programming, especially at the architectural level. So, it’s almost like, you work with Jonas for a couple cycles. You get to a point where like, I think we got something. You kind of bring it to David. David’s like, ah, yeah, I see it. I can see what you think you’ve got here. There’s an idea here. He’s willing to put his time in, so now you’ve got like, you’re getting some programming wired up, there’s some basic stuff happening, and then there’s another transition after that to are we actually going to put teams on this?

Jason: (01:09:07) Yeah, look, everything’s a sales job, ultimately. It’s like, look, I own the place and I still had to sell David on it, right? Because you have to get people to come along with you, and you have to show them something that’s interesting and compelling. And to the earlier question about sketches versus prototyping. In this case, sketches wouldn’t have shown the concept well enough probably primarily because this changed in concept. It was originally going to be a separate product. So for me at that point, the pitch was not should we do this thing we agreed to do, it’s oh, I’ve uncovered something else under this rock that I didn’t know was there, and it helped at that point to make the sale.

(01:09:45) By the way, this is actually an important point. David did not ask us to make high fidelity prototypes. He didn’t say, I won’t look at this until I can click through it. It was what I felt like we needed to do to get there. And I needed to do it for myself. So, it wasn’t a requirement from someone else, it was like, this is part of the sale. This needs to happen, and I felt like we could sell it better if we did that.

(01:10:11) But anyway, to your second question. “How do you structure the team separate from Basecamp?”

(01:10:14) So what we did and what we’ve always done is whenever we do a brand new product, so this is true from Basecamp to Backpack to Campfire, to Highrise, to a number of other things that were at this scale. We eventually go all-in on the new product, which means we put the other thing aside for a while. We don’t take everyone off Basecamp and move everyone to Hey on day one. But it was a gradual transition. And as Hey began to build up and build up and be more of a real thing that everyone could see, as the baby was growing up, essentially, we pulled more and more teams off of Basecamp work, and now everyone in the company’s essentially focused on Hey to get this out the door. And then we’re going to shift right back to Basecamp to do a bunch of work on Basecamp that’s been waiting.

(01:10:55) So, yes, in some ways you can say Basecamp has been put on hold for a little bit, but we’re a 50-person company. That’s the reality. That’s the trade-off. Getting back to trade-offs again. If we want to launch a new product and address this surface area we want, we need a number of people working on it. We don’t have spare teams sitting around that are just prototyping stuff all the time. We need to actually take our best product teams, which is the only product teams we have, and move them onto the new thing.

(01:11:24) So the trade-off is, Basecamp doesn’t get some love for a while. But we felt, four years in, the product’s very mature, it can withstand that. It can handle that, and we’re just about, in fact, in about 10 days, about to jump back to Basecamp, and do some really wonderful work on Basecamp again. So yeah—

Ryan: (01:11:37) And this was relief for me because while Jason and David were totally focused on Hey, it actually allowed me to go deeper and do more sort of research and strategy work for BC4. So that created a beautiful window for that type of work.

Jason: (01:11:54) So yeah, we’re actually calling this internally, like tick-tock development. All in on one thing, move over to something else, give that other thing a rest a little bit. Get some new ideas from the other thing bring it back to the other thing and kind of go back and forth a little bit. We’ll probably split teams for a while, though, once Hey launches. Because whenever you launch a brand-new product, the first few months are just like, ideas more than you can handle and things that are busted that you didn’t think about. All that stuff happens. So we’re not going to leave Hey. We’re going to stay on Hey. But we also need to work on Basecamp, so we’re working on Basecamp 4, and also some improvements to Basecamp 3 which will launch in about two months or whenever the next cycle’s over. End of May or early June. Whenever that will be. And then we’re probably going to have parallel teams working on both products at once given our current ambitions to launch a new version of Basecamp next year.

(01:12:42) Also, we have Hey Personal coming out and then Hey Business will come out a little bit after that. So we’re going to then split the teams again. So it’s a matter of directing all the resources to one bucket, to another bucket and then sharing resources across two buckets at some point. It just kind of matters when does the time feel right, what’s necessary when. When you’re building something new, you kind of need everyone on it. When it’s actually reached a critical mass of being real, but you don’t want too many people on it too early, because you don’t even have enough work for everybody yet, because you don’t really know what it’s going to be. So it’s like, you feather in and you layer in, and there’s a gradient of work in and out, and teams move around. That’s kind of how we think about it.

Ryan: (01:13:19) This is so easy to just gloss over, what Jason just said, and it’s so important. This notion that there’s a critical point where it becomes real and that that’s not day zero or day one. So there wasn’t one bet. There were a series of bets coming from a couple cycles of Jason and Jonas exploring, to a couple cycles of now David’s involved, and the whole phase of those one-by-one bets, individual bets of let’s keep looking, let’s keep digging were all what we call the R&D mode. And that’s where Jason and David are directly involved in the ongoing process of is this the right design and how do we tweak it, and really being hands on.

(01:14:01) Then there comes a point where we know we’ve got something. We’ve got the architecture, the bones are there. We know what this is. Now we can delegate work. That’s when you can scale up. You can’t scale up until you know what you want, right? So once they were clear on what they wanted, now they started to actually have cycles of work where teams were building stuff where Jason and David weren’t the ones who were doing the building and the design anymore, and that’s the production mode.

(01:14:28) And that can start where, in the beginning, maybe there’s one or two teams that are doing that, another team is still working on Basecamp. And then there comes a point where like, if we’re actually going to get this product done, we’re going to have to all hands in. Everybody’s going to have to work in parallel in order for us to do all the work that it needs to do, for this thing to launch. And that’s when we’re in the full production mode.

(01:14:48) So there’s these different phases. And getting into a phase is a new kind of bet. And the only point where it really starts to feel like a big bet is, I would say there’s a moment when I hear Jason and David will say, we’ve set a release date. And then there’s this notion of, somehow we’re going—we don’t know what the cycles are going to be but there’s maybe four or five more cycles between now and that date and they’re going to be production mode cycles and teams are going to be building stuff. And that’s where that feeling of that big bet comes is you know what, the next number of cycles are going to be for this product and not for something else, and we are going to drive toward a ship date and this thing is going to ship. But before that, it’s very piecemeal.

Jason: (01:15:28) And there’s a number of bets made along the way. You kind of parlay your bets basically, because one of the other bets we had to make is, we’re betting that it’s okay to leave Basecamp as-is for six to eight months. Like, that Basecamp is far enough along as a product, has enough of an established market. It still continues to grow in the way we want it to grow, and there’s still excitement about it and all these things. It can hold on for a while as-is.

(01:15:56) And we get that confidence by looking at previous versions of Basecamp. Basecamp Classic, which came out 16 years ago still has thousands of people who use it every day and it hasn’t been updated since 2012, eight years ago. So if Classic can last eight years without an update, based on an idea we had 16 years ago, surely Basecamp 3 can handle six to eight months of our best, current thinking, on its own. And we’ll get back to it pretty soon, in a week, or 10 days.

(01:16:32) So that’s the other bet you make and you have to calculate, and you go, there’s going to be a trade-off here. Again, we could lose people because people say Basecamp hasn’t been updated for a few months or where are the updates. Totally fair. And by the way, fair complaints, all that. It’s just like, that’s the trade-off. That’s the bet we’re making, that it’s going to be okay. That we’ll weather that storm.

(01:16:49) And the other argument is that Basecamp 3, as-is today, is brand new for anyone who’s signing up today, and last week I can look at the numbers. Last week, 5400 new companies signed up for Basecamp. For us, and for existing customers, it hasn’t changed for a little bit. But for them, it’s brand new. And so we think that that’s okay too.

(01:17:08) So, you know, it’s just a matter of feathering in moments and even one more example. This feathering thing, which I think’s important, because these… I feel like, and Ryan, I think you got to it, theory and practice are different here. In theory, it’s like, the company decides to do something and gets all in on this and the company stops doing this, and you move onto a new phase and these things are like, so blocked. They’re blocks, but they’re really fluid. They’re fluids.

(01:17:34) And it’s because, like, for example, we’re inviting people to Hey right now, beta testers, okay. Someone has to do customer service for beta testers, right? Who’s going to do that? Well, I’m going to do it. I’m going to do it for a while because I’m working the product. I want to know exactly what people are struggling with. I want to know what exactly isn’t working, I want to know every single typo, whatever. But I don’t want to do that forever because I have other things I need to do, too.

(01:17:57) So I’m feathering in myself to do support for a while, then we’ll begin to feather in some people in the support team and train them up on the product. We’ll make these very fluid transitions between one phase and another. It’s not this rigid, this end point and this starts. It’s really not that way. Except for the six-week cycle thing is, but as far as moving resources around, and whatnot, it’s typically very gradual. And I think that helps to reduce the risk and also to provide you with some feedback. If you push a little bit too hard, you don’t upset the cart quite as much. You can feel the push coming in and we need to slow down right now. Or there’s too many people involved here, or whatever it might be.

Ryan: (01:18:32) Also, from a strategy side. Jason and David were leading the push on Hey. I was kind of in a role where Jason might pull me in once in a while if there was sort of a, if they were at a weird fork in the road or something was a little bit murky, and maybe I might contribute some perspective but it was more like their thing that they were leading. And then I actually kind of responsible to play some, both offense and defense on Basecamp strategy while they were busy on Hey. So, on the one hand I really wanted to be able to push forward Basecamp, so when it came time to come back to Basecamp, I wanted to have some very, very new, exciting ideas for where to take it.

(01:19:09) But at the same time, it’s a little bit nerve-wracking to leave a product alone for that amount of time so I felt kind of responsible to play some defense, too. There’s a million ideas of cool stuff that we want to do, but there’s one or two things that we kind of know that we have to do because of our idea about where things are going competitively over the next, maybe year and a half, three years, something like that. It’s not so fixed. But it’s important to keep an eye on those things and to stay in touch with the market in order to have a sense of what are the odds. It’s more of a feeling the weather than it is a number. But you need to have a sense of is winter coming or is spring coming in some aspect of the market. And you want to be in a position to make your bets on some basis of being informed.

Jason: (01:19:57) Cool. This was good. This is about 90 minutes, so it’s probably more than most people can handle. However, I know that there’s actually, because I was looking on Twitter, dozens of additional questions so I think we’ll probably do a second edition and maybe a third edition of Ryan and I doing this, if people want that.

(01:20:13) So thanks for tuning in and for all the questions and thanks, Ryan, for just [inaudible] and always giving the answers I wish I gave. And thanks to Andy for, Andy behind the scenes, for producing this and pulling the questions and lining everything up.

(01:20:30) Hey, thanks again, and we’ll see you next time.

Ryan: (01:20:32) Thanks everybody.

(01:20:33) Broken By Design by Clip Art plays.

Shaun: (01:20:41) REWORK is produced by Wailin Wong and me, Shaun Hildner. Music for the show is by Clip Art.

Wailin: (01:20:46) We’re still periodically doing these live Going Remote Q&As. Head over to Basecamp.com/remote-resources to check out past streams, and follow us on Twitter at @reworkpodcast where we’ll announce upcoming streams.

Shaun: (01:20:59) We’re also still collecting your tips and tricks for working from home. You can leave us a voicemail at (708) 628-7850. Or, record a voice memo on your phone and email it to hello@rework.fm.

(01:21:15) REWORK is brought to you by Basecamp. Basecamp is the all-in-one toolkit for working remotely. You’re wondering how you’ll quickly transition your team to remote work. People are stressed, work feels scattered, projects are slipping and it’s tough to see and manage everything. With Basecamp, everything will be organized in one place, your team will be working together even though they’re physically apart, you’ll be on top of things and a sense of calm will set in.

(01:21:38) Check it out for yourself at Basecamp.com.

(01:21:42) Broken By Design by Clip Art plays.