Podcast: Play in new window | Download

Sean [00:00:18] Hi, welcome to the Product Momentum Podcast, a podcast about how to use technology to solve challenging technology problems for your organization.

Sean [00:00:28] Hey, Paul, have we got a treat for the audience today. I’m so excited.

Paul [00:00:32] I can’t wait, Sean. What are we going to hear about from Ryan Singer?

Sean [00:00:35] This is a guy who is doing it. Like he’s living it, he’s grown up in this industry. You know, similar to you and I, he’s got so much experience but he’s actually created his own process, his own framework, his own language around what works and what doesn’t work in Agile and I’m just excited. Such a great interview.

Paul [00:00:53] Talk about trace arounds, tent poles, butchering animals. It’s going to be an interesting conversation for sure.

Sean [00:01:01] It’s going to be awesome. Let’s get after it.

Paul [00:01:03] Let’s get after it.

Paul [00:01:07] Well, hello and welcome to the pod. Today, we are super excited to be joined by Ryan Singer. He has worked on all levels of the software stack from UI to back-end programming to strategy. Over 17 years at Basecamp, he’s designed features used by millions and invented processes that teams used to design, develop, and ship the right things. These days, he’s focused on product strategy, understanding what Basecamp’s customers are trying to do, and how to make the product fit them even better. Ryan, welcome to the pod.

Ryan [00:01:34] Hey, thanks for having me.

Paul [00:01:35] Thanks for being here. I’ve been looking forward to this conversation as a longtime user and fan of the business. I’m really curious to get in to, what’s on your mind lately, and what are you thinking about?

Ryan [00:01:47] Sounds good.

Paul [00:01:48] So let’s jump in and let’s take it right from the highest level. You’ve talked a lot about how Basecamp does business and how you think about product strategy. How do you think the industry is looking now compared to where you started 17 years ago? What are some things that product managers are doing, at Basecamp, but in the community at large?

Ryan [00:02:06] I mean, I think the biggest thing that’s changed over these years is that the community itself is way bigger than it ever was. I think it was only a few years ago that we started to really hear this term like product, product, product all over the place, right.

Sean [00:02:19] It’s true.

Ryan [00:02:20] When I first started off, I learned most of what I learned about how to think about and go about the software development process from programmers. If you think back to the origins of Agile and extreme programming and stuff like that, so much of the stuff that sort of we grew up on at Basecamp came out of software developers who were working separated from business people and separated from designers. You know, the whole notion of Agile was actually like, “We keep getting requirements thrown at us and the clients keep changing their minds so how do we change what we’re doing faster?” Right? I mean, it made perfect sense in its context. But then when you look at the context that we’re in today, the chief challenge isn’t, “how do I react faster when my client changes their mind?” I think the big challenge and the big opportunity is to have more leadership and say, “what does progress look like for us as a business or us as a product and where do we want to go and how do we actually get to where we want to be?”

Paul [00:03:23] Exactly. Yeah, I think that there’s a lot of maturity that’s happened. You’re spot on where web design as a practice started back in 2003 or so when you started and I think when I graduated with a graphic design degree with a lot of the same tools at our disposal. The things that we were thinking about then were, how do you get a feature on a screen so that a function can perform? But there’s a lot of fussiness in products that I think Basecamp has deliberately avoided. I don’t know if that’s how you’d put it, but when I look at a product that Basecamp puts out, it’s very unfussy. It’s almost utilitarian and I think that you’ve preserved a lot of that original DNA in ways that a lot of the rest of the Internet hasn’t. Would you say that’s fair?

Ryan [00:04:04] I think that this is a subject that’s bigger than us as an individual company or a product. It’s a question of, do you actually have a clear vision of what it is that the thing is supposed to do? If you really have a clear sense of the itch that you’re trying to scratch, you can cut away so many unnecessary fussy details because you have a macro view of these are the few levers that actually matter for solving the problem or for making an impact, versus if you don’t have a clear idea of what’s important and what you are trying to do that’s unique and the key points of the itch that you’re trying to scratch, you get lost in all kinds of little, you know, little impressive technical things or complicated UI touches and stuff like that. You get bogged down in that stuff when you don’t have a bigger picture. And so I think what product strategy is supposed to be about and what we’re supposed to do if we’re doing product strategy is to actually get to that macro picture of these are the very small number of very important things that differentiate us and actually serve the job that our customers are trying to do.

Sean [00:05:08] Yeah, well, and in addition to that, I would argue really focusing on the core customer that you want to solve those problems for. Because it’s not everyone.

Ryan [00:05:16] Absolutely.

Sean [00:05:17] It solves a very specific set of problems for a very specific set of people.

Ryan [00:05:20] Exactly.

