How to shape amazing SaaS products? with Ryan Singer, author of "Shape Up"

Hey there! Welcome to SaaS Unbound brought to you by SaaS Group. I'm your host and then Dana and this is the show where we chat with inspiring founders and experts to get an inside scoop on how they made their business success. And today with me and I'm super excited about it is Ryan Singer, a member of the original Basecamp team, the author of Shape Up Methodology and a book that has changed the way many software teams talk about shaping their products. And since 2021, the founder of Felt Presence helping product teams regain the thrill of building, which sounds really exciting. So welcome to the show, Ren. Thanks. Nice to be here. Sure thing. I mean, I honestly always make such fuss about just keeping SaaS inbound for the SaaS founders. But when we met in a little bit of a context here, we met at the CodeTalks conference in Hamburg a month ago. And I thought, oh, my God, that's just perfect, you know, because I interviewed David, I interviewed Jason a couple of times. And just having you here would make a perfect sense, just like round up this entire experience. So, yes, super excited to have you as a special guest here. But maybe I don't know, this is a SaaS podcast and I'm pretty sure. pretty much everyone knows what shape up is uh in the audience but maybe we can dig into it a little bit just maybe a couple of minutes what does shape up sure um so yeah the question is actually um how do we deal with different problems we get into when there's a disconnect between the product and engineering between the designers and the engineering between what business is trying to do and what the technical people know how to do you know when we are in a technical business we have to actually figure out how to connect all those things so that we can turn an idea into something that actually gets built and it all happens in the amount of time that we actually strategically intend to spend instead of just having you know never-ending projects and what's the status on this and why isn't this finished yet and why did it turn out to be more complicated than we thought and That's not the thing that I thought we were building. That's not what I meant when we talked about it earlier, right? All these kind of problems. And if you look at the way that people tend to work today, it's a lot of agile and scrum and tickets and stuff like that. And those things aren't necessarily bad in themselves. Tickets are actually great for dealing with bugs and urgent small issues from customers and stuff like that. But when it comes to doing project work, a lot of teams are finding out that when you are only assigning tickets to people, that nobody can really see kind of the bigger picture of how it all holds together. So it's really hard to actually understand all the trade-offs involved and to make judgments and decisions along the way. And people kind of get lost. And there's a lot of problems there. The other thing, too, is that... A lot of teams are just kind of diving into the work. They're just going straight into from talking about something to trying to start building it. Or they're going from some kind of a beautiful kind of piece of artwork, you know, like a Figma file where there's a million perfectly drawn screens. And it looks like we know what to do when we look at those beautiful drawings, but we don't actually know what it means in terms of the technical solution and all the trade-offs and the architecture and what it is that we're actually going to go. and build you know and a lot of that stuff that's actually in the first figma file or the first conversation about we're going to build has to get thrown out or changed along the way so these are kind of the things that motivate people to start to think like oh maybe the way that we're working you know could be better and those are the kind of things that we over the you know i was at base camp you mentioned with jason and david for 17 years and we had this amazing luxury of being able to trial and error different ways of working you know with a really small team and a team also you know jason and david the culture they created was there was just this urgency to always be making progress and moving forward you know so if we were like working on something and then throwing it all away and then starting over again or or we were supposed to be done and actually nothing moved as far as it was supposed to. Like these kinds of things really felt like bugs that like shouldn't be happening. So there was this long trial and error process. And what eventually what we came up to was some kind of practices, I could say, that are missing in a lot of other teams that are just following agile rituals and scrum rituals. And then ShapeUp was my kind of attempt to formalize all of that and create a kind of framework so that other people could learn. what it was that we figured out and what it was that we were doing differently to solve all these problems. Awesome. All right. Well, I mean, during our first interview with Jason, I kind of interrogated him a little bit like on why is it six weeks and why are there like two people, a designer and a programmer and why is this and why that? And I was like, okay, I'm asking too many questions. I should probably read the book. Well, it's interesting too, because it turns out that a lot of those very specific things like the number six, you know, or that the team has one designer and one programmer. One of the things that I've learned from working with more teams in the last few years has been that those very specific things are actually more unique to Basecamp than the universals. So the more universal thing is choosing that fixed time that we want to spend instead of just kind of saying however long it takes, you know, instead of going two weeks sprint after two weeks sprint after two weeks sprint and not seeing where the end is. having that decision upfront that we are going to spend, we're only interested as a business in investing, you know, four weeks into this project or six weeks into this project or whatever that number is. And then when we have that kind of fixed time, then before we actually kick off the project, before anybody has tickets, before the programmers actually start working on it, asking ourselves like, what is an architecture? for this concept what is the idea that we can actually do inside of that amount of time you know so the example i've been using a lot lately is like if we're going to build a house we have a certain amount of money that we can actually spend on the house there is a physical limit to what's possible because we only have so much budget right and so no matter whether we want you know if we want the five bedroom mansion like the budget says otherwise so then we have to say like do we want do we want the three bedrooms and two baths in maybe a location that's cheaper to build on? Or are we willing to have a much better, more central location, but then we have to have less space and we're just going to have a one bedroom, but in the really hot location that everyone wants to be in. So these are the kinds of trade-offs that happen in what we call the shaping phase. And it's really more about making those big decisions earlier on. before we kick off the project and having more clarity about what we're getting into and then knowing that that's going to fit into the amount of time that we actually want to spend so that we can ship on time and then move on to something else absolutely i think that was my like people are talking about the aha moment in the like software tools but that was my aha moment in the book i was like oh that's an interesting way to like to look at it like for me even uh because I guess in a way you can you can apply this shaping thing into like different areas of work. Right. And for me, it's like I want to create this piece of content. Right. And how much time do I have for it? And like, what can I do in a week? Right. Is it going to be absolutely perfect in a week or do I have to put in more research? But another one was it was just kind of funny for me when I got to the the drawing thing and uh um i think it was on one of your podcasts as well where you showed uh like a prototype that jason did of one of the features and it was just like doodling uh it doesn't look professional it doesn't look serious yeah right and i remembered my first job ever i guess i it was oh my god like like right after the first year of university And I was working at a software company as a marketer, but I was asking like so many questions and they're like, well, you're annoying. So there is there is another annoying person, but he wants to build something. He's a programmer. So you should you should you guys should work together. And he just explained to me, like, I want to build that and I want to build this and I like you're going to be my marketer slash product manager or like whatever it takes, you know, to to actually like engineer the sequence of like what customer could go through and he's like i don't have time to look at it and we're going to an investor next week uh and i didn't know any better like it was my first experience ever to like engineer something and this is exactly what i showed up with at this fancy restaurant with this big guy investor i just pulled two a force with like doodles awesome And he was like, what in the world is that? Because no one shows up like this, right? It was the world of like big, fancy PowerPoint presentations. And then when we actually looked at it and when he went through it, he was like, I understood more from this than from any other presentation that was, you know, presented to me in the last year. And when it got to this point at the book, it was like, okay. So I was kind of shaping it up back then in 2011. Totally. And I think that's why those rough drawings are such a good fit at that phase, because it's more about, like, is this an idea that actually works? Do you know what I mean? And it's not about, like, we can make the polished PowerPoint presentations if we need to go sell something to somebody and, like, we can do that whole dog and pony show. But if it's about the actual idea, you know, then this is a different moment, you know, in the phase of creating something. There's like if you are a developer who's making doing a real estate project and you're making an apartment building, you have like the very fancy, perfect 3D renders that you can almost like see into the future and see the building that's standing there. And that's what they use when they're trying to get people to to buy the condo units in advance, you know. But when you are still trying to figure out as the architects, like what this thing should be, then you're not going to do like a precise, perfect 3D rendering just to get a feel for this, whether this idea is the right idea or not. You know, you're going to do those really rough sketches. And then when you're really sure that this is the right idea and you're investing in it and then you need to make it happen and get other people on board, then maybe some more beautiful drawings might be the right tool, but it's not for that phase of shaping what this thing actually is. Yeah, yeah, absolutely. Completely agree with you. And I just wanted to come back to something that you said that over, you know, over the last few years, since you have this shaping in real life thing that you're doing, you mentioned that, you know, ShapeHub is perfect for companies like Basecamp. And again, that was something that I've heard in one of your podcast episodes, that it's... very unique for bootstrap companies. And I started thinking like why being bootstrapped is such a crucial point to doing what you're doing and to make it work as you know, Basecamp does it. So and it's also very fascinating for me because like we mostly buy bootstrap companies, right? And some of them Ah, yes. We love the methodology and a few said that, you know, Jason's books really inspired them to build their companies in the first place. So like the entire culture, right? And then everything that Basecamp does, you know, is really inspiring for a lot of founders. But now you're saying that maybe it only works for bootstrap companies. So what is the difference? I'm glad you raised that. So I've been very pleasantly surprised. to find out that actually shape up as principles works amazingly well also for companies that are vc backed the the place where the the difference is is in how you do it so in the book there's there's kind of two things happening at the same time there are these kind of big picture mindset changes, you know, from working in this like world of just estimating and then saying, how long is it going to take versus saying, how much time do I actually want to spend? And then designing into that, you know, setting the appetite and then shaping into the appetite. There are these kinds of mindset things and those are universal, but then there's the like, specifically are our cycles six weeks long? do we have separate people who are shaping in parallel to the people who were doing the the actual building in cycles those are the things those kind of concrete implementation details those are the things that are very different if you're a company that's bootstrapped like base camp or if you're in a different situation like a vc-backed company the main difference is that when you're bootstrapped and also when you have basically if you are very comfortable with a lot of cash flowing around then you can have these luxurious long timelines. It's like, oh, six weeks at a time and a two-week cool down in between. And maybe we'll do this and maybe we'll have a few different ideas on the table. And if we don't get to it now, we'll do it later. That whole atmosphere is based on being bootstrapped and having healthy cash flow. When you have external stakeholders, when you have Investors, when you have targets that you have to meet, then that is a totally different atmosphere. That is much more like you have to be very kind of targeted. you know like in the next two weeks we want to do this thing because this change is going to improve our activation and then after that we're going to make this change and we're going to do this for three weeks so you need to be more like you know like moving fast and targeted and trying to get a bump in a certain number because you have a goal that you're trying to hit it's a very different atmosphere but if you look in that atmosphere the pressures are actually the same we st we We also don't want to have a bunch of unexpected complexity or a bunch of unexpected scope coming up. And then we spend two, three, four times the amount of time that we intended to spend. Right. So like all of those things are the same. It's just that the time boxes that we choose. So we're going to set an appetite one project at a time. We're going to say this thing needs to be three weeks and not more. And then what can we do inside of three weeks to make sure that we actually accomplish that change that we're trying to do? How do we shape that so that we really get to the end of it and we're able to ship it and it works? And also the other big difference is that in a bootstrapped company, there's more, let's say, freedom and time maybe to shape a few different possibilities and then wait until the last minute before some team becomes free. and decide what work to give them. That's how it was at Basecamp. In most companies, actually, it makes much more sense to have one thing that is the most important thing to do next, make the business case for why that's important next. So frame the problem, the opportunity, why this is more important than the other things. Shape that one thing, get a green light on it, build it, and then figure out what's the next thing. So more like one shot at a time. You know, what's the most important thing? What's the best opportunity? Let's invest time to shape that. Let's build it. Okay. And then what's next? So it's less about having these kind of big parallel tracks. And it's more about like, boom, boom, boom, one thing after the other, so that we're getting closer to the goal that we need to reach. Okay, just a bit more strategy. Well, you know, it's a different environment. So like, if you are leading product strategy and you are in a situation where you have a lot of vc pressure and you have to hit some targets and hit some numbers you're going to want to be much more hands-on and you are not going to want to say well if it doesn't work in six weeks then we always have another six weeks because you don't have so much time right so it's more about kind of yeah being more hands-on with like what are we trying to achieve here and making sure that we get it versus if you have that luxury of having more of that six weeks, you still want to be strategic, you know, when you are bootstrapped and you're able to work in those six weeks because you want those big, you want to make those big steps of progress that the six week cycles make possible. It's just that the structure around you is different, you know, so it's easier to do it maybe the way that it's described in the book when you're bootstrapped. Yeah, absolutely. All right. Well, since you, you know, you've been working with the a ton of bootstrap companies and new VC backed businesses are also approaching this and asking like how how this can be done so is there like any trend that you see in adopting this like why why are companies coming to this why is it just the on one hand maybe the hype behind it, right? It's a book that everyone's talking about. I mean, it's been around for four years, but literally everyone in SOS knows what it is. Is it the success of Basecamp? Because again, both Jason and David, you have been talking about and how it worked and I know where it got you guys. Or is it something else? Is it the realization that maybe, you know, whatever they were using doesn't really work and they have to adapt to this changing environment. Yeah, it's really this last one that you mentioned. There are so many things that we're excited to do when we're trying to build a software business, you know, or if we're trying to program or whatever, and changing the way that we work together is not high on people's list. It's usually like the programmer has a million things that they would love to explore. on the technical side you know and the business people have a lot of ideas of strategically we want to do this and we want to do that and then we want to serve this customer by building this feature there's so many things everybody wants to do and like rethinking our you know process of how we work is like it's not the priority and there are kind of two main reasons why it sort of starts to become the priority and the first one is when did i just have a bunch of I think there's some magical FaceTime feature or something that I triggered without knowing it. That's amazing. That was wonderful. I'm on a new Mac here and something in this setup wasn't understood. That's amazing. Okay. So, but anyway, there's kind of, there's two main things that drive people in. One is when leadership realizes like we are actually not finishing things and that's and and we're not going to get to the finish line in time on the stuff that we need to ship so it's like projects are taking longer and longer there's so much scope it's it's like and this cannot continue like we have to be able to finish things so that's one reason the other reason is uh there are teams who are actually able to finish things because they have someone who is kind of that product person who has everything in their head. They understand what the business is trying to do. They understand what's technically possible. And whenever a project has to get started, they are kind of the one who has to be there to bring it all together because they're the person who understands both worlds. And what happens is when the company starts to grow, or starts to take on more work or starts to hire more people, it can't all depend on the magic of that one person who knows both worlds anymore. You need to remove that bottleneck and have some kind of a repeatable way for how all of these different roles and functions come together in the shaping phase so that the projects can continue to be delivered well. So it's not like we can't finish things. It's more like, yeah, we can finish things, but it all depends on Jill. And if Jill isn't there, how are we going to do this? And we can't just clone Jill. So you know what I mean? Like we need a way of working that is going to give us the same result, but it's more, let's say, scalable. Yeah. And just one more thing that, and I also asked Jason about it, because like for me as for a marketer, like it was really fascinating to know that there are like two people usually in the team or like, anyway, there are programmers and there are designers, right? And that's usually the usual setup of any startup out there, of any new SaaS tool, pretty much. And it was like, why is there not a marketer? Because ultimately you need to know how to then present it to people, right? And what he told me is that that decision actually comes from him, for example, right? And then everybody knows how it's going to be sold. But the team, what they're doing is they're... they're building it right there making sure that there is a beautifully engineered sequence. But that's also like quite unique, I guess, for Basecamp and teams like that, because then there is a good ratio of developers versus designers, right? And in a lot of companies, that's an issue. Like you have maybe two designers and then a load of developers. So yeah, how do you also like battle this? Because like you said, and I completely agree, like, for example, and I'm not a designer in it, like, anyway, I can just have something in my head that I will explain to the designer how I want it done. But then it's their job to deliver that to a developer, right? And then developer would tell you if it's possible or not, technically, because for me, technically, everything's possible, right? It lives in my head, then it's probably doable. But how to like, how are teams bridging that gap between well, maybe someone on the team not understanding like what's physically possible, what's technically possible for a project? And what can actually be done with the appetite they have. So the way that a lot of teams deal with this is there's a designer who creates a kind of vision of what the surface looks like, and they make very, very detailed drawings in something like Figma. And then those get thrown over to technical people who are supposed to somehow kind of understand what it means in terms of building. And usually there's a big mismatch there. There's a lot of things that can't really be built the way that they were drawn. There were things that weren't drawn that need to be thought about, like a lot of edge cases and complexity that isn't taken into consideration because the person who drew it wasn't actually aware of all the technical factors there. So I like to use the example, like if you're doing a renovation in your house and you want to put a lamp up on the wall and you have a drawing that this lamp is going to be there on the wall and you only focus on the color of the lamp and how beautiful the lamp is and where exactly the lamp is positioned but you don't actually know if there's electricity behind that wall and there's a wire that can actually give the lamp the electricity that it needs to turn on right and if there is electricity there then you can just put the lamp there but there isn't if there isn't electricity you're going to have to rip open the walls and have a electrician an electrician come in and do a bunch of expensive work that changes the budget and the time and the plan for the whole project right so usually these technical things are missing in the beginning because we think of the project as being just this visual design but really when we're building software we're building something that is technical most of the work most of the cost most of the trade-offs are actually they have to do with what can technically be built so it is much more effective to bring a technical person and someone who understands what it is that we're trying to do in terms of the customer experience bring those people together into a live shaping session and have them do those rough drafts those like very rough sketches that we talked about before have them kind of sketch out different architectures It's very helpful to think about the difference between architecture and interior design. You know, no matter what the kitchen is, we can choose the right paint color and we can find nice fixtures for it and we can choose the most beautiful tile. And those things are not the biggest factor in cost. You know, the biggest factor in cost is whether we can actually get all of these rooms. and all of the pipes and all of the infrastructure built. And then there's kind of the surface of making it look good. And that interior design, it's important. No one wants to be in just a raw space that isn't beautiful. But the architectural decisions of how many rooms there are and how do we move between rooms and how do we deal with the plumbing and the ventilation and the electricity. These are the big things that really impact cost and schedule and what kind of house we really have in the end. So it's much more effective to bring those different people who have the different skills together, like the product person, the person who understands the experience that customers want to have, the person who understands what is a good kind of a workflow from the user standpoint. But very importantly, the technical person who knows what we can and cannot build and what is the real cost of different possibilities with what we might build, right? And how things actually fit together technically. Then when we have these people together in a room, we can sketch out some different architectures and then we can have something that we say, This is something that's feasible. This is something we can do in the time and budget we have. It's something that's going to do what the business is trying to accomplish and what the customer is trying to accomplish. And then later on, we can actually figure out all those very fine details about the exact color and position and style. But those aren't really the important things in the beginning of the process. They're actually more important later in the process. Yeah, absolutely. All right. Thank you. So since we started talking about like different stages of the product and of the tool that we're building, I also wanted to ask like about adopting ShapeUp at the very beginning, like there is nothing yet, right? Or like want to go to market like super fast and that's kind of like. everyone says oh but you can whip up a product in like 15 minutes right there is no code there is low code white label solutions like whatever it is you can just you know throw your brand on it and and that's it you're done well that that sounds really cool but it's not really possible right you can yeah obviously you can build it but then there is so much more that you have to um work on in order to in order for it to work So how to adopt ShapeUp? Is it possible to start with it if you're just starting? Because now it's also not very feasible to go to market with something that is not ready, with something that is not pixel perfect. The design is just not there. There are bugs that will appear when you actually give it to the customers. how a product should look like when it goes to market when you show to your first users it's just so it's just over the top right now uh so how to integrate shape up into that i've seen a couple different ways that teams start working together when they're just starting you know like on a very brand new product and it has a lot to do with the way the team is structured if you've got all the skills necessary and they're all together in a room every day, a lot can happen kind of by magic. I mean, I've seen this in a lot of teams. They're just, if you're just in the same room and there's only three of you and you have all the skills in that room to make the decisions, you don't need a lot of process and a lot of structure because things can kind of just start happening. Usually the place where teams start to feel like we need a process or we need a way of working is when there's a step of, let's say, delegation. You know, when like I kind of understand what it is and I'm asking you to go do it. And now there can be a disconnect between what I'm imagining and what you're imagining and what I think is possible and what turns out to be possible when you're actually doing the work. Right. So it's more when those gaps start to appear. And then the question starts to arise of like, okay, maybe we have the experience of giving someone the work and then checking in after a few weeks, and it's just not what we thought it was, or it's not moving the way that it would have moved if we were doing it ourselves. And then we say, what are my options? How can I deal with that? And then if we go into just the toolbox of ShapeUp, we don't necessarily need to have a lot of structure around. we always work in cycles that are this long and this person is in this role and this person is in this role we can just take the tool of shaping and say before we actually kick off a project and make the commitment that we're going to spend x weeks on this thing we are going to make sure that we've actually shaped it and we can see the architecture we can see that these are the few moving parts that connect to make this thing work and make it feasible. And we've actually looked into the specifics and this is a really doable thing and we understand what it is that we're getting into, right? So just having a shaping session and getting more clear about what it is that we're actually doing before kicking off the work, this is something that small teams can start to do. I've also been in a situation, I built a tool with some friends of mine a year and a half ago. And we worked for about a year and we worked in very standard, even you could say strict shape up, even though it was just myself as kind of the product and designer. And we had one part time programmer and I would shape the next thing, package it into something that clearly explained all of the concept and the moving parts. And then the part time programmer, he was able to work on that for six weeks. We would get to the end of it, ship it, do the next thing. And we went through that process for a year to get a whole new brand new product standing. And it was a fantastic process. And a big part of that, though, was because we didn't have very much overlap in space and time, you know. And so I needed to be able to really formulate what it was that we were trying to go do and make sure that he really was seeing the same thing I was seeing. and had all of the context and kind of the whole picture so that he could go and run with it you know so we needed that in order to make that progress together okay so it works perfectly for asynchronous teams it works very well for asynchronous teams when it comes to building i think that asynchronous is a little bit let's say it's becoming a little bit like of a should and a should not kind of a thing You know, like there's a little bit of an atmosphere right now that if you're having like meetings are bad and we know that meetings are bad, therefore, like everything has to be asynchronous. And this might be the pendulum swinging too far because when it comes to actually doing the shaping, meaning like what are our options? What are we actually trying to do here? What is a possible solution? Like what's a good concept here? That is really difficult to do asynchronous. A lot of times if you want feedback on an early concept, and you actually want to get into some different direction you know or something is too big and you need to narrow it down to what is really the core of the idea that kind of work requires wrestling with the trade-offs and wrestling with the constraints and figuring out what's really possible and what are our options and if you try to do that in an asynchronous document the document just keeps getting longer You know, like another comment, another comment. What about this? Maybe this. What about this? No, I don't think we should do that. And there's a lot of ideas getting thrown onto the table or maybe a lot of objections, but we're not actually converging. You know, we're not coming together on like, what's the conclusion here, right? It's just kind of like everybody walks away from the discussion, you know, okay, I put in my two cents, right? And everybody kind of walks away thinking what they thought before, which is like all communication on the internet. You know what I mean? You just add your opinion and nothing changes, right? But when we're shaping, when we're actually deciding like, what are we with our limited time and resources going to build in the next three weeks or six weeks or whatever it is, we have to make trade-offs and decisions together. We have to really get in there and say, you know, do we want... the three bedrooms and two baths but in the cheaper location or do we want to be in that central location where the real estate is expensive and sacrifice space and have the smaller space those trade-offs require really getting into the subject together right and that's really hard to do asynchronously it doesn't mean that we need to be having meetings all the time a single two or three hour intensive shaping session where we really dig into what our options are and what trade-offs we want to make can do wonders i mean a focused two hours together where we really get into what our options are and then come to a conclusion together can that's i mean that can be the kind of kernel where all of the important information about how to make this project a success that kernel can then carry on through all the subsequent weeks of the project and enable it to succeed. It's really, we can really get a lot out of those intensive work sessions. 100% agree. I mean, I enjoy, we're fully in asynchronous, well, not fully asynchronous, but we have as few meetings as possible at Sarsker Open, especially me because I'm not really involved in like the work of any other brand. But there is this one meeting that we have. per week and it's an hour and a half and you're like really looking for it because like you have all this points that you want to go through and you're just like okay it's coming and we can discuss it and we can get to the same page and like we we can all know what's going on so i completely agree like asynchronous is great up until you need a big decision or like a big uh exchange of ideas And asynchronous works really well when we have a kind of frame of what it is that we're doing and what it is that we're talking about. Do you know what I mean? If you have a map of what it is that we're trying to do, then you can kind of easily talk about it in a chat or a document because you can just say, I'm over here working on this thing and I have a question, right? But if you don't have the map because you haven't figured out what it is that the project is or what you're really going to build, that's really hard. you know it's really hard to align people and to really know that we're talking about the same things absolutely all right uh well uh i have just just a couple more questions and uh the first one i guess yeah you are probably the right person to ask for a hack because you've been successfully building strategy for one of the most successful SaaS companies out there. And now you're helping so many teams to build better products. So is there a hack for the teams that want to adopt ShapeUp maybe? They haven't... been able to do that and i heard this one on another podcast that you were doing where uh they had a book club they were going through the book and uh they were discussing each chapter of it and i think it's brilliant but not again not every team has the time to do that so is there anything else that you know is a good point to start if you want to adopt shape up i would say the one hack that goes the furthest for most teams is for the people on the product and design side to find that one person on the engineering side to invite into the early sessions where they figure out what it is that they're going to do next. Just figuring out who is that person? Who is the one person from engineering who we could bring into the room, who could help us to understand on day zero, that something is going to be way more complicated than we think or more expensive than we think or easier than we thought because they know how things are actually built right instead of going through a whole bunch of discovery and ideation and concepting and then after hours and hours and days and weeks of work having the technical people say no that's actually not real you know just to break that cycle of all of this work and then we find out it's not going to work and we have to go backwards you know just who is that technical person and bring them into those early design sessions that's that's a giant leap okay wonderful thank you and one more question it could be yeah it might be tricky and i'm not even sure if that's relevant to you but you know apart from shape up and apart from like building this own unique methodology use anything else but if not shape up then what if not shape up then what i know i would love to say that there was an alternative to point to but the way the industry has gone uh basically it's either um people are either doing scrum they are moving tickets across a board on a kanban kind of a thing you know but then it's very little isolated pieces of work right or If they're not doing shape up, they are getting their best people together and just hoping that if we put those people together, then they're going to somehow magically work it out, you know? And when you have good people, it does tend to work, right? So it's kind of either, you know, either the miracle of good people or, you know, I like to call Scrum the paper shredder. because you take whatever your concept is and then you split it into a million pieces and then hand them out, hope that it all comes together again. That's what we have on the menu today. So it would be great to have some other ideas about how to do these things. So far, actually, Scrum is the main alternative. And it's nice to see that people are starting to discover all the shortcomings and look for another way. One thing I could point out is that when it comes to... Shape Up is all about... how to get an idea into reality, how to make it into something that ships and ships in the amount of time we want to spend. There's also the whole question of what is actually the strategic thing that we should be shaping, right? Like once we have our muscle of how to actually build things, like once we know how to drive the car, like where should we go? You know, like how do we actually set the strategic direction? And this touches more on the demand side of how to understand what customers are actually struggling with, what are the real problems and opportunities in the market, and ShapeUp dovetails very nicely with all the job-to-be-done work that my friend and mentor Bob Mesta has pioneered. So if you look into Competing Against Luck by Clay Christensen, or you look into Demand Side Sales, which is 101, which is an amazing book that Bob wrote, you can get into this kind of other universe of understanding kind of how to set the product strategy. And then that's like a different thing than ShapeUp, but they're very complementary because it becomes the input to what it is that we're trying to shape and build. Awesome. Thank you. Thank you for being very honest about this. It's been great talking to you. I mean, you've inspired me to read a book about product management. So thank you for doing that. It was a great experience talking with you and meeting with you in person. Hopefully we can do it again sometime. So thank you for being here. Yeah, thanks a lot. Yeah, great to be here. Nice to see you. Thanks for the invitation. Sure. Anytime. Thank you and take care.

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/ . I'm your host Anna Nadeina, Head of Growth for saas.group. In this episode #14 we are talking with Ryan Singer, the member of the initial 3-people team at 37signals, now author of  Shape Up: Stop Running in Circles and Ship Work that Matters, and the founder of Felt Presence, helping product teams stop running in circles and regain the thrill of building.

In this episode we help you uncover the secrets of successful project management as we navigate through fixed project duration and the art of asking the right questions with Ryan. Understand how Shape Up impacts businesses of all types - whether you're bootstrapped or VC-backed, there's something for everyone here. We help you shift your paradigm from estimating timelines to setting project time limits and make you realize that the specifics of Shape Up implementation can vary according to your company type.

Ryan shares his invaluable insights on creating a repeatable process that doesn't rely on one person's knowledge. We discuss the importance of a unique ratio of developers to designers and its influence on the product vision. Finally, we touch upon ensuring that technical factors are taken into account during project planning. 

(0:00:06) - Insights Into the Shape Up Methodology

(0:07:39) - The Impact of Shaping in Business

(0:20:13) - Improving Software Development Processes

(0:31:16) - Adopting Shape Up

Subscribe to our channel to be the first to see the interviews that we publish twice a week - https://www.youtube.com/@saas-group?sub_confirmation=1 Stay up to date: LinkedIn - https://www.linkedin.com/company/14790796 Twitter - https://twitter.com/SaaS_group Website - https://saas.group/