How to ship SaaS products fast with Ryan Singer @Shape Up

Hey there, everybody, and welcome to another SaaS Unbound podcast episode. I'm Daniel Tulfout. I'm your host today, joining for a special series where I chat with product experts all about things SaaS. So I'm the head of product at SaaS Group. We are a serial acquirer buying wonderful small SaaS businesses, and we try to take them to the next level. And my guest today is no one other than Ryan Singer, the author of Shape Up and the former head of strategy at Basecamp. Ryan, welcome. Hey, nice to be here. I'm super excited to have you because I have to tell that something around like six years, a little over six years ago, I can say that you kind of changed my life. In a company I was working back then, we were in a transformative phase, I would say, and I stumbled across the ShapeUp e-book. I thought, well, this kind of hits the nail exactly where we need it. It's exactly the problems that we stumbled across when applying Scrum for us. So we went all in and applied ShapeUp and the company is still using it today. And after that, I kind of went on, introduced it to a couple other companies. I actually teach it as a method at a German university right now. Oh, really? So super excited to have the author of that today here in the call and dig a bit deeper into that. Cool. So for those out there that don't already know what ShapeUp is, perhaps never heard of it before, could you give like a, I don't know, three, four minute rundown of what essentially it is and perhaps what's the most, the biggest difference between it and Scrum, for example? Well, I would say the biggest difference is, you know, if Scrum is already working, then everything's fine, you know? But a lot of teams have this experience where when they're really small and it's just the founders, everything... kind of moves fast and projects keep moving forward and decisions get made and projects feel good. But then there comes a point when you start to get a little bit bigger and then you reach for some structure and then you start to realize like everything suddenly got slower, right? And it seems like so much harder to get anything done than before. And what we wanted to do when I was at 37 Signals and we were working on Basecamp all those years, we wanted to kind of keep that feeling. of that fast moving small founding team, even as we got into 10, 20, 30, 40, 50 people, you know, and beyond. And so I would say probably the biggest difference is that Scrum is a little bit more of a kind of a mechanical process of how we get together and the rituals we perform so that we can deal with, you know, sort of. It's a little bit like running a sausage machine, you know? It's like, it's just input going through the steps and getting to the output. And if that's working, then great. But for a lot of teams, it's not actually helping to make the decisions and actually get things done, you know? So if you don't want to just have another two weeks, another two weeks, another two weeks, but you want to really reach the end of things and finish things and feel good that we... built something and delivered it and it does what it needs to do and now we're doing the next thing you know that's that's sort of why we needed to come up with something for ourselves when i was at 37 signals you know that's why we didn't just adopt scrum because we didn't want to just have a lot of meetings and mechanisms but we really wanted to repeatedly finish things and ship things and feel good about the stuff that we were working on so that's kind of the the the story behind it and the the key ideas are First of all, that we always wanted to have an end date for the thing that we were doing. So instead of the never-ending project, we really wanted to say to ourselves, how much time is this thing worth spending on strategically? What's kind of the maximum time where we – this is the point where we're going to release something? And we set as an upper boundary for an individual. effort, you know, at the end of it can't go longer than six weeks before we actually finish something that we can say this works and we're we can walk away from it or we can continue adding on to it. But this piece really works, you know. So first having that kind of time box where this is how long we want to spend. And at the end of this time, we're actually going to finish something. And that kind of leads into this idea of, you know, fixed time and variable scope. So if we're willing to spend six weeks on this thing or if we're willing to spend four weeks on this or whatever it is what can we then do that's actually possible inside of that time where we're going to feel that we spent that time really well so uh the time constraint becomes a design variable right like what can we actually do so then the the so if the first piece is actually setting a time budget where we're going to finish something and then working backwards and the second piece is actually bringing product and engineering together to make trade-offs about the actual solution before we start so that's the work that we call shaping so not just throwing a figma file over and saying now that now the time box starts let's see how to build this when we don't really know what it is but actually working together to get a very clear understanding of this is the idea and these are the you know five six seven major parts and this is how they connect together And this is how we can be confident that this is something we can actually build in, you know, six weeks or less. So that's that shaping work. And then if we have an actual time box for finishing the project, if we've clearly shaped it with product and engineering working together, then that time of building inside of that six weeks or less, that time is where the team can actually. take over more responsibility. So instead of just one ticket after another or asking questions constantly, what does this mean? What does this mean? What do I do here? There's a very clear guidance where the team understands what it is that they're trying to build so they can work much more autonomously and much more fluidly, you know, so they can just kind of have the clarity of what they're trying to do. And then from a management standpoint, there's less babysitting and less micromanagement and much more time to think strategically about what's the important next thing that we need to do. All right. Thanks for that. And I have to say from a product management perspective, I always like that it's a lot more holistic approach to the whole part of shipping something. Whereas I felt that Scrum is a bit of this garbage in, garbage out process or the meat grinder, the sausage grinder, as you said. Yeah. Even worse, you know, Scrum, the other analogy I often use is a paper shredder. Because it takes something that was whole. Maybe you had a whole idea, but then it splits it into all these separate tickets. And you hope that all of these tickets add up again to a whole, right? But in practice, if people are just looking at these individual strips of paper and they don't see the whole picture, then the team isn't able to make good decisions, right? And of course, they're going to be asking all these questions and they're going to have to keep moving backwards instead of forwards when they can't see the whole picture of what it is that they're doing. Yeah. I mean, one of the appeals of Scrum is that it's rather easy to implement because it kind of it focuses on this development team, right? So you can still have the whole company more or less operating at the same level and just do this paper shredding. Whereas if you actually want to implement shape up, I think you have a lot more touch points with, with other boundaries outside of the development team and how you think strategically about product development, how you actually fuel that team with, with an idea or how you ship stuff. And I, I think that often requires a lot more buy-in from the leadership, from other teams, from sales, from marketing, from other stakeholders. And from what I've seen, this is often one of the first barriers that you kind of encounter when trying to move to shape up. That all of a sudden, it's not just something that the dev team does and let them figure out how to build great software, but all of a sudden it changes how you work as a company to a certain extent. Do you have any kind of tips how to... how to move past that stage and take those those stakeholders with you on that transformation what i found is that some shifting to a shape-up style model only really makes sense when it's the stakeholders who are unhappy because if if there's a dev team that is unhappy with scrum you know and the stakeholders don't care how they work well then you do your best to adopt what you can but the place where it really makes a difference is if stakeholders feel why can't we seem to get anything done? You know, why is it that we're moving so slowly when we used to be faster? Like, why, like, why is this project still dragging, you know? And there comes a point where if it's acceptable for projects to keep dragging, then you can continue with Scrum and the team is not going to be happy, but the business will survive, you know? But if you start to come under different time pressures where it's like, look, there's an opportunity that we need to catch. And if we don't finish this by this date, we're going to miss this window of opportunity. Or there's a target that we need to reach in terms of certain, you know, there's a goal that we have in mind. And we're not going to get to that number unless we can ship faster. Unless there's some business pressure that the stakeholders feel, there isn't really a reason to ship faster. Yeah, no, that's true. But it's also up to the, or in most cases, I believe, up to the CTO, for example, to kind of figure out that there's a, a better way to do so so i think a lot of a lot of companies just accept that this is as good as it gets you know we're a 10 year old company we're just slow it is as it is we've got 2 000 user stories in the backlog and we ship a new column here and a new tooltip there and that's that's about it it's the nature of product um i think this eye-opening moment of well we actually don't have to do that like we we can decide to do it differently that that needs somehow to happen Yeah, of course, you need to have an aha moment where you realize that your neighbor is faster than you are. But the other thing is, if there is a reason to move faster, if it really feels like, guys, this isn't good enough at a leadership level, if it feels like we can't keep going slow like this, then it's true, actually, product and engineering have to face each other and decide that they're going to work together to solve this. Because if it's just engineering leading it, you still have to figure out, like, how are we actually, how are we building the right thing, you know? Because the shaping work is about bringing together, this is the thing we're trying to accomplish. This is the business context we're in. This is the time we have. Now what's technically possible, you know? And usually what you see is a common anti-pattern is that sometimes you'll see product tries to adopt it, but then the product is just writing all of their wishes and dreams about what this feature is going to do. And they don't get the reality check of what's actually possible or. you know until they finally give it to the engineering team and if that only happens at kickoff that's too late right and and if the engineering team doesn't have a cooperation with product then you're not going to be able to make trade-offs right because you're not going to be able to actually narrow down in on what the problem really is and what is actually important for us to release and what problem are we trying to solve here now that makes sense yeah so the the second kind of barrier that i and i did encounter that back then with my with my old team as well is that it now shifts a lot of the creative work, the accountability and responsibility from outside of the dev process to now involve the developers as well. So it's a lot more collaborative. The scope is a lot more open and everyone has to be part of that journey and have to invest themselves in that to make it happen. And I think that requires a lot of A lot of maturity from a team. And if you're coming from a team that now for the past five years have received acceptance criteria and mockups of any possible state in Figma screens and are trimmed to just take all the boxes, get your definition of done, finished, and then move on to the next ticket. Moving past that to, this is a rough shape. This is the idea that we have. These are the outcomes we're after. You now have six weeks together with the rest of the team to figure out how to get us there. A lot of team members are super excited about that, but then quickly frustrated that it's not as easy as it sounds and not as glorious as it sounds, that there's a ton of work actually required to get it done. How did this happen for Basecamp back then? And did you encounter similar issues with with other teams that you've coached since then this is the most under misunderstood part of shape up so sometimes people read the book and then they imagine okay so i'm gonna have a team and i'm gonna give the team six weeks and i'm just gonna give them an outcome and they're gonna figure out how to do it and we're gonna call that fixed time variable scope fixed time you get six weeks variable scope figure out how to make it happen this is cruel this is terrible to put a team under that kind of a pressure to say we don't know how but you're going to somehow figure it out the shaping work means that before we actually kick off a time box that we have a clear answer of what we're building and this is very often overlooked and usually it happens because the product teams try to shape in isolation separate from the engineering teams And the product teams very often, they give more like a business case. And here's the outcome we need. And here's the reason why we're doing this. But because they're not working together with the engineers, they don't get down to here's actually the concept of we're going to click this. This processing step is going to happen. Then we're going to see this. And then you're going to navigate here. That's the shaping work that actually happens. When we do that shaping work before kickoff. where we actually figure out this is the concept we're going to go build, everybody has more clarity, not less. So this actually, the shaping work creates more clarity for the team about what it is that they're doing. It's not taking away clarity. And then the thing is, there is another aspect to this, which is when we do the shaping work, we look at the team that's going to take responsibility for this work. And the amount of detail that we include in the shaping work is like a dial that we can tune to the team that we have. If we have a more junior team, they are going to be more successful and they're going to learn more if we give them more direction. So if we are more specific in the shaping work and it's leaning more in the direction of. actually, this is how I want you to implement it also. For someone who's very junior, they're going to be like, oh, thank you. Now I have some clear guidance about how to do this. On the other hand, if you did that with someone who was more senior, they'd say, why are you telling me how to do this? I'm a professional, right? So the senior is going to want more creative latitude versus the junior is going to want more direction. But it's not going to be the same thing project after project, of course, because people are also learning and growing along the way, you know. So if we have very senior people then on the team, then what's going to happen more natural is that we include them in that shaping work up front. And then we leave more space for them to figure out the implementation details along the way. But if it's more junior team, then we're going to be much more clear in the direction that we're giving up front. Yeah, I like the image of the this mental model of the dial. I always explained it that it's a bit of a balancing act in shaping to leave some of the details to be figured out later because you haven't really seen it live, right? You're not something just, you know, are apparent that this works better than something else after like three weeks of actually seeing it in the finished product. It is like building a house though, you know, like you don't want to be redoing the foundation and walls three weeks into a project. So we need to have certain amount of confidence and understanding about what we're building before we start so we're not throwing work away because that's bad for everybody. And that's part of why we have these never-ending projects, you know, because we didn't actually get serious enough about what is it that we're really building before we started the project. So in the shaping work, we should have a lot of clarity, actually, around these are the main parts. This is the basic architecture. This is the basic flow of data that we need in order for this thing to do what it needs to do. And then the implementation detail is more that there's a thousand different ways to make the small things happen, you know. And, of course, we don't have to decide on the color of the kitchen tile when we first start building the house. But we do need to know, you know, where are the water pipes going to be where the kitchen is, right? There are certain things that we really should know in advance and we can know in advance. We're not inventing some completely new mysterious technology here in most of the business work, you know, the business problems we're solving when we're building software. Yeah, I think it's one of the misconceptions of agile that is kind of this. You don't need to plan. You just iterate in code and see what comes up with that. But I believe there's a difference in a minimal viable product and you need to have kind of these minimal viable prototypes before that, you know, help you validate stuff and shape stuff before you actually write the code. So that, you know, once you give it to a team as a how does matter how rough the shape is. it's validated at that point you know that the the whole thing is most likely gonna gonna work and not going to be changed after two weeks again because you figured out that whole architecture wasn't as good to begin with. Yes, this is exactly the kind of thing that we question in the shaping phase. So before kickoff when we're shaping the work this is the time to have the critical eye and say how can I know that that's going to work and if we don't know if it's something we've never done before we can do some spikes. We can do some quick experiments to verify that the existing system works the way that we think or this API that we've never used works the way that we think. There are certain big questions that we can answer. There's a lot of unknowns that we can eliminate. When we actually kick off a cycle and make a commitment to each other that we're going to ship this thing after four weeks or six weeks, we should actually be looking at some. Some things that we've done before. I know how to code. I know how a database works. I know how to make routes. I know how to build front end. And this isn't rocket science. If we are more careful to be clear about what it is that we're doing, then we can actually make a commitment and we can really also succeed. We can repeatedly ship things. I tell you, we did it for 17 years. In the 17 years I was there at 37signals, we kept saying, this is what we're going to build, and then we shipped it. And then we said, this is what we're going to build, and then we shipped it. And we did it again and again because it wasn't rocket science. And I see a lot of teams that I work with today doing the exact same thing now. Great, great. Yeah, that resonates very well with me. So shifting gears here a little, something that kind of is everywhere right now is AI. And I think it's... It's fair to say that it kind of disrupts most of the industries right now, including development, including product management, SARS. There's even the notion like will SARS exist in the future or will we just have AI agents? How do you see AI affecting that kind of process or how you, even like apart from ShapeUp, how you approach software development? So there's different phases. You know, if we are shaping a project, if we're trying to understand what's the approach. So let's say we need to build, we need to get a basic iPhone app running for something that's already a working web service. And let's say we don't have experience building an iPhone app for this. So there's going to be a lot of unknowns when we're first concepting, like what is the first project going to look like? Are we going to use WebViews? Are we going to be doing everything natively? How are we going to handle certain kind of notification flows? There's going to be certain unknowns that we have. I've been finding that AI is a really great kind of speed up for getting, seeing kind of what kind of alternatives we have for something, you know? So if I want to find out like three different ways that I could build something, or if I know one API for doing something and I want to know if there's another way, you know, even with web development, can Tailwind do this thing or are we going to have to do custom work for that? Do you know what I mean? These little questions. They get answered so quickly with AI. So that's a big speed up when it comes to kind of filling in our gaps about what is possible and what technology we might reach for when we're trying to concept something. And then, of course, like when we're doing implementation work, I think you see probably most of the developers, you know, are using AI today instead of formally going to Stack Overflow or whatever. Right. And I can't believe, I mean, how fast I have Grok open these days. I mean, I'm just, it's incredible how fast I can get an answer to how does this thing work or how do I do this specific thing? I think what we see is that there's a lot of implementation detail steps that everyone is experiencing a big speed up with AI. Just how do I get this little thing to work the way I want it to work type questions. And as I mentioned, there is a bigger ability to sort of see big options of what technology might I reach for or, I mean. Technology is a more of a, it's even like, given this thing that I need to do, what APIs might I look at? Or, you know, how might I do this on this platform or whatever? So in the shaping phase that can be helpful, I don't think we've yet seen what I would call any meaningful disruption. I think so far what we're seeing is all in the category of speed up. The one story that I heard recently that could start to feel a little bit like disruption is I had a friend who is a back-end developer. And his team had the problem a lot of teams have where the front end developers are too busy and they couldn't, they would have to wait a month if they wanted to make the front end change they needed. And so they just asked, they just asked my friend who's a back end developer, like, hey, can you just, can you just figure this out? And because he had AI, he had never built, it was some complicated thing in Angular, you know, and he had never built in that before, but because of the AI, he was able to very quickly work his way through and in three hours get the change done. you know and that's a thing where it starts to affect a little bit how you look at oh what specialties do we need and how do we hire people and stuff like that one one question mark in my mind right now is if we if we have too much of that what does it mean in terms of our ability to understand the code in the future and because there's a loop back if we can't understand how the existing system works shaping gets harder You know, if we're talking about making a change and we're considering investing time in a project, but we don't understand how the existing code works, then there's all kinds of ticking time bombs in terms of unknowns there, right? It seems like we could just make this change, but now we're going to go and we're going to, you know, rip open the walls and you find out that the electricity isn't running through the wall the way that you thought it was, you know? So I think that's going to be a very interesting – I'm watching that quite carefully, actually. I think that there's a big difference between give me a quicker answer to this implementation detail versus there's an element of design in a software system where if we don't have an understanding of how the system is designed in terms of what's wired to what and what we can change and not change, you know, we might have a – Have a challenging period where the code runs, but we don't understand it. You know what I mean? And I could see that interesting producing some challenges, but who knows, you know, I mean, with cloud code, for example, it's now looking at your code base and answering questions, you know? So I think there's also a little bit of support coming from that side of maybe we'll be able to introspect more in the code to understand how it works. But for now, I'm betting on, on having clear design and having some. meaningful ability, some sense of meaning when you look at the code base and say, I understand what this does and where I can make changes. I think that's still very important. Yeah, there's the risk of turning your code base into a black box. You know how to operate it and you know how to add new stuff with AI to it, but you might not understand the full thing anymore and that risk is growing. I can see that. You know, there's a lot of AI assistance happening in computer-aided engineering, for example, in, like, chip layouts and stuff like that. But I think those things, to my understanding, those things fall a little bit more under optimization problems and less architecture problems, you know? And I learned from, like, from my friend Bob Mesta that there's a difference in old-school engineering thinking, like, going back to Gucci, that, like, there's a difference between system design and parameter design. You know, system design is, like... What are the moving parts? How does this thing actually work as a system? And parameter design is like the million different little things that we can tune to how to actually make it work the most efficient way. Yeah, that makes sense. And I think from a hiring perspective, the minimal effect that we're seeing right now is that it doesn't matter anymore if you're super experienced in a specific framework. Like you're not hiring an Angular. developer anymore you need someone that is a experienced developer and ideally with like one kind of framework but it's so easy right now with ai to kind of allow that developer to translate the experience they had with angular to react for example it's becoming more framework agnostic so i think that's that's that is becoming true in in the in the downhill phase and the implementation so if you're inside of a time box and something was shaped You're going to be able to get answers. But the thing is still the question of is this possible and how hard is it? How costly is it still requires knowledge of the framework in theory, what you can do and react and what you can do in Angular are similar. But in practice, they have different cost profiles for different different building different things, you know, because because they're architected differently. So they for the for projects to go well. The key difference is that if you have someone who understands the framework in the shaping phase saying, look, we're going to use this API and connect to this and connect to that and connect to that. And I'm telling you this and this, these things, they connect and they work because I understand that framework, you know. And then you can say with certainty, like, this is possible in this amount of time because I understand how the Lego blocks click together. That certainty you won't have unless you actually understand the tooling. Oh, that's true. That's true. So if someone else knows that it's possible and they tell you, I know this is possible and it's true, but then you yourself don't know the framework, you can then navigate inside of that possibility space. You know what I mean? You can take shortcuts via the AI to get to the answer, but somebody still has to know that it's possible in order to make a bet that is going to go well, right? In order for that, to make that commitment of like, this is actually going to ship after X weeks, you need to. to actually know that that's possible going in yeah it doesn't free you from having having the expertise at least at the team yeah but it does it does move the expertise a little bit more leftward yeah all right coming back to ai in the actual shaping phase so you mentioned that it's about speed and giving options so if you bring this to this model of of the double diamond in design thinking i think what what ai does for us is that it makes the kind of the diamonds steeper. So you're basically in the same timeframe. Now you can explore a ton more options than the problem space to figure this out. And it's, you know, then allowing to validate this a lot faster and then solution space, you know, it's not that you can prototype three solutions in two weeks, but now you could 15, 15 in a week if you wanted to, at least from a, you know, try it out perspective and see it in how does it look like. So I think it opens up this solution space a ton more and helps you not go with the first hunch or the second hunch, but allow more options on the table. You know, what I see is most teams are stuck on the first idea. It's very rare that you even see two ideas. So I would not bet on 15 ideas. I would say the usual problem is that somebody has a solution in mind and everyone gets stuck and we go in circles on the first idea, you know, for much too long. If we can at least ask the question of are there two other alternative paths we should be thinking about and just look at two other options, that already would be a very meaningful change. You know, the other thing is, I think I think our our ability to explore all kinds of alternatives is is usually a sign of an unhealthy team. If a team is always exploring and exploring and researching and new questions, and now we need to look into this and now we need to look into that. What it usually means from the leadership perspective is nothing gets done. Nobody's making decisions. Everyone only has more questions and more unknowns, and we're not converging to answers. So usually what really you see in a team that's shaping well is you have a few people who actually have a lot of experience. So whoever are the most senior people on the team, those are the ones in the shaping session together. So imagine you have the most senior engineering person. The most senior product person who understands the business imperatives and what the customer cares about. And then maybe somebody from the more experienced side, from the user experience side. The people who are the most senior, if they come together, the shaping session is going to go well if they already have a very rich mental library of, like, these are the things that we know how to do. These are the things that are possible. And then given this problem, you know. What might we be able to do? And then whiteboarding an idea. You know, that's what a good shaping session looks like. If we have no idea what to do and we're all, like, kind of in the AI asking questions, this would be kind of, I would say, like a negative indicator. On the other hand, if we have an idea and we just feel like, oh, but could we do that with WebViews? Oh, we haven't done that before. Let me just get a sense of, like, what that would look like and then quickly ask the AI. you know, how does doing this in WebViews look like in this framework, you know, then we might be able to quickly determine, like, is this an attractive option that we want to look closer at, or do we just stick with the path that we're on, you know? So I would think more like a quick check to see if there's an alternate path, but not so much getting lost into this research because we don't have time for that. Usually there just simply isn't time for that if we're trying to really move forward and get a project ready for a team to go build and ship. Yeah, that's super interesting to me because there seems to be this ideal corridor between not having enough options. So if you just always go with the first idea or very solution driven, that's not good. But also then if you go at the other end of the spectrum and you're kind of, as you say, you're exploring, exploring and you spend all your time in discovery and you're not ready to make a commitment and you want one more data point and one more experiment, then you... never actually shipping anything. So there's this corridor in between where you want to land. This is a big frustration in a lot of teams today is also that the product teams are just doing discovery and discovery and discovery. And it's like, hey, when are we going to go build something? You know, that's usually what helps is to do a certain amount of work to get clear on. Is this a real problem? Why does this present an opportunity now for the business? So we've got five different feature ideas. There's the thing that sales wants. There's the idea the CEO had in the shower today. All these things are competing. You know, where is the struggle attached to this? Which one of these things actually is presenting a problem for customers or prospective customers today? Weighing sort of the problem side. and the business impact of ideas before we even get into the solution side we call this framing in shaping in real life as opposed to shaping framing the problem and the opportunity so if we can get more clear that this is the important problem to work on and we have a sense of like if we could ship something in six weeks that scratches that itch that would really feel like a success you know then anything that we can come up with on the solution side that solves the problem is a win right yeah and it's actually more of the wrestling and narrowing down the problem that helps us to do that than exploring the million solution options it's usually a lack of pushing hard enough on the problem true and i think what plays a big role here is that these the the six week cycle in shape up is based a lot on giving giving the teams like space and room to focus on this one thing or on a very few things which reminds me of this, I think it was a quote by Jack Wells around strategy. You know, strategy is very straightforward. You just, you know, you focus on a specific direction, then you execute like hell, which I think works very well here as well. At some point, it's not about having the perfect direction, the absolute perfect solution, but having something that we all believe in that's good enough, that has some kind of data backing, and then just actually ship it, bring it to the people, and then kind of... move on from there rather than iterating to perfect and never get actually anything done. All right. So, but this kind of focus, and it's a good segue to the next question here, is something that a lot of development teams often complain about lacking. So they say, well, we can call it whatever you want. We can call it shape up, we can call it cycle, sprint, we can do a feature freeze, whatever we do. Usually, we won't get that done. There will be bugs, there will be requests here and there, there's maintenance stuff, keep the lights on stuff. It sounds like a luxury being able to focus for six weeks on something. I did implement a couple of workarounds throughout the years. All of them are kind of working somehow, but I wouldn't call them the best solution if there is any. What's your take on that? So, if there is all kinds of work going on and engineers have to choose, do I fix this bug today or do I continue on this never-ending infrastructure project or am I available to work on this feature? Oh, I thought I was available to work on the feature, but now someone is asking me about a bug. If you're in this world, it means that no one at the leadership level is making trade-offs. It's simple. You have a budget. You have a certain amount of dollars or euros in your bank account. And if you wanted to figure out, if you wanted to not be spent thoughtlessly, then you have to make a plan of how much am I spending on what, you know? And it's the same thing with capacity. We have a certain amount of people. We have a certain amount of hours. What are we going to spend it on? So are these bugs truly urgent and critical and necessary? Which ones are truly urgent and critical and necessary? Very often that conversation isn't happening. Someone reports a bug. Someone says bugs are bad. It goes into a backlog. And then somebody says, listen, we need to solve this bug. And nobody's pushing back against it to say, yeah, but what are all the other things that we also need to be doing right now? So those trade-offs need to be happening. There are so many never-ending infrastructure projects where the engineering team is left alone to do those or big refactorings. And no one is asking the engineering team, please justify this expense from the business perspective. It's possible. And when we insist on that, what we want to have is when the executives come together, everyone should be able to say, what are we spending time on? And there's a discussion and we say, that feels like a way, that's a good way to spend time. And let's see, you know, it's we're going to be done on this date and let's come back together and then see when we're done. That's what like, that's what a healthy company looks like. And absolutely. It's purely a matter of. Making the trade-off of saying what is actually important here. If sales need something to sell and they don't have anything new to sell because engineering has been busy with a never-ending refactoring, that's not a good trade-off, right? So those are the kinds of, that's also what I mean that the decision about how we use our time and our capacity and what problem is actually important right now, that's where so much of the gains are. One thing that's good to mention here is that ShapeUp, All the kind of shape-up style practices are about projects. And there is a class of work which is truly, truly urgent things because there is a stakeholder on the other end and they cannot tolerate waiting. Do you know there's a there's a customer is literally experiencing data loss right now or they can't access it or something that customers rely on that they paid for is seriously broken right now. Like there are things that that need to be solved. If they truly have urgency attached to them, then that belongs in a ticket. Right. Tickets are excellent for. urgent things where we need to know where are they in the pipeline because the clock is ticking but usually what happens is we make anything that's a bug or something we don't like we put it into a ticket and now it's mixed together with the actually urgent things you know these are totally different things so if we have a clear if we have dedicated capacity for truly urgent things and we have dedicated capacity for projects then we make a business decision about How do we use that project, Tom? And what is the thing that needs to happen most for the business in the next quarter or in the next half a year or whatever? That's a decision that we actively make. I love that you opened the conversation with everyone but focused on the business value and having kind of a negotiation on the business value and some, I would say, positive friction. One of the methods that a lot of people companies solve this issue that I don't like is to just assign a quota to stuff. Like 50% of the team are working on features, 30% on maintenance, 20% on bugs. And that's about it. We negotiated this once for the year and then we don't care anymore. I think it doesn't take into account like what is in those backlog and perhaps it makes sense to at that specific moment to invest a little more into that feature because there's a higher business value attached or to invest a little more into that infrastructure project. Because it's a big enabler for the future. But people want to get around having these hard conversations and these negotiations by just attaching a quota to a bucket and call it a day. So I'm not a huge fan of those. Yeah, well, I would say that there are certain things that the business learns are ongoing and they needed an ongoing share of capacity. So there will be, probably it doesn't make sense to renegotiate every quarter. how much engineering capacity goes towards like emerging urgent issues. Do you know what I mean? Like there, I mean, there should be someone who kind of has a team or, or we have a rotation depending on our size, but there, of course we need to kind of gradually update that, but that's, that's not something where we want to constantly be saying, do we do a project or do we solve urgent issues? Cause you, it's just like having support staff. You need to have a certain amount of support staff on hand. for the amount of customers that you have at a given moment right yeah so i think category there yeah but it's but it's the main category because most people are getting pulled away on bugs this thing broke this thing isn't doing what it should like these kinds of things you know i mean these this is a big big category so one category is the is the is the is the the the sort of emerging tickets the reactive work and then the other big one is the um is the infrastructure work Is the stuff which is the never ending behind the scenes thing that nobody understands what it is. And that's the thing where I agree with you there that that's very healthy to have that in the push and pull with the with the customer facing change. There should be active business trade offs there. Yeah, that makes sense. All right, we're approaching the end of our conversation. I honestly could go on this for hours. There's so many things. I've been holding back so we could use the time. Same here, exactly. One thing that I wanted to ask you is that I'm not sure if there have been revisions to the ShapeUp eBook in the past years or if it is... like more or less kind of the same that it was six years ago when when published first time or six seven years something around that did at least for you shape up evolve in the past years is there anything that you would now do differently or where you you know um you have a have a perhaps a better idea now the the thing that really is clear to me now is how unique how unique 37 signals is you know the makers of base camp we have every designer codes this is already a big change every designer codes and uh not only just i don't mean just html css i mean the app is running locally and they're editing the views in the live running app you know the the the the engineering team is overwhelmingly senior you know everyone has a very long history of depth in the same framework together i mean there's a lot of things there founders are hands-on in almost Every major project decision, the decision to green light a project, a founder has looked at it, you know, so there's a lot of things that are unique there that I didn't appreciate at the time. And these things don't actually prevent anyone from doing shape up, but they can create a lot of misunderstandings if you only go by the book. Because the book kind of makes it seem like, well, you just shape it, you give it to the team and no problem, right? But for most, for most companies, there is a pretty significant. separation between the product people and engineering, between the designers and engineering. So a lot of what we teach in, for example, in Shaping in Real Life, this course that we've been giving the last couple of years, is about how to actually bring product and engineering together in shaping sessions and how do they actually interact to understand what's possible and make decisions and come to some clear picture. of this is what we're going to go build right so that it's it's it's in the book but it's kind of it's sort of assumed you know all of that interaction the other thing that's a big difference is base camp was you know they they there was the renaming of third so i keep using uh both names but it was a bootstrapped extremely extremely profitable company that didn't have any outside pressures at all zero no target to reach You know, no danger of not having enough revenue or anything like that. No sales team, right? No marketing team even. So what it meant was that there was a great luxury of time to sort of anything could be next, right? There isn't this need to compete and align on who gets the thing that they want next, you know, out of developer's time. And so in the book, what you'll see is it suggests that there's this shaping work. And then after the shaping, there's betting. And the thing is that at Basecamp, we could tolerate, while I was there, we could tolerate shaping different ideas but not actually building all of them. For most teams, it's a big time pressure to even manage to shape one thing well. You know, this idea that you're going to shape multiple things and only do one of them, that's not realistic in most teams. So for most teams, the place where you're looking at a lot of different options is at this framing step, which also we didn't have a word for at the time of the book. The framing step of like which problem is the most pressing, which opportunity is the most important right now. And out of those different problems and opportunities, getting alignment on like this is the thing we want to invest our time toward yet, even though we don't yet know if we have a solution. Right. But this is the thing we want to shape next. So working from a leadership level on this is the thing that seems important next. Let's see if we can solve that. Then bringing a team together. Two, three people to try and shape that, you know, because the shaping time is actually expensive. You have your most senior people coming together. Right. And then and then only after it's shaped, then kind of having rather than comparing it to a whole bunch of other ideas, it's more like a green light moment. Like we already wanted to do this. We already aligned on this. Is this something clear enough? Does it make sense enough? Do we believe that it's going to be possible? you know so that's that's one shift you know so this this decision about what's next happens more at the framing level more at the problem selection business opportunity level and and the the actual solutioning in the shaping is more downstream from that and we just want to have a green light to continue that's a that's also a shift all right and i think it's kind of an inherent issue with or misunderstanding of frameworks I believe frameworks or books and methods, whatever you want to call them, they have the value of compressing a lifetime of experience into something you can read in a couple of hours. But you need to be aware of the context. You need to be aware of how did this develop in the first place and why did it make sense there? And does this apply to yourself? So you can then extrapolate those experiences to your own situation. but taking any kind of framework just as it is and applied by the book will most likely fail, similar to why a lot of companies fail with Scrum. It's usually a good idea to give it a trial run for a couple of iterations as it was intended and see does it actually make sense for you and then perhaps tailor something back to how it works for you. But yeah, you need to be aware of that. And I really appreciate that you can see the differences of what you find in the Wild West right now and what was perhaps a luxury in your time at Basecamp. Yeah, what I see working really well is when teams establish some common language, because they usually don't have common language that goes across product and engineering. So we can talk about framing and shaping and kicking off with scopes and all these different things, the uphill and downhill work. We can have a lot of common language that links us together for the whole life cycle of work that we need to do for a project to go well. And then the actual work of framing and shaping, that's actually skill development. Those are skills to learn, you know, because product person maybe knows how to write a PRD or the designer can make a Figma file, but shaping is a different kind of work, right? And then that's something that we learn through doing projects together. All right. I think that's a good word on ending. ending our session. I so much appreciate this conversation. It was great to have you here. Of course, we do a follow-up sometimes. Yeah, let's do that. I feel like we barely scratched the surface, you know? So I would be happy to do it. Let's do it again sometime. All right. So much appreciated. Thank you, Ryan, and have a wonderful day. All right. Thanks a lot. You too. Thanks. Bye.

saas.unbound is a podcast for and about founders who are working on scaling inspiring products that people love, brought to you by https://saas.group/, a serial acquirer of B2B SaaS companies. 

In episode #9 of season 5, Daniel Thulfaut talks with Ryan Singer,  author of Shape Up Methodology, an approach to product development through clearly defined, focused projects.

--------------Episode's Chapters----------------
01:31 Explaining Shape Up vs. Scrum
06:21 Implementing Shape Up in Teams
11:36 Challenges and Misconceptions
19:43 AI's Impact on Software Development
26:41 Understanding Framework Costs and Expertise
28:20 AI in the Shaping Phase
29:57 Exploring Alternatives and Team Dynamics
32:09 Balancing Discovery and Delivery
35:58 Making Trade-offs and Prioritizing Work
42:23 Shape Up Evolution and Unique Contexts

Ryan - https://www.linkedin.com/in/feltpresence/
Shape Up - https://basecamp.com/shapeup


Subscribe to our channel to be the first to see the interviews that we publish twice a week - https://www.youtube.com/@saas-group 

Stay up to date: 
Twitter: https://twitter.com/SaaS_group 
LinkedIn: https://www.linkedin.com/company/14790796