Sean [00:05:21] And I would totally agree with you. I think it’s largely a function of the history of the industry. It’s a young industry, right. It’s starting to mature and the coolest thing about it is we’re in this space where new technology is getting inserted in front of us every day. So there’s always some new shiny, sexy object that we can, “hey we can incorporate this into our product,” right. So this concept of figuring out what to say no to is becoming, I think, more and more important as we differentiate our products.

Ryan [00:05:46] This is where, to come back to the first question about sort of what’s changed or what am I seeing in the industry, this raises questions about leadership in terms of how do we actually work as an organization. And what I’m seeing that I think is the biggest struggle for companies that I’m talking to is actually that they have a lack of leadership. What they’re doing is that they are pushing down way too many design and product decisions to the lowest level of the company.

Ryan [00:06:14] They have teams of designers and programmers and they’re just giving them work and then saying, “go do discovery and figure out what to do,” or, “let’s have a giant meeting together where we all figure out what goes into the next sprint.” And I don’t think that there’s enough confident direction coming from the top and down saying, like, “this is actually what’s important; this is what we’re going to pursue.” And then at the same time, there’s also this weird contradiction where there’s this flip side where on the one hand, there’s not enough leadership in terms of the macro vision of where we’re going to go next, and on the other hand, there’s way too much micromanagement. There’s so many teams out there who are pulling tickets. You know the work is getting slotted as a bunch of predetermined tasks and you pull tickets until you’re done.

Ryan [00:06:56] But, man, real work doesn’t work like that. In real work, you don’t have a ticket to tell you what to do. You get in there and you start pulling on the strings of the problem and you say, “okay, what do I need to actually make this thing work?” And you realize, like, “oh, crap, like that doesn’t connect to that,” or even worse, “this connects to all these other things that are out of scope to change,” right. And so you get all these surprises and this unexpected work that you couldn’t see from the beginning and you can’t capture that by giving people tickets, you know? So really, what Shape Up is about, and what we’ve been figuring out how to do for the last, yeah, I mean, the last 17 years, at least in my experience there, has been to figure out how to solve this contradiction. How do we give a much clearer direction to the teams about what’s next? And at the same time, how do we give them way more autonomy to work out the details?

Sean [00:07:47] Yeah. From reading Shape Up, great book by the way, you have this concept of imagined versus discovered task.

Ryan [00:07:53] Yes.

Sean [00:07:54] I love that part and I love that language. And the imagine part is your plan, which could come from the top down. But it’s imagined, because we don’t know really what the results can be until we put it in the wild, versus discovered, which is the reality, which really can only be determined when something goes into the wild and see what happens, right?

Ryan [00:08:12] Yeah. And there’s two kinds of wild. There’s the wild of the market and there’s the wild of our own code. So…

Sean [00:08:19] I love that.

Ryan [00:08:20] We have a variety of different types of opacity that we have to deal with here. We think we know what we want to build, but we don’t even know all the little weird intricacies of how the billing system works or what assumptions were made when the permission model was put into place. So we can have a pretty clear idea of what we think we want to build and there’s all kinds of unknowns just in terms of the internal interdependencies of what’s going to be possible and how long it’s going to take to get there. And that’s all before you even ship the thing to find out what’s the market reaction to that.

Paul [00:08:52] So you teed up a perfect segue into the level of leadership that product managers tend to focus on or not focus on and the paradox of lack of leadership versus micromanagement versus what Shape Up is all about, this concept of shaped, right. Having this executive oversight that provides a vision that can set a team off in a direction and I think that shaped is uncomfortable for a lot of models. I don’t know if you would call yourself Agile, but you’re certainly not scrum, right? Two weeks is not enough time to get meaningful work done based on the Shape Up model. But I think when you start to allow a certain amount of ambiguity, it can be uncomfortable in the current paradigm, I think across the industry. So how do you talk to somebody outside of a Basecamp to share what Shape Up can be? You’ve published it. It’s in the world now. What kind of responses have you seen about people who’ve adopted it or even rejected it?

Ryan [00:09:44] So the first thing is that I always start the conversation with struggle because there’s no reason to change unless you’re trying to fix something. And the two big struggles, there’s actually three big struggles, but the first two are, we just aren’t getting stuff done. Projects are dragging. It’s another sprint and another sprint and another sprint and why aren’t we getting stuff done? The other big struggle is, “I’m a product leader, I’m a product manager, or I’m a founder of a small startup and I feel like I’m just in way too many meetings and I’m doing way too much, like, this daily stand up and every two weeks this grooming session and I’m answering people’s questions and I’m trying to deal with, like, how to overlap people’s schedules. I’m just doing all this stuff that feels like it’s in the weeds all the time and I don’t have time to think. I don’t have time to do this strategic work that I know I should be doing about like where are we going next and what’s valuable and what’s important and what’s it going to look like? Like, I don’t have time for that. So how do I carve out that time?”.

