Shaping up to deliver big and meaningful software products | Ryan Singer - Author of Shape Up

Hello, everyone. Today we're talking with Ryan Singer. He's the author of the book Shape Up, which subtitles Stop Running in Circles and Cheap Work That Matters. I think this will be an interesting episode and navigate through this interesting product development process and all the story behind Ryan and his work. So welcome, Ryan. How are you doing? Hi, Ricardo. Nice to be here. Thanks for having me. Yeah, Ryan, so, well, maybe something I missed from my introduction was that you are the former head of a strategy of Basecamp and you also kind of work around almost 18 years in the company and move from early stages of Basecamp and change different roles. So yeah, maybe on that specific journey, can we talk about how Yeah, how do you define yourself based on this journey? So what, yeah, how do you call yourself at this point? I've tried to understand that over the years. I think the pattern that I've noticed is that I really like to work at the interfaces between different things, you know? So in the beginning, I was literally an interface designer. I was... doing the the ui um and that's kind of the place you know between the human and the software and uh and then i became kind of the bridge between uh the design and code inside of the company uh so i became kind of uh i learned kind of to be also the interface kind of between teams and and expertise in a way you know how do you actually connect these different functions together design and engineering And then eventually I realized that even if you can design something and you can build it, you still have to answer all these difficult questions about, well, like, what is the right thing to build? And what is it that is going to move the needle for the business? Or what is it that customers care about? So now you have an interface problem between the business, let's say, and the market and your ability to build and design things. I've always been really interested in kind of connecting and learning how to integrate all these things so that everybody has an understanding. I mean, for me, like I just I love seeing the whole like the big picture, you know, I just that's what's exciting for me is to see how all the pieces connect so it all becomes one picture. And so it's fun to be to go down into the details in one area. But for me, I really like being able to connect it all so we can understand how it all fits together. Right. So. Well, that's good, of course, thanks to the experience that you are kind of self-aware of what do you like, of course, right? So that's important. I think I share something similar like you, right? I like that communication bridge or, yeah, connector of different areas of a business and, yeah, how to translate something in an easy way between all the parts, right? Yeah, and so, well, as I mentioned in the intro, so, You have been working on Basecamp as a head of a strategy at the end, but as you mentioned, you started from design and user interfaces and stuff like that. Yeah, so based on that, now, since you have been creating this process of ShapeUp, what legacy would you like to get out of this ShapeUp? Imagine in the next 10 years, what would you like to see in the market with ShapeUp? You know, I'm very pleased that we're already starting to see an impact. I think you've probably noticed that the attitude around agile and Scrum has really changed in the last few years. I think if we go back 10 years ago, a lot of people were still very excited about Scrum and all these 10, 15 years ago, these tools like Jira and stuff where they felt like fresh things, you know. uh and today it's uh you talk to people who are doing all of these scrum rituals and it's like oh we have to have all these long meetings and you know i feel like we're never getting anything done so this general attitude in the industry has really shifted and people are actually tired of this way of working and i'm surprised how often i hear from people who say yeah i've My team is doing ShapeUp or we're doing parts of ShapeUp or we're inspired by ShapeUp. And so I don't know where it's going to lead, but I'm very, very pleased to see how much interest there is. And it seems to be the right time where people are really looking for a way of working that's more around actually how to bring all the different roles together to really get big stuff done instead of just kind of having some machinery for the engineering teams to go through tickets. Yeah, understood. So it's not going to be a factory of features and just go through task to task and so on. So while we have been kind of talking about shape up in general, but maybe, well, this is of course the right time to talk. Okay. What does it mean shape up based on your, in the big picture for you? And maybe, yeah, I understand the concern about the scrum and agile, which has been kind of trendy in the last 10 to 20 years, I think, or something like that. But Yeah, what is the story behind the J-pop process? How did it start it? And also, what does it mean, J-pop, in the big picture first? Well, I think it starts with this feeling that we want to ship something. You know, if you work backward from that feeling that we want to work on something that is not just finishing some tickets here and there, but we want to actually... finish something which is exciting something which is a big project that matters to the you know the product people want to do something that really matters to the customer you know and uh they want to ship something that actually impacts the business and on the engineering side the engineers what they want to work on something which is kind of feels like a big victory you know like something hard like like a big challenge you know and so everybody wants to be able to work on something big and actually deliver it and ship it on time. And what we start to see is that when we're trying to do something big and meaningful, of course, it's exciting when we talk about it, but then when we actually start to do the work, then we might start to notice that our designers and our engineers, that they don't speak the same language and they don't really know how to actually work together. to make the trade-offs and make the decisions and make forward progress you know so this is kind of really where it starts and um uh shape up evolved from all of my experiences at base camp over those years because we always had this kind of urgency this kind of exciting kind of this this good kind of urgency coming from jason and david the founders there of like let's just make some decisions and let's ship this, right? This idea that you were going to have these long dragging projects or a lot of work and then going backwards and then redoing what you did or changing what you already did. There was just this culture at Basecamp of like, we wanna move forward, you know? And so then the question becomes like, well, what are the ways of working that are actually going to allow us to do that? And it has more to do with actually understanding what it is that we think we want to go build together. So putting the design and engineering heads together earlier in the process and not just saying, okay, we're going to figure it out as we go two weeks at a time, but having more clarity around this is actually what it is that we think we're going to build. We call that the shaping process. And especially the key difference there is instead of having some kind of you know, long, never-ending process where we can't see where it finishes, we kind of start, we learn to start projects by saying, how much time do we actually want to spend on this thing? And then creating this kind of box of this is the maximum. This is the budget for the time that we want to spend. And now that we know what we want to invest in this and when we should be done, now how do we actually explore different design alternatives and how do we look at trade-offs we can make in the scope so that the work that we decide to build actually fits into that amount of time right so this this notion of fixed time variable scope or being driven by an appetite instead of an estimate you know this is something that grew out of the experiences that that i had at base camp and then this is something that i formalized into shape up so how do we actually look at our development process in this very different way, where instead of give me an estimate and let's just, however long it takes is how long it takes, let's flip that around and say, how much time do we strategically want to spend? And now how can we actually shape different design alternatives and evaluate what is it that we can get for the amount of time and people that we have and the availability that we have? And how does that actually align? you know with what's possible on a technical side and where we actually want to drive the business from a strategic side okay yeah of course it's a really interesting approach of course and is did you what other processes did you try before deciding let's trash this and let's sit down to create shape of do you have some moment in in base camp uh collaboration that you decide hey screwing is not working Well, I think it's different when you're inside of the process versus at the end of it. You know, now that ShapeUp exists, we can go down the aisle at the store and look at what's on the shelf and we can say, oh, do I want Scrum or do I want ShapeUp or what do I want to do? You know, and of course, there's a lot of there's a lot of different ways of working. but uh when you're inside of a small team and you are you are experimenting together then it it felt very different you know we were trying all kinds of individual things over the years when we were in different moments when we were trying to solve problems you know so there was like a one thing we knew was that a two-week sprint wasn't going to work because uh you can't actually finish something big you can't really build something big in two weeks you know uh and we needed to be able to see the finish of things so this led to a kind of a longer way of working where we where we were working more in six-week cycles but i've actually i've since learned that even this thing between two weeks and six weeks isn't really the important thing you know a lot of what was happening a lot of this development came from some of the intuitions that i learned from jason and david you know uh there was this Jason and David, they did not want to just start something without knowing where it was going to lead because we had to be making progress because we were so small. If you only have two people or three people working on something and you waste time, you're never going to get anything done. So there was this kind of pressure. And so this kind of drive for clarity in the beginning of like, what is it that we're actually doing? Do we understand the concept? Can you explain kind of the moving parts of this idea so that we know what it is we're asking people to do? That kind of clarity was something that I learned was really important. And so a lot of this was just about figuring out how can we actually create that clarity? And it was a trial and error process. And it was only at the end of actually 16, maybe 16 years, 16, 17 years. that i was able to actually formalize this and look back and say ah here we can actually describe all the stuff that we figured out and start to teach it to others of course that takes time right as you're saying so um yeah my question next will go towards okay i understand that in the shape of process you have first uh this initial step which is actually shaping up right this goal and basically um you are making a small structure of what you would like to build around the product, right? But the question for me is what happens before that? Like, how do you decide what to go to a shape-in session, right? So do you have any way to... Because, okay, I can give you an example, right? So imagine I am running a product team as well, and then... Of course, we are receiving feedback more or less in weekly basis, right? But we cannot just jump and start shaping everything that the customer says. We need to have some prioritizations. So how do you decide in base? Yeah, what to go to a shaping session? Is there something that you use for that? Yeah, this is something that I learned actually after I left Basecamp and I started working with a variety of very different teams. learned that there was a missing concept in the book because a lot of people had this question and it was something that was happening so organically inside of the team at base camp that I didn't even realize it needed to be spelled out you know but I've since learned that there is really a different phase of work that comes before shaping and now we call it framing and framing is about What is the problem? What is the opportunity? Do we understand what it is that is important to solve? Right. And so there's this kind of qualitative side. If there's something we think we want to do, we have to understand what is the problem and why is it an opportunity for us? But then also on the on the quality, on the quantitative side, like, is this thing big enough to spend time on? Is it a real thing? How many people does it affect? Is it more important than other things that we might want to do? So all of that work, that is what we can call framing. And it's not about what is the solution to the problem or what is the technical design. The shaping is actually much more about the technical solution and what we're actually going to make and the design concept versus the framing is more like, what is it that is strategically important to the business? And based on that, what are the things, what are the problems that we think we should actually turn into real projects, right? So that's kind of that first step. The other thing that's a big change is that in the book, I presented this kind of process where we shape some different possibilities of what to do. And then we have this betting table where we decide which of the shape things to bet on. And in real life, actually, it's funny, it's usually the opposite, that actually the bet really happens in the beginning. So there's this, all of the different things that we might spend our time on, and then we have to do that work, like you said, of kind of aligning on what is actually the next most important thing, what is the next thing that we want to shape, and that's that framing work. And that's actually the time when most of the bet happens, you know? uh when you need to come to agreement that this is the next most important thing and then if we have something framed or we think that there's something meaningful that we could invest our time in then we can go try to shape it you know and sometimes by shaping it we might discover some new questions are being raised about what is the problem really about you know there might be some trade-offs that we need to be able to deal with so there can be a little bit of back and forth between the framing and shaping but actually that that alignment, that strategic alignment, it actually starts at the beginning with the framing. And then we go into shaping and if we're able to shape something and we say, yeah, that's something that we think we can really accomplish, then it's more like just turning the light green, you know, or hitting it with the stamp and say, yeah, this is good. Let's put this into the next cycle or let's give this to a team to build. Okay. And do you have any specific advice towards... how many times to do framing or is something individual to every company? Like, for example, just as I said, again, in my case, using as an example, I'm having weekly meetings with customer success people, right? And then I am getting feedback, feedback, feedback. But then it's like, okay, but I already have a roadmap. And then, okay, what I do with that feedback, I cannot just suddenly change the roadmap every week, right? So the framing, process is something that you advise is like a monthly bash for example that you kind of i see what you mean yeah so this this looks different depending on this on the the structure that you're in so um the structure that you described is where there is a kind of a bigger roadmap right that's getting decided at a higher level in the company and then there are different product teams and then inside of your product team you also are trying to find things that you think are a good idea to work on and you have like these two different levels right there's like the big things that are coming from the higher level in the organization and then also you're trying to decide on the smaller things that you can accomplish uh not as the whole company but just inside of your team right and this this framing it's it's it happens in both it can happen in both levels so um But the thing is that it helps to work backward from the free time, let's say, that you have available to you to build with. So there's some amount of space that is like your choice that you get to use. And there's some amount of space that is not your choice because it's already something else that's on the roadmap. So wherever you have the open space where the question is, oh, here's, so maybe in this quarter, you don't have any time for your own projects because it's all coming from bigger things. But maybe you have a gap between bigger projects where two or three weeks appears. And now the question is, what's something that I could do in that time, right? So everything about shaping and framing is actually about how do I use that time? that is available to me in the smartest way. The framing can happen also on the higher level. So somebody has to decide what goes under the roadmap, right? If you're in that kind of a structure and that's actually also framing work, right? It's making that decision of like, what is actually important to us and what are the things that we want to build? So I would look at it more as when you have some capacity that's going to open up to you, you know, then you're going to be in the back of your mind trying to come up with, you know, what are the, what's, what's the thing that I'm going to try and do as soon as I have a chance. Right. And so that's the framing work, you know, and it, it, it might not be, um, uh, monthly or weekly. It might be more that you have a running process that is like your almost more like your private process. of um trying to prepare yourself so that when the chance comes you have something good that you can put into that time yeah it makes sense of course so yeah and how do you yeah talking about companies and teens so is is there any specific size of teens and type of companies that fit more to the shape of process that you would advise because Let's say, imagine in the context of an early stage startup. Do you believe ShapeUp is aligned with an early stage startup or you believe it's more for a scale up or for a corporate? So how do you feel into this classification, let's say? So the way that I look at it is that there are different steps of work that we have to do no matter what size company we're in. Whether you are a tiny startup. or you are a big established org, there are going to be times when you're trying to ship something that's important and you have to figure out how do we decide what it is? How do we align people on spending time on this instead of something else? How do we get the clarity around what it is that we're asking the engineers to do before they start? right how do we prevent the process from slowing down and having all kinds of unexpected complexity or the work you know people coming back to product with questions all the time or all of these things these these problems they happen at all sizes you know so the the specific way that we do it is going to look different depending on if we're just three people or if we are 200 people and i've seen shape up applied in actually all of those cases that's been a big driver for this course that we're doing now i have this course called shaping in real life and we do uh cohorts of this a few times a year and this has actually been a result of learning that there are so many different ways to do it and not just the one way that's described in the book and so actually what we do in this course is we teach people how to break ShapeUp apart into these separate skills and these separate steps that happen. And then you can see in your company, okay, when is the moment when I have an idea and we're trying to bring the engineers on board, right? Or when is it that we need feedback from engineers because we don't know what's possible? Or all those different moments that come up, we have tools for that. It's a little bit like a big box of tools and it's more about learning how can I... use those tools in the moments when I need them to make the progress in the organization that I'm in. That sounds good. So, yeah, it's good that the process, of course, is adaptable and, of course, that we can kind of take pieces of it and start building on top of that, right? That's really important. Yeah, I even think of it more like a framework now than really a process. It's not so much you do this and then this and then this and then this. It's more like, you know, when... when we keep giving work into a cycle but then it's it it it keeps the work keeps getting bigger and more complicated like how do we solve that we need tools for that right or if we're trying to design the project and we can't agree on the scope what are some things that we can do to solve that right we need to have tools for those different moments right okay um maybe i will go a little bit in the big picture now like okay based on your experience about a strategy or product strategy in base camp as well so because of course we have been going really deep into into let's say operational part right but now if you are talking about the big picture of uh let's say imagine we are some of our audience is a early stage startup or and it's trying to build a tech product right so how do you define a product strategy and how does it look like in the big picture because maybe this is we have been talking as i said a lot about the specific cycles but then now in the big picture what how do you align the team that this is the direction or the big mission or something like that the way that i've learned to see strategy is that there's different moments that you need to figure out how to handle those moments There are times where you might be in a company where there is a founder who very clearly knows what to do, right? They have something that they want to build or they have a problem that they know. And it's like, we're just going to build this thing, right? And, you know, I would say that most startups... Somebody just has an idea of what they want to build, you know, and it starts like that. And actually, if you're talking about really early stage startups, in the beginning, you cannot tell a founder, like, we're going to talk about strategy. Because they just want to make what they want to make, right? And they have to fail a few times before they start to say, okay. What is this stuff about strategy? So there are a lot of times when the strategy is just, look, the CEO has a vision and we're building it. It can be as simple as that, right? And then maybe it works and maybe it doesn't. And then there's times where you've been building and building and what you're building isn't working. So then you have to try and understand what is it? that i'm missing right what's wrong with with with the picture here it can also happen that you build something and this this this happened to me at base camp we had a very successful product and after about seven years of the product just growing organically i reached a point where i didn't understand how to improve it there were so many people using it in so many different ways and i just felt lost like i didn't know which customer to listen to you know i didn't know which problem was more important than which other problem or if the problems were even real problems and if i fixed something would i break something else you know so those kind of situations can come up where we feel like we don't really understand what is important and that what i've learned is to reach for a Tool that I learned from one of my mentors and also a good friend Bob Mesta And that's the demand side interview So he teaches this very specific type of job to be done interviews where you talk to people who made a purchase or they They already kind of got through a process of deciding To buy something or to change their behavior or something like that and you learn how they made the decision and what they were trying to do and how they knew if it was working for them or not. And then this is a research method to clarify basically what is it that people are actually trying to do and what do people really care about? And I first did that when I was in that situation I described at Basecamp when I felt like I was lost and I was in the dark. And that gave me a lot of clarity where I could start to understand. how to start to think about what customers were trying to do. And when I knew what they were trying to do, I could see the obstacles and the places where the product wasn't working as well. And this led to lots and lots of new ideas for how to make things better. I do the same thing if I'm on a brand new product. I've had that. I mentioned the founder that doesn't even want to be asked about strategy. You know, if you've been through that experience, then you start to think, OK, maybe I should I should talk to some people first, you know, to validate to validate if I understand the market or not at all. And so I do these interviews even at the very early stage of a new project to try and see if I understand. the demand if the demand exists out there in the real world the way that I imagine it does you know so this is all kind of on the qualitative side of trying to understand where are the actual problems and opportunities out there in the real market this is this is one method that I know of course there are there are other ways I know that when I was at base camp you know Jason's preferred method was just to build something at a cost you can afford and just release it in order to find out. That's always been his favorite method is not to do research, but to have the idea to build it and to see what happens. But the reason that he's able to do that is because the team there can build very quickly. So it's, you know, you can't invest in building a year. and then find out at the end of a year if your idea has an attraction or not right so so this this you have to be very very resourceful in order to use that method right but it's also possible to to do it like that yeah so that's on the qualitative side then the quantitative side is where um uh maybe you have three different things that you understand are actual problems you know these are things that people are trying to do this is a place where the product isn't good enough if we did better we think that it would be it would be an improvement then the question becomes well how do i understand which one of these things is bigger than the rest and that's where we can do different types of quantitative research and that can be um instrumenting something that's happening inside of an existing workflow so that can be If we've done the qualitative when we actually know the right questions to ask, it could be also done through some kind of surveys and stuff like that. But what I've understood is that the qualitative has to come first because we don't even know what the right questions are and what the right variables are. But then after we know what the questions and the variables are, then we might be able to define some metrics so that we can do the quantitative. But I mean, this is all. Maybe it sounds a little bit abstract. It's a big area, right? That's kind of the rough starting point, I would say. Maybe I could try to simplify it. If I have a question about strategy, then the first thing I would ask myself is, do I understand what the problem is or not? If I don't know what the problem is, then that's a qualitative thing, and I need to... go into the field and do interviews with people to learn the cause and effect of what they're struggling with and what's really a problem if i know the problem but i don't know how big it is or how much it matters then what i want to do is figure out how can i measure that or instrument that what can i do to give me an indication of whether one thing that i'm thinking of doing is bigger than the other yeah i think well of course i can go in multiple directions thanks to this so it's going to be interesting but uh i think one one of the comments you make at the beginning was about yeah that founders of course don't want to hear the word strategies like strategy what but uh maybe at the beginning right because they are to fix it into certain vision or or product idea or stuff like that which is something i see a lot that people get in love with the solution of course we all do it yes yeah So, but then my question into this is how do we communicate, let's say in a role as product people who have certain experience, then how do we communicate to business owners or founders, which maybe are non-technical people or non-product people, right? Yeah, that this is important and dedicating this time of qualitative. interviews and or other methodologies is important before just jumping and coding or designing something so do you have any specific strategy for that in the communication side or the only thing that we can do is give them something so if if I understand right the question is you have people who are in a role above you and the thing that they're working on you think isn't really the most important thing and so the thing is how do you push back on them Is that the question? No, the question is more, let's say, okay, for example, imagine you are talking with a startup founders or it can be from established companies, but they have an idea to build certain tech product, right? They are already kind of fixated over, okay, this is what they want, right? Okay. But they haven't... done any interviews they haven't confirmed that it's an actual problem right so how do you communicate that this methodology actually will save them time and money and effort at the end of the day instead of just running and go to code yeah i don't try to do that it's their money yeah no when someone has a clear idea of what they want to do then we can just get out of the way and let them make their own experiences you know but um when when If I have something that I want to do and I just want to do it and I can afford to do it, I don't need to do research. I'll just do it. You know, and that's that's a risk to bear. And I think that everyone has that freedom to do that. It's more like if if we feel like we are struggling because we don't understand what to do next. Right. Then that's when we start to look around and try and reach for tools. So if we see that there's a business person who is actually struggling to make the decision about what to do next or having difficulty with that, then we can come and say, here are some things that are useful in that situation. Here are some things that can help. But they need to be struggling in order to value it. Okay. understood so let's let them suffer first and then they will learn by themselves and or they might be right also yeah it's it's just it's not our pro it's really it's just uh it's not our problem you know if they're not if if they're if they're in the leadership role and they're not asking that's not our problem well but also from the point of view of let's say okay j-pop as a framework is maybe one way to communicate to them hey i understand imagine i am in that situation right and there is a business person and then i said okay you have this big product idea that's perfect right but what about we try to split this in using this process let's let's take that big idea and let's May first a shape of what is possible to be done in the let's say in the six-week cycle as you said, right and Of course we in the six weeks. We are not going to build the entire product But we will focus into the initial version, right? Which is a complete version and then they kind of already seeing and getting these small wins every Every six weeks, right? Let's say so It's not this and a good approach to yeah to communicate this how yeah how do you because i i feel it's not only about this specific example i'm telling you but this in general about how to communicate that the concept of fixing time and buyable scope is an important thing that we should do yeah i i don't try to sell it um i i i talk about the problems um so if they're having trouble finishing things on time if they're moving too slow if uh um the way that they're developing isn't going to scale because there's no um kind of repeatable structure to it you know um those are the moments when people are interested in learning a new way okay we have to work backward from there has to be a struggle there you know so if they're struggling if they're struggling to deliver on time or if the existing process isn't going to scale, or if they have a way of working, but now they need to onboard new people and they can't explain how they work to the new people, right? These are the moments when you're like, oh, the way that I'm doing things isn't working. Got it. And based on your experience, what is the most common problem why people start thinking about using something like shape-up or changing their way to build? I've seen kind of three main problems because they can be very different. One is the one that I said a few times when we're just not able to complete big projects anymore. People say, why can't we finish things? We have to do something different. The second one is when it's time to hire more people or you are trying to grow and you can't actually like, you need to be able to tell people how to work when you have more people. You know what I mean? And that's a point where if you've seen Scrum and you've seen other things, you're like, okay, but I don't want to hire a bunch of people and tell them to do Scrum. i know it's not i know it's not the right way so how do i have a more structured process that i can actually teach people to do um you know then then a lot of times people will say oh sometimes i see teams who are working in a very good way when it's just like there's no process at all you know they're just naturally a few uh people who started working together and this was just natural sometimes they look at shape up and they say ah That does a better job of describing kind of what we were doing anyway, right? But in a way that we can teach to more people. So this is the second case when you're trying to onboard new people and put a process into place. And there is a third case too, where you have a lot of people who are actually not in a role where they can change the way that everybody works. If you're an individual PM or you're an individual engineer, you're somewhere inside of the process. and you're looking around and you're saying i don't like this backlog and i don't like the way that we go through this process there must be a better way and you think that if you learn some tools then you might be able to slowly uh introduce them around you and make an impact you know in your corner of the company i also see quite a few people who are who are coming for that reason yeah sounds great to see all these different problems why people buy-in into changing their way of work right um maybe yeah i think i will go towards the direction also that i've seen problems towards or maybe it's a problem in general about how we plan right like okay we are gonna finish the year now and then we are making plans for the next year let's say so but also i i see problems with this methodology as well because then imagine i'm making a plan of 2024 and i am kind of giving promises of uh the product will be in q1 will be x with this feature or this problem and in q2 this problem but then but you haven't even stopped in the framing or the shaping of that and imagine that in the framing and in the shaping you discover it i shouldn't be doing this i should be doing that right so How do you change the communication or the mindset of a company? Also, because there are a structure already set, like board members, C-level people. And how do you change that mindset of product thinking that make it that you cannot just written in stone everything, right? In the plan. So how do you feel into this comment? Well, we have to write something in stone. and this is i think um the it's easy for us who are on the on the other end to say oh you know the this all this stuff we can see all of the things that go wrong with this road mapping process but then at the same time we have to try and ask ourselves well why is all this happening why are they making this roadmap right why are they doing this because at a leadership level there has to be some kind of an alignment between the people who are deciding how the how to get money or where to invest or how money gets spent there has to be some alignment on a big picture level of this is like why we are funding this company next year or this is why we are continuing to invest in the same level we have to figure out like where's the money going like what why are we here what are we spending our what are we spending it on you know and um so Of course, like in an ideal situation, I think the way that Basecamp was doing things was to say, you never really know, so let's only make commitments six weeks at a time, you know? But even that is not really what was going on because at a leadership level, there was an understanding that next year, we mainly want to focus on this new product idea. or we want to add some very major new features to the product or something. There was always a big picture idea of like, this is kind of what's important next year, you know? And that's a good thing. That's a very good thing for the company to know what is important in the big picture and where are we investing and where are we not investing. The only time when we really come into difficulty is when we have the wrong amount of detail. there. So if we say we're going to, you know, we're going to invest in solving this particular problem that our customers have, and the exact solution is this feature, and it's going to be released on this day, then we have a problem, right? So what can be really good there is to have the alignment that this quarter, maybe solving conversion problems, is actually more important than building new features. So we can have an understanding we're going to be focused on only things that improve conversion in the first quarter, right? Or the first half next year. Or maybe we have a new product idea and it's something we've been talking about doing and now we think the time is right. We say next year we're going to invest the first half mainly in getting this new product started, right? And we can make commitments like that on a roadmap and those commitments are at that higher level then the framing and shaping framing and shaping is actually about individual projects right you frame a project and you shape a project and then you build a project so when we're framing it actually really helps to have a bigger picture of the strategy that we're trying to achieve so that we can frame that one six-week effort that's going to take us a step closer. So we actually need both, you know. So what's helpful there is just to focus the long-term planning more on the direction and more on what this is about and not about in terms of what we're investing in, you know, and then leaving enough latitude that we can still formulate what the individual projects are so that they kind of accomplish those higher level goals. Yeah, that's a good approach, of course, about how to communicate between these two parts that at the end, as you mentioned, all of them are important, right? Like a big vision of business. Yeah, we need all these levels. For sure. And yeah, everyone is focused in different parts that at the end are complementary, of course. Yeah, so maybe I will try to play a little bit as a devil advocate of devil, let's say of, yeah, why? Yeah, if someone is listening to this and they are using something like scrum and... as a manager right and they are kind in love of this because they feel they have these daily meetings and they kind of feel they have control over their process because of daily meetings i feel like this is kind of well i've been working also in agencies and we were having these daily meetings which was a torture right any developer or this any developer or designer really didn't love this but the managers i think they will love it i i don't know maybe not but the point is Yeah, how do we remove that fear of control that maybe people have and one of the reasons of doing these daily samples or stuff like that? These things are, it's a very good question because these things are related to each other. When you work in a Scrum way of working, you know, you go into these planning meetings, right? And then you create all these tickets, right? And all the tickets, they're like separate work assignments. And what happens is whatever that understanding was that we might have had about what we're trying to do next, I think of it like putting the plan through a paper shredder. It's like we're taking something that we all wanted to do. And instead of understanding it as a whole, we're like splitting it apart into a thousand pieces. right? And then you give each person a different piece and you say, go build your piece. And of course, when we do that, it's hard to know what is going on, right? Because how do we know that the piece is fit? How do we know that what we're working on is actually starting to come together and do what it's supposed to do? And if we split apart the pieces too early, we actually cannot see how We don't really understand, actually, if we even have the right pieces. You know what I mean? So there are so many unknowns and so many questions throughout the whole process. And all of those unknowns and all of those questions, they're there from the very beginning because of the way that we split the work, because we use this paper shredder. So actually, if you have the paper shredder and you're working in this ticket style, You need the meetings. Because if you don't have these meetings all the time, how will you understand how the pieces fit together? So they're part of the same thing, right? It's more the paper shredder that's actually the problem. And the meetings are actually a compensating behavior that is very understandable reaction to that situation. If we try to get rid of the meetings, but we don't fix the paper shredder, then we'll just have chaos and nobody will know what's going on. Got it, got it. So the meetings are more like to make sure that everything, we can put the paper back together. The meetings are the replacement. Yeah, the meetings are actually the, exactly, they're the replacement for the shaping. It's like because we didn't shape and we don't really understand what the... project is as a single concept right of like this is these are the major parts and this is how they fit together and this is what we're doing because people can't see the whole then instead of that they have to have meetings all the time to try and understand each other and to try and understand what's what's going on but when you shape the project up front then you have like a map and everybody can look at the map and say i'm doing this i'm doing that i'm over here yeah i think i will refer also to another fear that i can see of potentially people using something like agile to to switch to shape up i think is i assume you could confirm it or not right it's like i will assume like the shaping or the framing don't have a fixed time right like and maybe managers wants to have this certainty that okay i will dedicate one week for this and I will get this output or this outcome right so yeah how do you feel into this how do we remove also that fear of that the shaping or the framing don't have a fixed time frame maybe compared to to something like what they call a sprint right into scrum which still is not really definitive it's have a build solution or something like that well i think in practice all work has a fixed time because we can't do nothing so uh if the team is going to start uh if the team is going to start on a cycle no matter what process you're using you have to have some work ready you have to give them something So there's always a deadline. Yeah, but I am referring more to the part of research we are calling framing, right? So how do you make sure that, let's say, okay, I will assign, I don't know, this lead of design or engineering, and they will do this research because it's something kind of a lot of unknowns, right, in the research, how much time it will take to actually do it, right? Yeah, how do you... communicate this to a manager towards to understand that okay maybe it doesn't matter to okay you maybe you have certain limits or range of time right but but maybe it will pass maybe or not right so how do you communicate this time by your ability there maybe in practice what works really well is actually to do the framing and the shaping in sessions so uh if there's something that we think that we're going to build instead of just jumping to building it or asking the designers to go make a bunch of figma files or something like that we can have a shaping session and a shaping session can be done in three hours and in three hours we can bring together a lead technical person a product person maybe a ux person And we can come up, see if we have a concept that we actually understand of what to go build. And when we, we, sometimes we come out of that three hours and we already have a concept, which is ready. It can also happen that we go into the shaping session and out of the shaping session, we identify very specific risks, like unknowns. So not like we don't know at all what to go do, but like. We think we want to build this thing, but we don't know if this library works with the API that we have, that we expect it to, you know, or we think we're going to do this, but we don't know what it means in terms of the performance load on this very important part of our infrastructure. And then there are very specific things that we can answer, which are like individual tickets we can actually create. We call these spikes. So we could have a shaping session and the shaping session produces, let's say, three tickets, right? And each ticket is less than, you know, let's say less than, let's say two to four hours of work, right? And it can happen asynchronously. And then we have the answers to those specific unknowns and we come back and we have one more shaping session and then we're ready. That kind of thing happens a lot in real teams who are doing shape up. So it's not that we have some kind of like long running exploration or something like that. It's more like there's something that sales wants us to do. You know what I mean? And so, like, what can we do? What can we do to solve it? Let's call a session. And instead of having, you know, a whole bunch of meetings all the time that are just about who knows what they're even about, we can have one very, very focused meeting where we figure out what it is that we think that we're going to do next about this problem, right? And this is a much more efficient use of time. Yeah, of course, it makes sense. Yeah, it's a really as you mentioned is really efficient for sure that you have this focus time and then yeah, you will see if you need other shape of Other shape in session or not right depending on how much progress you do And usually you like I said before Usually you you simply are running out of time because you have to do something So so this is the thing is that like we cannot just do research forever because we we have to do something the team is finishing the current project or the current cycle and now the next window is opening and now we have to decide what to do right so there is a back pressure there for us to to get together and and make decisions about about what's happening next good um yeah now i i will kind of switch gears to to more your experience and advice as well in general or work experience so okay yeah so you mentioned before about your mentors like both Moesta and of course Jason Fried and DHH as well so yeah if you can well if that's even possible summarize your your learnings out of them as a mentor from you so what is the most important that you have learned out of these people that if you have some kind of concept out of that in your experience so um i i there are a lot of lessons but i'll just pick a couple that are at the top of my mind um i would say a very clear lesson from jason is don't overthink things um uh we had this um back and forth where his instinct is just to act immediately. And then my instinct is to analyze something. And if I am too much analyzing, then it can become like this thing that is just getting more and more complicated and nothing ever happens, right? And on the other hand, if we always just act without thinking, then we can get into situations that we could have avoided, that we might not want, you know? and so um i really learned from him um he like kind of i like how to describe it it's like uh it's a little bit you know like the like the angel on your shoulder that is like saying to you something you know it's it's like like don't overthink it don't overthink it don't make it too complicated you know this is like uh specialty of jason this is very good um david i think is um among many things is a master at making really hard trade-offs of giving up something to get something else you know it's easy to to say yes to something if it has everything that you want but it's really hard to say yes to something when in order to get you you have to give something up you know so for example if you look at um uh the trajectory of rails over the last five plus years there's this trend toward uh something called hotwire and the approach there is that the development time can be much shorter if you are willing to always make a trip to the server to get a response and this is something that many people who are working in other frameworks like react and stuff like that they're they they they they don't want they they're not willing to do that and because of that they have um different trade-offs, you know, and one isn't better than the other, but it's really hard to say, I'm going to always allow that trip to the server. And it means my app will never work offline and the app will never work in a local first way or something like that. And, but because of that, there are major productivity benefits and that's something that that's. a really kind of a hallmark of a lot of decisions in rails that there's those very difficult trade-offs and he really sticks to them because he knows the advantage that he wants to get and what he's willing to give up so that's that's a big lesson and um from bob uh there are a lot of things but i guess the the key thing is to always see the difference between the demand side and the supply side the demand side is um is what are people actually trying to do? What are they struggling with? And the supply side is like, what are we building? And we tend to focus so much on just the idea of what we're building, you know? And we need to be able to shift into this totally other space. It's like the supply side is like the sail of the boat and the demand side is like the wind. And we have to have both. you know and we have to bring the two together and so um for me like all of this stuff about framing um uh and doing customer interviews and all of that that came from kind of having my eyes opened to to this demand side and that's kind of his expertise um but but in particular this trick of at any given moment being able to understand which side of the coin we're on you know and when to flip over to the other side in order to solve a problem. I would say that's the key learning from Bob. Yeah, it's kind of how to decide what to prioritize depending on the context or around that. Well, priority can mean different things. So sometimes we're building something and we know what the customer wants, but we have to make a priority in terms of, you know, uh do i wait for this other person to become available to do the code or do i use the more junior person or like there there's all kinds of trade-offs that can be made in the supply side right i can spend longer on it or i can and i can i can get it this way or i can spend shorter on it and i can do it this way or you know there's a lot and and versus there might be a different thing where i have two different projects and i don't know which one the customer values more so which one do i prioritize right Or I have a trade-off and should I have more steps where each step is really clear, you know, or should I have fewer steps and the page is more complicated, but it all happens on one screen, right? And I have to understand how do I decide? And then I can look at it from a supply side and say, one of these things is 10 times easier to build than the other, right? Or I can look at it from a demand side and I can say, the customer is going to have a problem with this one versus the customer is going to succeed with this other one right or uh so this is a different ways that we can we can we can flip it around okay uh ryan i think we are on time now but do you have like 10 more minutes if that's okay for you are you adding a rush to go i can give you 10 minutes sure okay yeah thank you for that um yeah so Yeah, so you mentioned how important are for you these mentors which you have been working for a long time, right? So do you think, do you have any recommendations towards if someone is looking for a mentor, what is the right mindset or approach towards having a mentor? Is something that you ask then personally be my mentor or do you believe it's more like, yeah, depending on the job where you are and stuff like that? I actually think that mentor is a word that you use after it already happened. It's a word that you can use to describe the effect that somebody had on you. And if we try to say, will you be my mentor? I think it's actually quite artificial. You know, it's a little bit like saying, will you be my friend? It's like, well, let's see how it goes. you know and then but after you after some things happen you can say that's my friend right and so I think it's more about the attitude of being curious and really being open to what other people have figured out you know really having this this this interest and curiosity and respect for people who are doing things well, you know, and to really look and say, wow, how do you do that? How do you manage that? Like, tell me more or show me more or help me to see better. And when we have that attitude, you know, sometimes we will go to people and they will be really glad that someone is so interested, right? Because most people don't really, appreciate what they're doing and that's a really nice combination when someone is very experienced and and and they themselves are really passionate about something you know and then someone who is less experienced but who is also smart and interested in the same thing and and says hey like i want to i want to do what you do and and and i want to kind of play the same game you know um then it can be a really fun relationship because actually both are learning and um and you're both learning about something that interests you both that's like somehow really exciting topic for you both you know so i think about relationships in other areas like um a lot of musicians who are really great musicians will tell you about a teacher that they had who was really important to them or um um sometimes really great scientists will tell you about people who were very influential for them who were kind of um you know someone who really like shined that light in such a way that they said oh wow you know and they got a lot of inspiration and and and a lot of guidance like that so i think we um These relationships, they are in every area of our lives and they really make us rich if we look for those and we try to build those. Yeah, thanks for sharing that. I mean, it's really valuable, of course, as you mentioned, to work with people that you admire and also that you can later reflect that, okay, wow, this guy actually was my mentor because of all this guidance and knowledge that now I'm collecting for my next experience. um now maybe talking more maybe not um a mentor like a person or in person experience or something but more about resources which kind of also are kind of guiding or writing our way so do you have any specific podcasts or books or any other type of resources that you love to follow in in your life yeah my for more than 20 years i've been a really close student of christopher alexander's work That's been a big source for me. I still probably once a year have a phase where I go back to his work and look for something new or look for some perspective on something that I'm doing from his work. So he's been a huge inspiration to me. Eric Evans, his work on domain-driven design was a really big influence. I was very inspired by Kathy Sierra's work, especially all of the work that she did on her blog. I think it was called Creating Passionate Users or something like that. And I'm not sure if it's available still online. Maybe there's an archive of it, but that would be really worth it. She's amazing. She was a big inspiration. Yeah. I'm always looking, too, at people who are good teachers. I was really impressed recently by Andre Karpathy's YouTube videos explaining how, how kind of machine learning things work. So, you know, of course I've been, I've been following kind of all of this, all this AI stuff, you know, and it's been super interesting, but he's been so far my favorite kind of real like hands-on kind of. reference or resource great great and do you have um any specific podcast that you kind of listen to weekly basis or something like that or it's not something you actually do with these days i don't have anything that has like stuck you know what i mean i i tend to uh So what happens is more like I'll become interested in a person and then I will go and find a lot of podcasts with that person, you know, and then try to learn what I can learn. And then and then so I usually follow topics and people more than shows, actually. Yeah. OK. And so. following on that so what topics are you currently checking out so like for your future if we can talk about that of course for one minute or something sure um uh yeah so like okay like so for example i um like so many other people you know found out about um nvidia and jensen huang because of everything that's been happening and i happened to hear an interview with jensen huang on um on um ben thompson's uh stratechery uh and i i like to listen to the um i don't i only listen to a a small percentage of them because but i i i really appreciate his um his interviews and whenever he publishes an interview i usually add it to my podcast but i don't often Make it to actually listen, you know what I mean? But if I if I recognize the person and Ben Thompson interviews then that's a really good combination because I really I think he's excellent and I really like his interviews but I heard an interview with him and Jensen Huang and And then I was like wow this guy's amazing and then I went through a I probably listened to 10 or 12 Jensen Huang interviews of different kinds, you know until I started to hear the same things over and over. And then I said, okay, I'll try again after some more time passes maybe and there's some new things, you know. So that's the latest example. Great, great. Maybe as a last remark for today, so is there something that we haven't talked today that maybe you would like to at least leave it there as a reflection for the audience? Maybe one thing that would be... useful just because we've been talking about things from the perspective of a product manager you know and one thing i think that is really nice to see is when a product manager can make the transition from being very busy with the builders you know to make sure that nothing goes wrong and when they can start to have more when they can start to have um more time for framing I think actually that the framing is where the product managers can really add value. And more this delivery management stuff, you know, it's a kind of inefficiency, which isn't really fun for anybody, you know. And so one of the things that I'm really most happy to see about the teams who are starting to use tools from ShapeUp. is that this balance starts to change where the product people are spending less time in the delivery cycle and they're spending more time figuring out what is important to do next and doing that framing and shaping, especially the framing. So I'm seeing a healthy trend also where the technical people, so the engineers, are moving more leftward into shaping. Because actually it's very technical. It shouldn't just be Figma files. It should really be more how the parts fit together. So the technical people moving more into shaping and the product people moving more into framing, this can be a very, very nice place where everyone feels like they are doing more of what they're good at, you know, to make the company stronger and to make the projects go well. Yeah, that sounds like a real game changer for... for the focus of everyone and strengths, right? Yeah, so last point for today, can you tell us how can people reach you out and know more about you and also about, well, your company, Felt Presence, right? Yeah, so they can visit my website, feltpresence.com. I'm RJS on X and I'm also on LinkedIn and you know you can email me uh the emails on the website or just message me on one of those platforms and i'd be happy to hear anybody's questions or i love just hearing about what people are experiencing and you know kind of what they're trying to solve from wherever they are in the in the situations they're in so please feel welcome to reach out with questions or comments and and i'd love to be in touch Yeah, maybe since you are mentioning about the future, right? Like shaping in real life. So do you have a cohort coming soon or what can you tell us in a short time about that? Yes, sorry. The next, we just opened sales actually for the next cohort and the next cohort is in January. We have as of right now, 10 seats left. So I don't know how soon your podcast goes out, but as of right now, we have 10 seats left for January. And then if they don't make it for January, there's a wait list. You can sign up the mailing list. You can go to feltpresence.com and then click on Shaping in Real Life. And then there's a waiting list to find out about the next cohort. Okay. So you have made me compromise. I need to release it as soon as possible. So you will have more people interesting in your course. So, well... Thank you very much, Ryan, for your time today. It was lovely to talk and I hope you have enjoyed as I did. And if you have any questions or anything, of course, feel free to reach out. And I think everyone in the audience will be happy with this conversation and hopefully we can be shaping more in our digital products. yeah cool thank you very much and you had really great questions and i especially like all the devil's advocate questions those are very interesting so thank you good thank you and see you around cheers

Meet Ryan Singer, the friendly mind behind the book Shape Up, founder of Felt Presence, and the former Head of Strategy of Basecamp. He's all about helping product teams create awesome software products that make a big impact, all while reveling in the excitement of building.

In this chat, Ryan shares his experience from his 18+ years at Basecamp, explains how the Shape Up framework came to life, and highlights the fantastic perks of shaping up your projects. He dishes out advice on diving into Shape Up, warns about the pitfalls of agile frameworks like SCRUM, and shares golden nuggets from his mentors - Jason Fried, David Heinemeier Hansson, and Bob Moesta. Plus, Ryan clues us in on the people and resources that keep him growing personally and professionally.
Ready for some valuable insights?

Stay connected with Ryan on LinkedIn: ⁠https://www.linkedin.com/in/feltpresence/⁠