Getting to Shape Up 2.0 – Ryan Singer (Author of Shape Up & Founder at Felt Presence) (EP1)

Welcome to Shapers and Builders, the show about better ways to deliver great software products. Today I'm speaking with Ryan Singer, former head of strategy at Basecamp. Ryan went through nearly every role in the product development stack during his 17-year tenure with the company, from UI design to programming to product management and, most recently, product strategy. In 2019, Ryan formalized the way that Basecamp was working into a framework that other companies could use. resulting in the release of the book, Shape Up, Stop Running in Circles and Ship Work That Matters. Since then, a lot has happened and many teams have adopted and adapted Shape Up. Ryan, in turn, has taken these learnings from those teams to reshape the framework and decouple it more and more from the specific context of Basecamp, a bootstrapped and stable business with a high share of senior people. In our conversation, we explore some of the initial reactions to ShapeUp, including common criticism of the framework. We then go deeper into the evolution of ShapeUp 1.0 into the 2.0 version, which Ryan is now teaching in his course, Shaping in Real Life. You'll probably get the most out of this interview if you're already somewhat familiar with the ShapeUp framework. If you want to catch up on context first, check the show notes for some links to get started. I'm particularly excited to have Ryan on today because this episode actually kicks off the first season of the Shapers and Builders podcast, where I'll be speaking with teams of all sizes and stages to hear their stories of adopting ShapeUp, how and why they've introduced it to their companies, and the tweaks they've made along the way. If you're curious to hear some real-life case studies of teams working with ShapeUp, make sure to subscribe and check out the other episodes of the show. But enough introduction, let's get into the conversation. Hey Ryan, it's such a pleasure to be speaking to you again. I want to talk to you about ShapeUp today and how this framework has evolved over the past three to four years. So to start things off, can you give us the 90-second introduction to what ShapeUp is? Oh, good challenge. Well, I usually start with why somebody would even get interested in it. People usually get interested in ShapeUp when the development process they're using isn't working. So if you're using something like Scrum and you're finding out that there's a lot of meetings and there's a lot of time going by and there's sprint after sprint, but stuff actually isn't getting finished and you start to think, okay, is there another way that we can do our product development that's going to work better? Also, I see startups who are just kind of doing everything organically, you know, without any structure at all, but then they reach a certain stage where they start to grow and it's kind of like, okay, now we need some process, but we know that we don't want to just mindlessly, you know, file tickets and think that that's also going to help us to actually ship quality work. So it's usually either coming from a standpoint of like, how can we ship better or how can we kind of. give the teams more autonomy so that leadership has more time to work on other things. And it's, yeah, stepping back from this kind of typical agile thing that we've seen where it's like two weeks out of time and very ticket based. And instead of actually asking the question of what is it strategically that we want to do and how do we put our heads together to solve the really important unknowns and have a kind of strategy about what it is that we're going after and what it is that we're trying to build. So actually bringing people together to do what's called shaping, which is like figuring out the overall architecture and the key trade-offs of what we're going to build in such a way that the build team actually has more freedom and more autonomy to make decisions inside the delivery phase and they can actually get things done on time. something like that. I think it's hard to boil it down to 90 seconds, but usually those are some of the factors that are driving people. Yeah, perfect. And we'll get into much more depth. But you published the book on ShapeUp in 2019 and recently launched a course around it called Shaping in Real Life. Why was that necessary? Well, the original book, ShapeUp, came out in 2019 and it formalized all the things that we learned at Basecamp over the 17 years that I was there. And those things were, you know, when the book first came out, there were a whole bunch of companies that immediately adopted it. You know, they were like, this makes perfect sense to us. We're going to work in six-week cycles, like the book says. We're going to do shaping before we start the actual cycles. We're going to do cool down. They did all the things that were in the book. But then a lot of people started coming to me and saying, oh, we're doing parts of ShapeUp, or we're trying to use pieces of it. And what I understood was that the companies who were just like Basecamp, they were able to just take everything in the book and run with it. But companies who weren't like Basecamp, they weren't actually able to use it, but they still needed, it's funny, they were still trying and they were still kind of twisting it and adapting it so that it could be something that they could use. And when I say companies that were not like Basecamp, what I mean is companies that were VC backed instead of bootstrapped. So they have different pressures. Companies that have more of a gap between junior and senior people instead of having mainly senior people. Companies that are significantly larger, where you have like a thousand people in the organization instead of just 50. Especially companies where the ratio of designer to developers is much different. At Basecamp, every single build team had a dedicated full-time. product designer, somebody who could do interaction design and front end design and all that stuff. And a lot of software companies have more of a one to 10 ratio where there's like 10 for every 10 programmers, there's only one designer and sometimes even fewer than that. And so a lot of the stuff that's in the book doesn't translate directly for them. So I had people reaching out to me again and again saying, how do we make this work for us? And what I understood was that instead of taking this single package where like you have to do all of these things exactly as they're written, that it was actually possible to break apart what's in the book into separate individual practices that teams can adopt. So what are different things that we can do to shape? What are different ways that we can create a time box for ourselves that's meaningful instead of just two-week sprints? And a lot of the things that kind of people thought were sacred, turned out to be much more flexible, like this length of the cycles or how you involve designers at which phase, the latitude that you shape at, whether it's rough marker, like this fat marker sketch, or sometimes you actually need to define more detail up front. Sometimes you need to define less detail up front. So this kind of setting the dial on what is the right... amount of information to include when you shape. There's also some really interesting things that we found out about. In the original book, we have what's called the betting table. There's this idea that somehow a set of pitches are going to come to the betting table and then there's going to be a choice of which thing are we going to build in the next cycle. But that actually presumes that there's enough time to prepare and meaningfully shape multiple pitches. right? Which very often isn't the case in a lot of companies. This was a luxury that Basecamp had. So what I often saw actually was that teams who were trying to follow the Basecamp way, but they weren't structured like Basecamp, they would end up very superficially shaping. They would have like a bunch of pitches, but they weren't really getting into the nuts and bolts of why is this viable and how is the hip bone going to connect to the leg bone? And like, what is the mechanism that we're actually going to make? They were much more like, kind of like sales pitches. You know, here's a reason why we should add this feature. Here's a reason why we should do this. We should build something in response to this request we're always getting from customers. And a lot of what we end up starting to... Well, like actually a lot of what this course teaches is how to really recognize the difference between just making a sales pitch where the product team is saying, here's why we should do something. And then it all lands on the laps of the developers and they have no idea what the real requirements are and what success or done looks like. And stepping away from that and figuring out how do we actually put product and engineering together in the shaping session so that we have a more meaningful understanding of what we're really getting into. And we actually start to make some trade-offs together and understand what we're proposing. Yeah, that makes a lot of sense. And so you mentioned who the course is for. Was that also what you then observed in the first cohort that you had, this mix of people from larger companies, VC-back, kind of growth-driven? companies? Or was it still very much the core bootstrapped scene? You know, there, what I saw was that there were some folks who originally fell into the core bootstrapped kind of group. But then since then, they're there, they've hired a lot more people, and they've had to deal with problems that they didn't have to deal with in the first place. So we saw some folks who were originally very small bootstrap teams, but since then, they've grown and now they have new new difficulties. but actually the majority of folks who've come into the course have been people from VC-backed companies, from larger companies, smaller teams inside of bigger companies who are trying to make this work for them. And do you hear from participants? kind of how they then are able to translate what they learn in the course in their teams because it's you know i assume it's a big challenge knowing what you know and then applying that in your team going back home and the team might not have been in the course and have that context yeah that's interesting we're seeing different things there for some people they have this a big aha moment so i've had some cases where the the founders or somebody who's like VP of engineering or somebody who's head of product, they're saying in the Q&A during the course, they're saying like, oh, wow, I didn't realize like what we called shaping was actually just framing what we were going to do. And we weren't actually getting enough into the detail. And like, no wonder we were always having these problems in the build cycle, right? Like they're having kind of just these big like aha moments. Another thing was that we saw a lot of people trying to shape asynchronously instead of actually putting their heads together into live shaping sessions. And there were some big ahas there too of like, oh, wow, like, okay, so I'm going to go back to my team. And instead of sending documents back and forth for discussion or for comments, I'm actually going to put this, you know, we talk about how to choose a technical shaper in the course. There's people who say, I already know who represents the customer knowledge, but now I have the technical person in mind and we're going to bring those people together and ask them to do a shaping session. I'm really excited to try that. That's something that we hear. Some people are able to just run with it because they see what they couldn't see before. understand the practices enough to kind of guide people through what a shaping session is going to look like and how they're going to actually run that or how they're going to package the work differently. That's also something we talk about. The other thing is like taking things, for example, from the point where there's a shaped packaged piece of work that's ready to go. to giving that to a junior programmer and saying, how can I actually trust them that they're going to be able to run with this, you know, without a lot of management for six weeks. You know, we teach, for example, the handoff exercise there. And those are, that's the kind of thing where people go like, oh, I'm going to go try that. I think I can see how to do that. There are other cases where people have said that there's, they want their teams to really learn this language to be able to, we talk about judging what room are we in? There's kind of this mindset of like, we're trying to do some work and sometimes it's very clear what the problem is and we're just debating different solutions. So we're kind of in a shaping phase. Sometimes we're trying to shape something and we're just going in circles because nobody can even agree what the problem is. And then that's the kind of thing where it's like, oh, we're not actually ready to shape this. We need to step back and frame. what is the actual problem or build the business case for like why to spend time on this problem instead of that problem because we're not agreeing on what's worth spending time on. So identifying the difference between when we're framing, when we're shaping, when we're spiking, when we're in packaging and when we're actually moving into delivery. Those are all kind of different kinds of work where we're asking different questions and we're taking in different things that we've already solved to carry them forward into the next step. some of the people want their whole teams to be able to speak that language in order to start kind of better problem solving the different things that are going on in the development process. So I've seen cases where folks have actually brought their whole team through. So they said, can we do a private cohort? And then they bring the whole team through. And then they have six people or 10 people go through as a batch to all get up to speed on the same language. So then they can go into these. framing sessions and shaping sessions and they have more common language to actually get through that. Yeah. After the book came out, I certainly felt a lot of reactions to it. Some were very positive, but some were also quite critical. So what I'd like to do with you is a quick fire round of the most common criticism or maybe misconceptions you tell us, right? Around ShapeUp. I get your take on these. Would you be up for that? Yeah, certainly. Okay, so I have a list of five, and I'm just going to read them out to you, and then you can kind of react to them whichever way you see fit. The first one I have here, I call the Lonely Genius Shaper. And the quote I dug up here was... It smacks at times of the genius solo designer crafting their masterpiece and doing the deep work while the team executes. I'm pretty sure that was not the intent, but it is implied in a couple of places. That's very good criticism. You know, what we've seen, this is also coming to the experience at Basecamp versus the wider world. We had the situation at Basecamp where the people who were doing the shaping represented three kind of very different areas of expertise. When you're doing shaping, someone has to represent what is actually technically practical to do, what is technically possible. So someone has to have deep technical knowledge. Someone has to understand what's actually valuable to the customer. Someone has to understand the interaction design. So there's these different areas that all have to come together in the shaping to come up with something that is going to be viable and it's going to be fun to work on that's going to be meaningful. And we were in a situation where we had a lot of those skills kind of in the same people. So there were a lot of cases at Basecamp where one or two people could lock themselves in a room, shape a concept and bring it to the team. And when we gave it to the team, the team wasn't saying, okay, you know, here we have another concept coming from product where they don't know what they're talking about. And they tell us that we should go build this, right? You know, usually when that happens, you see a really big disconnect, where the product people come up with an idea, and then they make a whole bunch of drawings and stuff like that. And then they bring it to the technical people like, here's your work. And the technical people are like, this isn't at all executable the way that you think it is. You know, and that's, of course, that's a frustrating situation. Now, when the person who's doing the shaping actually is really close to the technical people or even works with the technical people, you know, it can be that you give that work to the technical people and they say, awesome, I'm really excited to work on this. This is something that is doable and makes a lot of sense to us and we're eager to start on it, you know. So the thing that's really important for teams to be successful with this is to bring the right people together into the shaping sessions. So at a minimum, make sure that it's not just the artist with the beret who's going to make the giant Figma drawing and then say, here, I've solved it all, right? But to actually have the person who looks at it from the design perspective and very importantly, the technical person. In fact, the technical person is a huge critical piece. of a successful shaping session because what we're shaping is is a piece of software it's actually something that needs to get built so the technical piece is critical to be there from the absolute beginning so we usually talk about three roles you know bringing the the product person who really understands what the customer is trying to do the design person who understands kind of what is going to make sense in terms of getting from a to b in the interface and in the flows and then the technical person who understands what can be built, what we can execute. And then the three of them can all make trade-offs together. And then when specific questions come up about what is viable or what is practical, actually doing spikes. And that might involve doing a little bit of deeper work on the technical side to figure out if something that we think we're going to do. in this concept is actually something that's realistic or if there are unknowns there that are going to blow up, right? So yeah, I think if you take the shaping and you think that now like our designers or our product people are going to solve it all and give it to the technical people, that's definitely a mistake. And we need to bring the technical people into the shaping process, but recognize that it's a different type of work that happens. and it's under a different clock. It's not something where we, when we're inside of a time box and we've committed to do a project, that clock is ticking, right? Versus when we're in the shaping phase, we can throw out, we can throw out the whole project and completely take a right turn and go down a different direction because of something that we discovered together. So it's not as much about the shaper, but it's about the activity of shaping needing to happen, right? Yes, exactly. It's about not just going into a delivery time box where we're supposed to be shipping something when we don't actually know what it is that we're shipping and we haven't done the diligence to make sure that we know what we're doing and that it's viable. Yeah. So the second item I have on my list is in ShapeUp, teams aren't really empowered. And the quote I have for you is, I do worry that it is heavily biased to certain perspectives about the role of designers, leaders, teams, etc. It's surprisingly disempowering approach for a team, but they make a point of talking about empowering teams. So I'm not sure. if somebody was speaking from experience when they said that they found it disempowering, because what we hear from the teams who adopted is very much the opposite. We're not trying to sell anything here as empowering. This is a quote from people who've adopted it. A standard approach is figure out what we're going to do. So a lot of software companies, what happens? There's either a main, even if they say that they're agile, even if they're scrum, somebody is coming up with the concept of what's going to get built. It's happening somehow. And that's either in the form of an architecture from a senior technical person, or it might be a bunch of figment files from designers. Somebody is creating something that is like the thing we're going to go build. And what happens on a typical team today is that work then gets split into tickets and those tickets get assigned. And that's what the technical people are responsible to do. They're responsible for completing tickets. In the shape-up model, there's no step of assigning, of breaking the work into tickets and then this is your ticket and that's what you're responsible for. The team is given the overall concept of this is the thing that we think we can go build. So the team is given the shape concept and then they work out for themselves what the actual tasks are how they want to implement that. They make trade-offs. There's latitude for them to make changes to what was defined in the shape work. So when we talk about empowerment, I think it's mainly contrasted against this environment where you are just executing tickets and then somehow the tickets are all supposed to fit together. Like somebody created all the Lego bricks for you and your job is just to make them so that they will all snap together in the end. Instead, what we have is that the team is actually responsible for the whole thing coming together, and they are figuring out how to integrate and how to design all the different pieces so that this thing actually does what it was intended to do. Yeah. I think the criticism, I mean, I'm speculating 100% here, but I think it might come from a perspective where now there's kind of... streams of thought within the product community that are pushing engineers to be super involved in discovery, speaking with customers and spending time on that side of kind of the product turf, if you will, which wouldn't be part of kind of the standard shape-up setup, right? I actually think it is part of the standard shape-up setup and it just didn't come through clearly enough in the book. If you really read carefully, you will see that from the very introduction, shaping is described as an activity that integrates design, product, and technical knowledge. There's no way that you can shape something if you don't have the technical factor in there. And that has to be there. Absolutely. It's just that I don't think I made the point clearly enough in the book. I said that the shaper needs to be technically literate. And I think that that didn't go far enough. If you're working in an environment where the product is mostly just reading and writing from a database and the interface layer is really thin, then technical literacy is actually maybe enough. But in a lot of cases where people are working on, it's not so simple. Fundamentally though, you need to have that technical knowledge. all the way at the beginning of the process when you're figuring out, is this a viable path that we want to go down or not when you're shaping? That's essential. Yeah. The third item I have here is it works because of the stability slash stagnation at Basecamp. Basecamp is growing, but stable small team, no venture-backed growth goals, very tight founding group, a single product with a narrow scope. So there's truth to that. The specific practices that the book argues, six-week-long cycles, two weeks of cool-down, shaping multiple pitches in parallel, and then bringing those to the betting table to decide for the next cycle. No roadmap at all, basically. All of those specifics are... completely related. I think stagnation isn't fair, but they completely are related to the fact that Basecamp was bootstrapped and Basecamp ran on, had the luxury of doing things completely on their own schedule. And any company who's bootstrapped, whether you are fat and happy because you've reached a lot of success, or if you are you know i did a recently i did a project where we had one part-time programmer and we had very very little budget it was this like shoestring budget with one part-time programmer but we were bootstrapped and it's funny because it felt like working at base camp because we could go on as long as we wanted you know there was no external pressure that we had to finish because our costs were so low And everything was so small that if we wanted to just keep going three more cycles because we thought it was meaningful, that wasn't a problem for us. So being self-funded and having really low costs, this enables you to work that way. So I think that that objection is coming more probably from somebody who's in an environment where they have more external pressures. And of course, if you have investors, you cannot just... go cycle after cycle six weeks at a time doing whatever you feel like, right? Whatever feels meaningful to you. And in that situation, this is where we actually see a lot of teams doing shape up, but varying the length of the cycle, actually setting the time box ad hoc on a per project basis. So they might say, look, here's something that's burning, that's really critical, that's important that we need to do. we want to be able to get it done in the next three weeks. Now, but if we just go and talk to the developers and sit around a table and then start building something, we know that our likelihood of actually shipping at the end of the three weeks isn't high enough. This is likely to just spiral out of control or, you know what I mean? We're going to get into some technical area that was more complicated than we thought, or there's going to be miscommunications, blah, blah, blah. You can be under tight deadlines, two weeks, three weeks, and still say, okay, but in order to use those two or three weeks effectively and ship something at the end of it, we need to do a shaping session first, right? We need to actually be clear about what it is that we're betting on. So I think that's more a reaction to the pacing and the cadence in the six weeks than it is to the actual process. The next thing I have on here is a bit connected. And it says, there's no way I could justify the team sitting idle during cool down, basically for 25% of the time, assuming a six week cycle plus two week cool down rhythm. That sounds to me like the perspective of somebody who is under pressure from investors. And I've heard this from teams who are VC backed. And they said, there's no way that we can have something called cool down. So what we ended up doing was created something called ramp up. Because the thing is, if the team is actually completely focused inside of the time box, whether it's six weeks or whether it's three weeks, whatever it is, where they are just totally heads down delivering something that is extremely valuable and that's well-shaped and then they actually ship that at the end of that time, there are going to be a lot of little loose ends lying around that need those people's attention. There's going to be the little thing that marketing needs. There's going to be the little bit of tech debt that, you know, there's going to be this infrastructure issue. There's going to be alignment meetings that need to happen or different kinds of meetings that are between different people who couldn't meet because their heads were down before. So if they were indeed really focused during that time box, there's going to be a lot of other stuff that has been waiting for their attention. And then at the same time, if you are going to be really deliberate and strategic about what happens in the next three weeks or the next six weeks, there needs to be time for everyone to pull their heads up, look around and understand like, where are we actually going next? And that might involve having a couple of shaping sessions or doing a little bit of spiking before feeling like we can turn on the green light to start the next focused effort. So that ramp up time where we actually figure out what's next and we coordinate with each other and we take care of all the little things that have come up in between, I mean, that is functionally going to be really necessary and valuable. It's not that everyone is sitting around idle. it's the difference between we are targeting our efforts toward a very specific project that we have scheduled as opposed to we are giving ourselves the room that we need for all the unpredictable little things that are going to need our time so that we can again focus on the next focused effort. Yeah. On your website, you have this video called Shaping in a Nutshell. And I think in that video, you speak about also two ways to split the kind of the strategic work versus the reactive work. And it sounds like that might be connected to what you just said, where kind of my following question would be in a setting where you have separate tracks for these kinds of works. do you still see teams using cooldown on the strategic tracks themselves or ramp up? Sorry to stick with this. Yeah. Well, depending on the team, sometimes cooldown, sometimes ramp up. Yeah. We see teams doing a, doing a, sometimes a week long pause in between the planned efforts, but it's just, it's just because if you're going to do a project, you know, projects have a start and an end. And there has to be some coordination in between. And the idea that you're going to ship on Friday, I mean, that you're going to ship a major effort on a Friday and then kick off a major new effort, a multi-week major effort on Monday, it's just not going to happen. That's just not how life is. You can't do that. You need some time in between to coordinate, you know? So that time just has to be there. Whether it's two weeks or not, That can depend on the other things that are going on. And this thing that you mentioned about the difference between the planned work and the reactive work, this is a big, big, big thing too. This is really important to recognize. One of the things that teams struggle with is sometimes they try to adopt shape up and they think now that all software development should happen in some kind of a shape up way. And that is simply not the case. So reactive work, is work that is not only small, we think about bugs and little issues coming up from support or like marketing needs this thing. It's not only small, it's the fact that it has urgency attached to it from a stakeholder somewhere. It's the fact that it's on fire that makes it reactive and that you can't decide when you're going to do it. There are a ton of little bugs and little technical debt things that are small and they're bad, but they're not urgent. Nobody is saying like, I need this in three days. And if I don't have it, I'm blocked and it's a problem for us. Right? Yeah. So the reactive work, it has that urgency. And that's why it's a problem for project-based work because it interrupts us because of the urgency. And so this is why I literally am telling people, don't use shape up for that. a ticket-based process is way more suited for that kind of work. A Kanban is way more appropriate for that kind of work because you are trying to get the fastest flow from step to step to step so that you can get that urgent thing done. So separate capacity using a separate process, much more ticket-oriented, whereas we're not in the ticket world in ShapeUp, but very much in the ticket world for the reactive stuff. Yeah. This, by the way, includes project work where you do not control the schedule of all of the participants. So you might think of, let's say, an integration with a client, you know, or you have to do an integration with a third party, and that might seem to be a project. But if you are going to be waiting on the client or the vendor or the third party to do their part of the integration work and get back to you, you're not going to be able to do that in the shape-up model because you don't control the time box. So that would be much better to move that over to a Kanban and think of it as more of a ticket-based process. The last item on my list of top criticism or misconceptions is shape-up is just mini waterfalls. Teams execute a project and never look back to check, for example, if the intended impact materialized. There's no iteration. So I would ask, is this about, teams never look back to figure out what happened. So is this saying that once something is launched, that then there's no opportunity to evaluate whether it was successful and to improve it or something like that? That's my read of it, yes. So if we, first of all, if we are indeed shipping something and that piece of work is finished and it goes out into the world, now we can really get the feedback that we need. Because we've shipped, now we can iterate because we actually have meaningful feedback from the market, from customers, from real behavior out there in the field. A lot of times I think what gets called iteration in a more of a scrum context is actually a never-ending project. It's like we're going to keep making it better and we're going to keep making it better and better and better. And we're still not ready to ship it because it's not better enough. It's not good enough. It's not perfect enough. Yeah. And then what ends up happening is there's so much time that goes into it that project drags on so long that by the time you finally ship it, you can't actually justify spending more time to improve it because now you have a giant backlog full of other things that you haven't finished. Yeah. So actually, the more that we can shape a targeted effort. spend a strategic amount of time on it, the three weeks, the four weeks, the six weeks, ship it. Now we can decide, do we want to shape a new project based on the feedback that we got from the world to make that better? Do we want to work on something that is a completely unrelated feature or do we want to extend the thing that we previously shipped? Or do we want to rethink the thing that we shipped and do it in a different way? I mean, all those possibilities are on the table, but we really need to have the actual real world feedback to know how to make it better. Yeah, I think from my experience, this critique of mini waterfalls and not being attractive, it comes from teams that are working a lot in the... MVP mindset, which oftentimes tends to be an excuse for shipping half-ass things because you can always iterate the next sprint and make it better, which then doesn't happen. Is that something that you think ShapeUp fixes or prevents in any way because you're more intentional about the work? Well, I would say the first thing is that if people are happy with what they're doing, then there's no reason to even switch to ShapeUp. right so if someone is in some model where they are um constantly iterating on things and they don't think of it in terms of shaping projects that they want to walk away from then that's that's perfect for them the place where shape up kind of becomes relevant is when the team starts to feel like why are we never done you know when it starts to feel like a struggle that we never seem to reach the point where we can say that this is actually done and we walk away from it because it's effective and it's doing what it was supposed to do. So iteration is great when you are trying to get somewhere, but iteration isn't great when you're kind of wandering around and nobody knows kind of where the finish line is. I hope you're enjoying the conversation. I wanted to take a moment to thank you for listening. And to let you know about the Shapers and Builders job board, on shapers.builders, yes that's the domain, you'll find jobs in software development, design, product management and other roles at companies that work with ShapeUp. Many of these roles are remote and teams who use ShapeUp generally run at a more sustainable, healthy and meaningful pace than the hamster wheel of two-week sprints. So if you're looking for a job in tech or trying to find great people, head over to the Shapers and Builders job board at shapers.builders. Now let's turn back to the conversation. So turning from criticism to a more joyous topic, I'd love to hear if you had any kind of positive surprises from teams using ShapeUp that you learned of. The number one positive surprise is that it continues and continues and continues to spread underground. If I were to use Twitter and LinkedIn as a judge of what is going on in the industry, it doesn't match the picture that I get from all the private messages that I get from people. And that to me is totally surprising and really interesting. Also, the interest in the course has been really surprising and interesting. There are so many people who are aware of the fact that the way that they are doing their product development, you know, that there are all these disconnects and that Scrum and all the kind of best practices that are out there that they aren't working. But somehow it's not, it's not something that's out there yet as a public conversation. You know, it's funny. We tried, we tried to have like a, like a public shape up forum when we first launched the book. and it was just silent. At the time, I was a little bit disappointed even. I was like, oh, nobody's using the forum and nobody cares about ShapeUp. Of course, what I discovered was that the issues that the book addresses are the really, really hard questions at the highest level in the company. They're the questions that the C-level people are struggling with about why aren't like, why are we so ineffective? Yeah. You know, and of course, you're not going to be a VP or a C or a C level person and go onto the public into a public forum and then start talking about how ineffective your team is. Yeah, that's true. Although I have observed some some posts of, you know, I guess I know what the firm you're talking about, and there have been people sharing their struggles. But again, I think that the, the first niche was just the kind of the bootstrappers community, if you want to call it that. And then the C level of those companies, I think. So that's a different. Yeah, sure. Yeah, there's been some of that. Yeah, yeah. Especially those bootstrappers who were really close fit that we saw some of those posts. The other thing that's really surprised me is how often I've seen a lot of teams where there's an engineering kind of department. Okay. So we're talking about a slightly bigger company. There's an engineering department and this engineering department is using something like Scrum and the product folks have understood that giving the engineering people you know, drawings and Figma drawings and all this stuff, you know, or a bunch of research from their discovery that there's too big of a disconnect and everything is getting lost in translation and it's not working. And in my original kind of, yeah, like vision of this whole thing, like when I wrote the book, I thought that the way that the team does delivery was really important. Like from the moment the cycle starts until the moment of shipping, all this stuff about breaking the work into scopes and using hill charts and all of this, I really thought that that stuff was essential for doing shape up because it was actually kind of the area where I was digging deeper in my own, I don't know what you call it, like in my own development, you know what I mean? Like as a practitioner, like that was the area that I was kind of geeking out on the most. And what I found out is that for 90% of teams, once you establish a time box, the beginning of the time box is just a starting gun. And then once you fire that starting gun, it's just like off to the races and you cannot influence anything. You cannot control anything. And what I've found is that all the really like most of the leverage is actually in the shaping and bringing the experienced technical people into the shaping. having that push and pull between the design concept and what is technically feasible in the shaping. And that's so, it's just been amazing to me to see like the kind of results the teams are getting, even when they still have to put the work through a paper shredder afterward. And that to me was like kind of a really kind of violated my sensibilities that you could still have this paper shredder of splitting everything into tickets and then just assigning tickets and so on, or doing it in two weeks sprints or whatever. that even still just doing that shaping first had a huge impact on the team's ability to ship on time. So that was really surprising to me and really nice to see because it also means that, and this is a big part of why we ended up, my wife and I created this Shaping in Real Life together. I was telling, I had finished a consulting project and we were looking together at all the new things that we did in this consulting project. And it's like, there's a whole new way to teach this that's different than what's in the book. And she was like, why don't you, why don't we like, have you thought about making a course? Maybe we should make a course for this. And so that's been really interesting because now what we're seeing is that teams can pick off the practices that they want to choose. For example, like the framing and shaping steps. And if they don't have influence over the way that the engineers work, that's okay. They can still have huge wins. And then gradually what I'm finding out is that introducing these new techniques inside of the delivery phase, like breaking things into scopes and working on a scope basis and like dealing with the unknowns and stuff inside of that, like making trade-offs inside of the delivery phase, using the hill chart inside of the delivery phase, that stuff is actually all kind of like advanced level. Once you really have shaped work, And you have the folks who are in the delivery phase are feeling really engaged and they want to kind of take it to the next level. Like then these things come in, but they're actually not at all necessary to start. Yeah. And I can definitely second what you said about this underground spread of ShapeUp. I'm often surprised myself when I'm speaking with other teams and they are saying, hey, you know, we actually know of ShapeUp. We've tried it or we're using parts of it. just two weeks ago, I was interviewing and speaking with an agile coach. That was kind of the pinnacle of surprise for me that, you know, these people who are certified in SAFE and kind of that side where I felt like initially there was this divide between ShapeUp and the Scrum community. And now we have agile coaches that are kind of implementing um shape up and in that case a huge company across 20 21 teams i think he said so that's been a big surprise for me as well wow cool i even heard just yesterday i heard an interview with kent beck who i greatly admire and learned so much from studying his work i mean like he's like on the very like top shelf of important influential people in the in the world of agile and programming that i learned from you know, through studying XP and everything that he did. But there was an interview with him and he said that he was really disappointed that he sees kind of what he called a reversion back to waterfall. in out there in in in this in the industry today that there's a swing back toward upfront design and i'm listening to that i'm thinking like i wonder i wonder if it has anything to do with what we're talking about here you know and of course of course we don't want to go back to that 90s style waterfall either this was also a big mistake you know what i mean so that's not what we're talking about but there is a trend toward more upfront thinking at least, you know, and it could possibly be misinterpreted by people who are really very strongly agile in their mindset where they might get nervous about that. I could understand that. Yeah. Tied together kind of all the learnings that you had since launching the book in 2019, are you ready yet to tack on the 2.0 version label to ShapeUp? And if so, what are the major upgrades that you see between ShapeUp? 2.0 and 1.0. I think 1.8 is the current version number that you have out there. You know, I actually think that what we have in the in the shaping in real life material is fully is fully 2.0. The distinction between framing and shaping is actually really, really important. Understanding when we are making the case to do something and and trying to pitch people to invest time in something as opposed to making the trade-offs and designing the system of how it's actually going to work those are very different kinds of things we see product managers business people doing what we now call framing but they think it's shaping and then so they're saying here are the 10 reasons why we should do this here are all the customers who are saying they want it so let's go do it And it's like, but wait a minute, like what's the actual concept? Yeah. Right. So this and seeing how, you know, making the case to spend time on something requires going into data, doing different types of research. It's a different kind of work to make the business case as opposed to figure out the technical approach. So that's been very, very fundamental. And there's a lot related to that. In Shape Up, we talked about coming up with a concept and then kind of giving it to presenting it to technical people for them to somehow kind of push back and de-risk it or something like that. And we even talked about this notion of rabbit holes in the pitch. And this actually is the right idea. But in practice, there shouldn't be any rabbit holes in the pitch. If something is a rabbit hole, we should solve it in shaping by doing spikes. We should go deeper into the concreteness in that area to figure out where do we actually hit the wall? Where are the breaking points in this tricky area so that we can understand those things before we make the commitment to do the project? Spiking and shaping is a very, very big thing. We talk about going in and out from shaping sessions into spiking sessions and so on. The fact that shaping is very much about actually looking at alternate ways to do things. Whenever we were shaping at Basecamp, we were always saying, what is the version of this that we could do in six weeks? We were also saying, but what is the two-week version? What is the quick hack version? What's the six-month version? So thinking about alternate versions, option A, option B, option C, with different constraints in order to understand better what the possibilities are. This is something fundamental in shaping that we also teach now as different paths. So what are the parts that we think go into the solution and what are different paths we can take under different constraints? Then when we go into the actual output of shaping, that the output of shaping, it doesn't make sense to call it a pitch. Because a pitch is like a sales pitch, right? But if we've made the time investment, so if we framed it, we understood the business value, we think that it's worth spending some time on, we've shaped it, we've come up with what we think is a viable kind of system design or viable architecture or a viable approach of what to build. Now, what we have is actually something we call the package. We package what was shaped so that it can go into delivery. So packaging means, you know, like it's not just a bunch of scribbles on the wall and only those of us who were there understand what it means, but now it's in a document in a form that's going to survive the passage of time and the changing of hands. So this notion of packaging and then actually choosing the right level of latitude and what to spell out versus what to leave for the team to decide, this is something that happens in packaging that's very much dependent on who we give the work to. So in ShapeUp, there was this impression that there's kind of a right way to write a pitch, that it should have a fat marker sketch and it should have this and it should have that. But actually what goes into the package, the package is what the team needs so that they can be successful in delivery and they can make judgment calls. So it might be that there are things that they need to know that are... much more detailed about how some legacy thing works. Maybe there was some really old code that we had to carefully analyze in the shaping to understand what to do. We should spell out exactly what we learned about that old code in that package if that's going to be relevant. If we actually got all the way down to a very concrete UI concept inside of the shaping and we understood in this particular project, we don't want to have latitude for something else. But this very specific design, this little piece of the design, this little piece should actually be the way that we already defined it versus the other things could change. So this idea of being much more judicious, being much more conscious of what we put into the package so that it is the right thing that's going to help the team to be successful. And then, of course, also the handoff. of this method that we teach for how to enable the team to give some feedback and show what they understand, especially when you have a lot of junior people where they can kind of sketch out the scopes and their implementation approach before kickoff at the beginning of the cycle so that there can be some back and forth between senior and junior to make sure that we're actually aligned and that the team is going to work on the biggest unknowns and the most important pieces first. And they're not going to bump into the, you know, they're not going to bump into the biggest difficulties in the 11th hour at the last minute. So there's quite a few things there. And the word package itself also, I think it fits better the context that you mentioned in the beginning of teams who don't have the luxury to shape multiple competing pitches and then come together to decide. It's the package that goes into delivery next. Yes, exactly. Cool. Before we wrap up, I'd love to hear what's next for you. I know you've been speaking at quite a few conferences lately, business of software, the product con, and you're running more cohorts of the course. Are you a traveling coach and consultant now, or are you planning at any time to go back to building products? Because you have this kind of vague sentence in your bio on your website that says, I'm currently working with a small team to invent the next generation of creative tools for the early stage of engineering and design projects. Do you want to talk about that a bit? Well, what I've understood is that if we lead, or what I believe at least, is that if we lead with new tools, but people don't have the different way of thinking first that nobody's going to value the tools and they're going to say this tool doesn't work. For example, I built together with Bob Mesta and some friends, we built a tool for doing job to be done interview analysis. And it's quite sophisticated. I mean, it's basically producing a kind of embedding where you can figure out kind of the mathematical distance between different stories in the job and stuff like that. It's like, it's an amazing tool. And we use it on all of our on all of our projects now. But if you if you haven't really understood the how to get the these four forces from jobs to be done out of interviews, it's garbage in garbage out. Yeah. And it's kind of like this tool doesn't do anything. And so we we only even give access to the tool to people who are already pretty really well trained in interview technique and then they're like oh wow you know then they understand what it's doing for them and they can value it i think the same thing is true for all the tooling around this stuff so first of all i you know i'm continuing to i have a lot of stuff that's prototype that i use on my own projects but i don't think it's the right time to actually make any of that stuff public um we have a little bit of some prototyping going on some people are using a handoff tool that I built out there in the wild. I'm certainly not thinking myself as a traveling coach. So Katya and I really enjoyed making the course. And what the course has allowed us to do is actually to bring more people in to the new way, kind of the latest thinking and this sort of 2.0 level of ShapeUp. And, but the consulting projects that I'm doing are projects where I go into a team where I would not have been able to give them the answer upfront and where the course doesn't have the answer for them. But there's something harder. There's something, you know, unique or really difficult or something that I don't understand and they don't understand in their circumstance. And then the consulting project is a way to really extend the framework and innovate and like figure out, like really push the edges of what I already know how to explain. So I'm doing one or two of those a year. They're very selective. And I usually embed for about a quarter, you know, with the team. So like three months of, um, kind of part-time but but very hands-on with what's going on in the team and then that's actually been a source of a lot of the new stuff that's coming out so for example i just did a project where we applied framing and shaping and spiking to a marketing team and this was totally different than what a product team does but at the same time it was exactly the same stuff you know what i mean so uh it's really interesting so i'm doing occasional consulting projects to really kind of extend and deep in my understanding of how this can be applied in different tricky contexts. And in the meanwhile, we're continuing to do cohorts of the course. We're doing a few of those per year and that's going really well and we're excited about that. And I would love to do some tooling, but let's see when the time comes and when it fits. Yeah. I'm also, you know, and the other thing is, you know, building software is actually very time consuming. And then you have to maintain and operate what you built and you have to keep all the servers running and you have to keep updating everything to the latest version. And actually the operation side of the software business is it's harder than people think once you actually start to get customers and you have to support stuff. So I think it also could be interesting to see maybe in the future there's a possibility to partner with some people where the tooling side is a little bit of a slightly different business than the teaching and the figuring out the method side. That sounds great. I'll be looking forward to anything that gets released or announced in that direction. Thank you so much, Ryan. This has been a blast. If people want to connect with you, how should they do that? Yeah, so they can find me on Twitter, on LinkedIn, and my website, feltpresence.com, is a great place to start. You'll see that Shaping in a Nutshell video, and that's also a place to see what's happening with Shaping in real life and anything else that's available. Amazing. Thank you so much. All right. Thanks, David. Really enjoyed it. There you have it. I hope you enjoyed the conversation with Ryan as much as I did. If you like this show, it really goes a long way if you leave a favorable review wherever you're listening to this. And if you're interested to find jobs at companies that work with ShapeUp, we've actually set up a dedicated job board at shapers.builders. Yep, that's the domain. So go ahead and check that out if you're interested. But for now, thank you so much for listening and I hope you have a great day.