Ryan [00:10:43] And then the third struggle that I’m seeing is actually folks who have very small startups that are starting to make money and they’re getting ready to hire people and they realize, like, “I don’t know what to tell these new hires about how we work and I don’t want to tell them that we open JIRA and file tickets like that’s not the future for this company but like, what’s the alternative,” you know? So that’s sort of the entry point. The big reaction that I’m seeing is twofold. One is, we’ve been, I think, caught in kind of this black and white world between either you’re Agile and you have no plan or you are waterfall and you’re bad, you know, and Shape Up describes a whole vast middle zone where there’s ways to do work at different levels of abstraction and set different expectations. And this just opens up a whole new conversation, just this notion that shaping is a phase of the work that happens at a different level of abstraction.

Ryan [00:11:41] So we’re seeing already just a lot of people just saying, “oh, this is shaping, like this describes something that I kind of felt like I was trying to do that I didn’t have a word for, and I didn’t know how to kind of even declare my time of like what I’m doing today is shaping. I’m not coding today. I’m not doing a pixel perfect design today. I’m doing shaping and this is a different kind of work.” People have been really happy about that. The other thing that’s, I think, the biggest win for a lot of teams is when you as a person who’s leading product stop micromanaging and trying to, you know, sort of whip everybody to make sure that they’re doing the right thing today and this afternoon and tomorrow morning and then tomorrow afternoon, but you give people very clear boundaries of, “these are the few moving parts that we believe are viable for this project. This is more or less how we expect the big moving parts to work and there’s going to be a million details and a million discovered tasks that we can’t anticipate and we’re just going to say, ‘hey, work together and arrange your own time, figure out when you want to overlap with each other, figure out when you need to have your head down and just work on your own and find your own solution to all these details.'”.

Ryan [00:12:59] So by actually giving people the freedom and the autonomy to self-organize around the details, that freedom and that autonomy, it comes from the constraints. We’re not saying “go do discovery.” We’re saying, “look, we’ve got a concept here; we have a thing that we’re pursuing. So in terms of the work, this is the shape of the work.” And then in terms of the time box, “here is enough time and a real deadline.” You know, “if this doesn’t ship within the six weeks that we said it was going to ship for, the project’s not going to happen.” So there’s this back pressure on the team that’s motivating them to not only make tradeoffs, it’s motivating them to collaborate in a new way, you know, to ask each other different questions and to sequence the work in ways that are more fitting to the unknowns that they have to solve. So what you get is this super energizing collaboration between programming and design that wasn’t possible before in a world of pulling tickets and working in sprints.

Paul [00:14:01] I love that. And I want to come back to the concept of circuit breakers in a minute but I do want to share anecdotally, one of my biggest clients has stumbled onto a shaping phase where we’ll take a day or two full days, not a full two-week cooldown, but two full days of shaping activities to plan a quarter’s worth of work and map out, you know, that butcher block of, the hipbone connects to the leg bone, dependency-level tasks. And it’s been game-changing in terms of the way it’s not waterfall, it’s not pure Agile, but it does make a profound difference in the anxiety level in the teams and the clarity of direction. And I think that it’s been game-changing. And I think that reading Shape Up just made everything click, like, “this is why this works.”

Sean [00:14:47] You’re not going to get investors to invest anything worthwhile in the complete unknown. like there’s got to be some deadlines. There’s got to be some way of looking at, “look, we’re going to produce something at some point.” I think Shape Up is a really cool set of language, really, that we can take back into the market and make better products with.

Ryan [00:15:05] That’s important because we actually need language that is more centered around risk and unknowns instead of being centered around certainty and plans. So we want to be able to say, like, “what bet do we want to make and what do we think is risky about this bet and what are our odds of getting what we want out of this time that we’re gonna bet,” you know? And that really kind of invites us to look at the shape and to look at the de-risking process and to look at the unknowns in a way that is much more critical than I think a lot of Agile teams are doing today.

Sean [00:15:35] Yeah, that’s a key concept there. We’re all managing a set of risks to try to deliver something into the market. And I think in the book, you phrase it as bets versus backlog, right?

Ryan [00:15:43] Yeah.

Sean [00:15:44] And I love that concept. But you don’t have this concept of a long term backlog either, right? A lot of stuff kind of gets thrown out.

Ryan [00:15:50] We’ve got a kind of portfolio of potential bets, which is very different than a backlog. You know, there’s a few things and they’re mostly kind of close to the vest or whatever you say, like among leadership, of the things that we think we’re going to want to pursue in upcoming cycles. But there’s no actual commitment to those things and any of them could change or get thrown out or whatever. The only real truth is the next cycle. One bet at a time.

Sean [00:16:15] Cool. Let’s talk about circuit breakers. You want to explain them to the audience and then I got a couple of questions about how you use them.

Ryan [00:16:21] Yeah. So a circuit breaker is a risk management strategy. This could be a whole nother book. I’ve been spending a lot of time on this lately and it’s just such a juicy subject. There’s different types of unknowns and different types of risks when we get into a development project and we talked a little bit about this notion of like, your own code is the wild, and this is actually really important. If I line up a project that says, like, “OK, we are going to add an improved flow for canceling a subscription,” or “we’re gonna do an improved flow for, let’s say, updating a credit card in such a way that it’s going to fix churn.” So let’s take that angle instead. You can have a lot of assumptions about, you know, we have this billing service that we use and we have this like third party service we rely on and they have an API. So we assume that we’re gonna be able to do this, that, and the other thing, and we took a quick look at the docs and we think it’s all fine and you go ahead and schedule the project, right. But then, of course, it turns out that there’s some details in the way that API is implemented and then before you know it, it’s like, “oh man, we can’t actually do what we thought and then we have to rip up all this other code over here,” right.

Sean [00:17:26] Sounds like 100% of projects, but keep going.

Ryan [00:17:29] Well, this situation that I’m describing that I think a lot of us relate to, this is a situation where the reason that all of a sudden the time it’s taking to build is increasing by 10x all of a sudden is because of the interdependencies that you couldn’t see. That’s very different than, “we’re gonna go and we’re going to change the text on the update your credit card button.” When I change the text on a button, I know that there are no interdependencies to anything else except maybe the width of the button so that it can fit with the other components that it lives in some container, right. And okay, you might a fuss a little bit with “what’s the right text and does the button still look good with that text,” and so on. But that’s an example of you have no interdependencies to other elements. And just by looking at those two differences, you can see how it’s a question of not just what is the estimate of how long it’s going to take, but what is the shape of the probability distribution of the error? How fat is the tail on the error of this thing? Is it gonna be ten times worse than we thought or is it maybe going to take twice as long as we thought? And is it twice as long on an hour? Or is it twice as long on a week, or what? Right.

Ryan [00:18:38] So a huge part of what we’re doing is when we do the shaping work, we’re not just saying, “Hey, this looks like a good idea, let’s give it to the team and have them figure it out.” We are actually going to spike and do a little bit of early rough prototyping to learn where the interdependencies are to tug on those strings and see how deep those unknowns go. And then what we want to do is we want to shape the project in such a way that to the very best of our ability, we have actually cut off those tails so that we get to a point where the error is going to look like a thin tailed distribution instead of a fat-tailed distribution. So we want to get to a point where it’s like, “we might be a little bit off, but it’s not going to blow up in a 10x kind of a way.” So we do our best effort in the shaping phase to reduce our risk. And then when we’ve gotten to a point where it’s like, “look, we’ve looked into this API, we know how this integrates to the model of our billing system like we know that this is doable and we’ve even spiked out the key moving parts,” now we can go bet on this with confidence. So we do as much as we can to sort of shrink down that risk.

Ryan [00:19:45] But the problem is that there’s no guarantees in this world, you know what I mean, and we’re always gonna miss something and there’s always going to be something that we can’t anticipate. And fundamentally, the thing is, we don’t want to spend time on something that wasn’t worth that amount of time. The mere fact that we embark on an effort doesn’t mean that we have to keep going until we succeed forever. You know what I mean, this is what we talk about with an appetite. So the thing is, if this project is worth, strategically, let’s say we say six weeks. If something goes wrong that we just simply couldn’t foresee or we got busy and we just got lazy and we didn’t look hard enough at it before we scheduled it or whatever happened, it doesn’t make sense to spend two times, three times, four times the scheduled time on this thing if it didn’t deserve that strategically from the beginning. There’s other stuff we could be doing, you know, and there was a context we were in when we made that bet to say, “this is the thing that’s worth doing today for this number of weeks.” So the circuit breaker is our protection, both against the unknowns of missing something in terms of the wild of the code or missing something in terms of maybe we misunderstood kind of who to schedule on it and then there was a misfit in terms of, like, technical knowledge and the problem that needed to get solved. Who knows what it was, right. A lot of things can happen where the project can blow up. And we do not want the blow-up to start to have these ripple effects where now we can’t work on other things that are valuable to us because this project is taking longer and longer.

Ryan [00:21:19] So if at the end of the time that we’ve bet, which for us is always a six-week cycle, we shaped the work to that time box. You know, it’s not an estimate. It’s a constraint on the design. So we get to that point, if the project doesn’t ship, then by default, it’s canceled. And if we still feel like we want to get this into the hands of customers but we didn’t succeed in building what we thought we were going to build in that amount of time, we’re not just going to throw more time and throw more people at it. We need to take that step back and say, “what is it that we didn’t understand? What is a new bet going to look like where we feel like we understand the remaining work that needs to be done and we’ve actually looked into the connections and the moving parts of that remaining work?” So that we’re not just crossing our fingers and hoping that a little more time is going to solve it and we’re not just padding our estimates to try and be more conservative, but we’re actually looking at the work. What are the actual interdependencies of the work? Where is that hip bone connected to the leg bone, so we understand what we’re getting into?