#1: Today I am speaking with Ryan Singer, former Head of Strategy at Basecamp. Ryan went through nearly every role in the product development stack during his 17-year tenure with the company: from UI design to programming to product management and, most recently, product strategy. In 2019, Ryan formalized the way that Basecamp was working into a framework that other companies could use, resulting in the release of the book "Shape Up – Stop Running in Circles and Ship Work that Matters".

Since then, a lot has happened and many teams have adopted and adapted Shape Up. Ryan, in turn, has taken the learnings from those teams to reshape the framework and decouple it more and more from the specific context of Basecamp – a bootstrapped and stable business with a high share of senior people.

In our conversation, we explore some of the initial reactions to Shape Up, including common criticism of the framework. We then go deeper into the evolution of Shape Up 1.0 into the 2.0 version, which Ryan is now teaching in his course "Shaping in Real Life". You'll probably get the most out of this interview if you're already somewhat familiar with the Shape Up framework. If you want to catch up on context first, check below for some links to get started.

I'm particularly excited to have Ryan on today, because this episode actually kicks off the first season of the Shapers & Builders podcast, where I'll be speaking with teams of all sizes and stages to hear their stories of adopting Shape Up, how and why they've introduced it to their companies, and the tweaks they've made along the way. If you're curious to hear some real-life case studies of teams working with Shape Up, make sure to subscribe and check out the other episodes of the show.

Links:
Ryan's website: feltpresence.com
Ryan on Twitter / LinkedIn: https://twitter.com/rjs | https://www.linkedin.com/in/feltpresence/
Shaping in a nutshell: https://www.youtube.com/watch?v=h_8M23wVjXk
Shape Up book: https://basecamp.com/shapeup
Shaping In Real Life course: https://feltpresence.com/srl/
Ryan & David in 2020 on the Project A podcast: https://insights.project-a.com/from-scrum-to-shape-up-a-tale-of-catharsis/
Shapers & Builders job board: https://www.shapers.builders