Paul [00:22:25] So I’ll be honest, the paragraph where you talk about canceling as the circuit breaker tripping, that hurt when I read that first time because we’ve all been on projects where it’s ship-at-all-costs and I think coming from a Scrum background, there’s a focus on, always be shipping, and I think there are even organizations who will wear the number of times they ship to production per day as a badge of honor. And what shaping does is turn that paradigm on its head and say, “we’re not going to ship unless it’s right, and we’re not going to invest, we’re not going to bet, unless we’ve done our due diligence.” One of the things that I had to wrestle with is because our industry tends to emphasize shipping versus shaping, right, as two types of activities that we do.

Sean [00:23:11] I like that, Paul, shipping versus shaping.

Paul [00:23:14] The thing that I took away from that circuit breaker after kind of sitting there stunned for a second is just we often develop a relationship with our products. We can’t cancel them. They’re our babies, you know, because we’ve invested this much time in, we don’t see the sunk cost and we just pour more and more resources in. But having almost that detached perspective of strategy, it’s empowering to look at this and say, instead of ship at all costs, it’s now take a step back, do our due diligence and say, “this part is still worth it; we’re going to focus and double down on this and focus down on that.” So that was a real eye-opener for me because it’s just so different than the way that the scrum two-week cycle of never-ending sprint planning tends to focus our activities. So I wanted to call that out as a moment of learning for me. I think it was really profound to find that nugget tucked away.

Ryan [00:24:05] This is really about separating output from outcome. The fact that you hit the deploy button doesn’t mean anything. It doesn’t mean anything to the business, it doesn’t mean anything to customers, it doesn’t mean anything on the second-order of the quality of what you’re going to have to maintain in the future. Like, those things require being intentional and being deliberate and saying, “what are we spending our time on and what’s a meaningful use of our time and what’s progress,” you know? So like we are also extremely, what do you say, like shipping-obsessed also.

Sean [00:24:37] Nothing adds value until it’s in production at the end of the day.

Ryan [00:24:40] Yeah. So we are extremely like eager to ship and we have that mentality. But we don’t ship things unless we think that they’re valuable and we think that they’re good and we want to live with them, you know, and that’s why we shape is so we can be intentional about what we’re doing. And I think also this hero mode, you know, it kicks in when the project has already dragged on because it’s already gone on for so long and it’s just getting worse and worse. And then on top of it, if you don’t have explicit lines drawn in your processes between shaping, betting, and building when a project starts to go wrong, how do you diagnose it? What is going wrong? You need to be able to separate out, is there a performance problem here where somebody is not solving problems that they should be able to solve in their role? Was there a shaping problem here? Did we not think through what we’re trying to do? Was there a de-risking problem? Did we not have a technical person look at what we were undertaking in enough detail before we made the bet? Was there a betting problem? Was it perfectly shaped and everybody’s doing a fine job building it, but it’s not a good use of our time? All of these things can be kind of orthogonalized from each other and we can use these to inspect what’s happening at a given moment and make a clear judgment of, like, what can we do differently right now to get on track and feel like we’re all making progress again?

Sean [00:26:03] Yeah. So as a business leader and an entrepreneur, it is scary. When I read it, I was like, “Woah,” same as Paul, but from maybe a slightly different perspective. And I agree with everything you’re saying. However, if you don’t ship and you cancel the project, how many bets can you put up with? Like there’s got to be a limit.

Ryan [00:26:22] Yeah, but this is where the causality turns out to be surprising because the threat of not shipping is what causes you to ship.

Sean [00:26:28] It’s a forcing function, right?

Ryan [00:26:30] It’s a forcing function. Absolutely. That’s really the reason it’s there.

Sean [00:26:34] Yeah.

Ryan [00:26:34] Of course, it caps our risk. But the thing is that it doesn’t just do that as a dead static thing. It introduces a dynamic.

Sean [00:26:41] Yeah.

Ryan [00:26:42] Everyone is constantly making tradeoffs in reaction to that possibility and what it means, in the end, is it happens very rarely.

Sean [00:26:48] That’s good because you wouldn’t have much of a business if it was the norm.

Ryan [00:26:52] But all of life is like this. This is really about actually decision making. None of us, you know, buy the new car or move the apartment or whatever until, like, the situation around us starts to unfold and we start to realize, like, “oh, man, has got to happen now,” you know what I mean?

Sean [00:27:08] You’re absolutely right. Interesting. It’s a forcing function, but what it does, I believe, and I’m testing an idea, is that it forces you to be much more purposeful about the learning as well, which is really what’s important. We want to be constantly learning and growing in both our skills and learning about our customers and what they need and want, right. So this six-week forcing function, similar to the sprint forcing function, but with this hard-core like, “look, we’re going to cancel this thing and all this work potentially could go to waste.” Six weeks is big enough that it’s kind of a scary amount of labor and resource and money, but you’ve got to really pay attention to what you’re putting out if you’re serious about canceling and throwing away that work. So it’s about the learning. That’s my proposition.

Ryan [00:27:55] Yeah. And it’s also about how do we create the right conditions for learning and how do we sort of develop an environment where people see that there’s learning that needs to happen. In the book, I talk about the Hill Chart, and the whole notion of that is you start the project and if it’s well-shaped, you at least have a clear sense of what to do in terms of the big moving parts. But you’ve got to do a whole bunch of learning because you don’t actually know how to wire it together and what’s going to work and what’s not. And the teams, if they have this backpressure rippling out at them from the end of the cycle saying, “look, we’ve got to actually make tradeoffs,” then they’re going to sequence their problem solving differently.

Ryan [00:28:37] This is another thing that is totally different from the ticket world. We’ve got a whole bunch of things that we have to figure out. It’s not just building, it’s solving, and solving means, “I don’t know what to do, I don’t know how it works, and I’ve got to figure it out. And if I spend my first two or three weeks, you know, making the perfect beautiful login screen,” or, you know what I mean, like noodling around with, like, a better email template… “There’s a piece about how to wire into the subscription billing service that I haven’t done before.” I’m going to learn that I need to move that billing API piece to the front of my sequence of what work am I going to choose to tackle first? And that’s a skill that you can’t just tell somebody, “here’s how to do it,” but if you put them in the environment where they have the right constraints and also the right support, the circuit breaker creates the constraint of “you got to solve it,” but the shaping creates the support of, “you’re not out floating in space with no handrails around you,” you know, enough of the problem has been figured out that we’re confident that this is more about just finding the right arrangement and working out the right details and they are not problems that require a major eureka or, you know, long walks in the woods or whatever to get there, right.

Sean [00:29:49] Archimedes in the bathtub.

Ryan [00:29:50] Yeah. Exactly. But what we want to do is we want to always kind of be in that mode of, “what are my unknowns, what are my knowns, how do I get over the unknowns earlier in the amount of time that I have and then sort of leave the things that are screw tightening and polishing and little improvements, how do I move those to the back?” So there’s a lot of time management and problem-solving sequencing that teams start to do that wasn’t even part of their world before because all of that was actually just getting outsourced to some ticket writer or project whip, you know. And so much of this is about taking kind of the management out of the product manager and moving that into the team by giving them the right constraints around them and then this frees up the product manager to focus more on, “what should we actually pursue and what are the things we need to shape and what are the things that we might want to consider betting on?”

Paul [00:30:43] So I love that as a frontline product manager who does a lot of ticket writing. It is refreshing to hear that the time has a name and that it’s valuable, and I think thinking about it differently can be a real meaningful improvement to how we view our day-to-day work. You made a comment about noodling about email templates just a minute ago, and I can’t resist asking, since the time that we chatted getting ready for this interview, and today as we record it, Basecamp has since launched Hey.com.

Ryan [00:31:12] Yeah.

Paul [00:31:12] And I know that it’s not your product specifically, but being around the folks involved with it, I’m curious how much of Shape Up was a part of what Hey.com became, and even bigger than that, if I may be so bold, email seems to be a pretty saturated market. So entering in and then following the process through seems to be a very bold position to take. I’m curious what the experience has taught you and how Hey.com’s launch has gone so far.

Ryan [00:31:39] Yeah. So Jason and David didn’t decide when they first started working on Hey that they were going to dedicate two years of the company’s time to build this thing. They were making very, very small bets in the beginning about the most interesting questions. And this points to the dynamic that we’re talking about, this learning dynamic. I don’t have to say, “we’re going to go build an e-mail client,” and then bet two years on it, you know. So the short answer is that all of Hey was built six weeks at a time. And what we’re observing now, having gone through a few rounds of this over the years, is that there’s kind of three different phases of betting and shaping that happen for a new product. Straight up, kind of like shaping as it’s described in most of the book, assumes that you have an existing codebase that you understand and that codebase is kind of fixed like concrete, you know. So if you’re going to build a new feature, you already have all of these things that you know are true about the basic architecture of the product and how the thing is organized and the main UI elements that you have to work around and blah, blah, blah. Because of that, you can come up with a concept, hone it down, shape it, look at the interdependencies, cut out the rabbit holes and the delegate it to somebody and say, “go figure out how this fits into what we already have,” and they can manage.

Ryan [00:32:58] When you’re doing a totally new product, you don’t even know what the main architecture is, right. There’s a lot of scrap. There’s a lot of rewriting. There’s a lot of trying things and having no clue what’s going to work. So what we do, we actually describe three different major phases that we go through. The first phase we call the R&D phase. R&D phase is where we are not actually shaping to the degree where we say, “at the end of the six weeks this thing has to be fully built and fully working and we expect it to exist the way that we more or less defined it in broad strokes.” No, we’re not doing that. Instead, we have a quite experienced small team. So this is like David is himself doing the programming at this stage and he’s working with a very senior designer and Jason’s involved. And so in this case with Hey, it was Jason, Jonas, one of our lead designers, and David. And they’re shaping and building in a completely unpredictable, blurry mix as they go. And what they’re betting on is, “look, we’ve got a handful of ideas of what we think we might be able to do in this product. So we are going to dedicate the next six weeks to this sort of few ideas that we’re thinking about.” And there’s no certainty about what happens after that six weeks. So there’s a capped downside on the effort, right. And then what’s going to happen is they’re going to build an approach to the inbox and then they’re going to realize, like, “oh, that modeling doesn’t work because that’s not going to give us this other thing that we think that we want to do.” So then they scrap it and then they rewrite it again, right. You go through this process of trying to reach a point where you have some stuff in the code that is like firm; where you have, like, these tent poles where it’s like, “these basic things are kind of working and we think that we can see how this is all going to hang together and this is going to create the open spaces for all the little features that we think that we want in the future.”.

Ryan [00:34:54] David calls it firing tracer bullets because you’re not actually building anything to completion. You’re not building anything to even, you know, people say MVP or whatever, like none of this is usable by anybody. But you’re building just far enough to say, “ah, that’s going to work; I’ve got the model figured out and I’ve got the caching figured out that this is going to be performant,” or whatever those core fundamental scary questions are, you’ve got that core architecture there. That’s what R&D mode is about. So we’ll do a number of cycles, however many cycles they feel comfortable investing in, depending on the derivative of the progress, like depending on this feeling of like, “how much faster are we getting warmer or how much faster are we getting colder?” Like, “is the trail getting hotter or not?” Like that’s sort of what’s going on as they’re making bets six weeks at a time.

Ryan [00:35:44] Then you reach a point where you say, “OK, we’ve got like a few key elements in this product that are all half-built.” But we’re actually ready to say, like, “we’re going to pour concrete on this.” Once you pour the concrete and you have the main moving parts of the system sort of frozen in place, now what you have is all of those empty spaces with walls around them where you can delegate other teams to go build stuff inside of that structure to do the millions of things that the tool has to do to be like production-ready, you know, without these huge unknowns about what are the load-bearing structures. So that’s the point where we flip into production mode. The whole time we were doing six-week bets, but now what we’re doing is we’re being much more explicit. We’re fully shaping. We’re giving the work to a separate team. This core senior team isn’t doing all the work anymore, and there’s no expectation anymore about scrap and rewriting, but it’s the opposite expectation that this is gonna get committed into master at the end of the six weeks and we are going to live with this and this is going to go out to customers the way that we finished it in that six week period, right. So we had about, maybe even a year of R&D cycles with a super small team on Hey.

Sean [00:36:59] But it was the same team through all those six-week cycles?

Ryan [00:37:02] Yeah. So an R&D phase necessarily has to be a little group with deep shared context because you are swimming in unknowns together and that’s what most of the work is.

Sean [00:37:12] That makes sense.

Ryan [00:37:13] Once you get over that hump and the core architecture is there, now you can delegate projects to other people because they see where the outlines are that things fit into. Then we had about maybe a little less than a year of more-or-less traditional, straight, what we call production mode, which is shaping, betting, and building. And then all that stuff that gets built more or less goes into the final product. When you’re doing a new product, there’s a lot more latitude to yank something at the end of a cycle, not in the sense of the circuit breaker, but in the sense of, “look, we’re willing to experiment more and we don’t quite know what portfolio of features we want to make the final cut of this thing.” So there’s a little bit more of an allowance for like, “Hey, we’re going to actually bet six weeks on this feature, but we may decide that we don’t want it in the end,” which is a different thing than, “it blew up on us and it took longer than we thought,” or whatever, right. So there’s those periods of the production mode cycles which are straight Shape Up. And then finally, there’s two or three cycles, or something roughly like that, of what we just call cleanup mode, which is literally like whatever comes up, whatever you can find, it’s just complete chaos on purpose because there’s a certain level of, the smaller the scale of the issues and the more random the issues are, the less you can plan. So we deliberately create a time box where we say, “we don’t have a plan; all we know is we’re gonna make the most important things better until we run out of time,” right. And then those are the last couple of cycles before launch.

Paul [00:38:40] Which is how it goes anyway. It’s just nice to do it on purpose.

Ryan [00:38:45] Yeah, exactly. We’re just acknowledging the fact like, look, “there’s a lot of loose ends here; there’s a lot of little things and we can’t anticipate this so we’re just going to reserve capacity for it.”

Paul [00:38:55] Yeah, that was a five-minute masterclass in software development and UI design. That was great.

Sean [00:38:59] Thanks for that.

Paul [00:39:00] Yeah, for sure. I want to ask you just a more general question, as we’re I think coming up to the end of our time together. You’ve taken a lot of knowledge in the industry and codified it in a very usable way. Who influences you? What books or mentors do you look to? If you were talking to a product manager who asked for a recommendation to read, besides Shape Up, obviously, where would you point them for reference tool to get their bearings in the industry today?

Ryan [00:39:26] So I had to go really far afield to find all the things that I thought that I needed and then get to a point where I could synthesize it into some kind of a package, you know. So in the beginning, I was studying all of the early Agile originators, the Kent Becks and the Martin Fowlers, and these folks, you know, the culture around extreme programing. So that was an input to Shape Up. There were also some inputs that were a little bit more distant, like Christopher Alexander’s work was a huge input to how we work in terms of being able to structure and understand what we were doing. Tons of Shape Up traces back to Christopher Alexander’s work and folks who know would also know that people like Kent Beck and Eric Evans and Martin Fowler are actually, they’re all Christopher Alexander fans. A lot of that also went into that early stuff. So there was all that and then I learned quite a bit from studying Clay Christensen’s work. And then, later on, Bob Mesta has been a major mentor to me, and I’ve learned a ton from him.

Ryan [00:40:25] There’s also a bunch of other things, too, but those are some of the main things that stand out the kind of went into the soup, you know. Today, when people ask for references, Shape Up was my effort to provide something that people can use today for the task of, “how do we change our organization so we can more reliably and repeatedly set a direction and then ship that thing that we tried to do?” Right. That has to do with the shipping muscle. Shape Up doesn’t really help you with strategy. It doesn’t help you to figure out what to shape, right, or what to bet on. And that has been a huge area that deserves a whole nother book. The best starting point that I can recommend in that area is called Competing Against Luck by Clayton Christensen. And actually, you’ll see quite a few anecdotes from Bob’s projects inside of there. And that is a really good introduction for how to think about scratching the itch and how to think about what matters and what’s valuable from the demand side instead of the supply side. That’s a really good starting point. Man, I mean, there’s a huge frontier ahead of us, I think, for how to spell out more of this stuff and that’s kind of where my head is these days. I’m trying to get better at teaching that kind of stuff. And so, you know, the path that I went through is first getting the basic theory from something like Competing Against Luck and then learning customer interview technique, which I learned from Bob. He does workshops and there’s also some online courses and stuff like that. There’s kind of a whole path to go down there.

Ryan [00:41:48] And then the other area is, I’ve actually been looking for how to more, like, rigorously explain the way that we deal with risk in the shaping and de-risking process. We’ve been doing the practices for years and years and years, but I got some of the language and the rigor around it from reading Nassim Taleb’s work, especially Antifragile was a big eye-opener for me. And then there’s also a lot of stuff from Genichi Taguchi’s work that I’m pulling in now that’s helping to clarify some of what’s going on in that phase of Shape Up. But this is sort of getting into, I don’t know what you call it, like the grad level of Shape Up. You know what I mean, like, whatever that is, I’m trying to head in that direction. So that’s kind of what’s there for the future. But for today, I would definitely recommend Competing Against Luck.

Paul [00:42:31] Well I certainly can’t wait for the sequel.

Sean [00:42:33] All right. One last question for you before we let you go. How do you define the word innovation?

Ryan [00:42:39] I think innovation means doing something new that’s useful. Novelty is just new and innovation is where I have to do something new because there’s a struggle. So what I’m doing isn’t working. Got to find a new way. That’s what innovation is.

Paul [00:42:53] Love it.

Sean [00:42:54] Well this has been fantastic, Ryan. I really enjoyed our time with you and I’ve learned a ton. I can’t wait to publish this. There’s a lot of great nuggets in here and you’ve been a rock star in our space and I really appreciate the energy you’ve given to this. Thank you.

Ryan [00:43:06] Hey, thanks so much for having me. It’s a lot of fun.

Paul [00:43:08] Thanks for your time, Ryan. Cheers.

Paul [00:43:13] Well that’s it for today. In line with our goals of transparency in listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get so please leave a comment or a rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch, and inspire the world, just like you’re doing. Thanks, everyone. We’ll see you next episode.