#38: Shaping up to deliver big and meaningful software products | Talk with Ryan Singer - Author of the book Shape Up, founder of Felt Presence, and former Head of Strategy of Basecamp

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 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 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 shape up. Evolved from all of my experiences at Basecamp over those years because we always had this kind of urgency, this kind of exciting, kind of 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 want to 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.

Hey, everyone. Welcome to the Opera sky podcast. My name is Ricardo Bonegas and I will be your host on this podcast. We would like to share valuable knowledge, lessons learned, and stories from entrepreneurs, investors and managers while running their businesses. We strive to ask the right questions and discover insight from our guests so you can apply them in your business and life right after each episode. Thanks for joining us and let's get started. Hello everyone. Today we are talking with Ryan Singer. He is 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 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 UI and that's kind of the place, you know, between the human and the software. And then I became kind of the bridge between the design and code inside of the company. So I became kind of, I learned kind of to be also the interface kind of between teams and expertise in a way. You know, how do you actually connect these different functions together of 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, and the, and the market and your ability to build and design things. So 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.

Great. 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, 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. So, well, as I mentioned and in the intro, so you have been working on Basecamp as a head of a strategy at the end. But you, as you mentioned, you started from, from design and user interfaces and stuff like that. Yeah. So based on that, now, since you have been creating this process of J Pop, what legacy would you like to get out of this J Pop? Imagine in the next 10 years, what would you like to see in the market with J Pop?

You know, I'm very pleased that we're already starting to see an impact. I'm. 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, And all these 10, 15 years ago, these tools like Jira and stuff were that they felt like, like fresh things, you know, and today it's, you talk to people who are doing all of these Scrum rituals and it's like, oh, we have to have all these long meeting, 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, my team is doing Shape up or we're doing parts of shapeup or we are inspired by Shape Up. 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 J Pop 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 strong 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 they started 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 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 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 shape up. Evolved from all of my experiences at basecamp 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, 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 want to 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 Basecamp and then this is something that I formalized into Shape Up. So how do we actually look at our development process, you know, 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, and where we actually want to drive the business from a strategic side?

Okay, yeah, of course, it's really interesting approach. Of course. And what other processes did you try before deciding, let's trash this and let's sit down to create Shape Up. Do you have some moment in Basecamp collaboration that you decide, hey, Scrum is not working, Kanban is not working or waterfall or whatever other problem process?

Well, I think it's different when you're inside of the process versus at the end of it. You know, now that Shape up 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 Shape up 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 when you're inside of a small team and you are, you are experimenting together, then 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 one thing we knew was that a two week sprint wasn't going to work because you can't actually finish something big. You can't really build something big in two weeks, you know, and we needed to be able to see the Finish of things. So this led to kind of a longer way of working where we. Where we were working more in six week cycles. But 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, 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 what is it that we're actually doing? Do we understand the concept? Can you explain 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, you 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 were saying. So, yeah, my question next will go towards. Okay, I understand that in the shape of process, you have first this initial step which is actually shaping up. Right. This call. And basically you are making a small structure of what you would like to built or. Yeah. Around the product. Right. So, but the question for me is what happens before that? Like, how do you decide what to go to a shaping session? Right. So what? 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. And 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. I 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 basecamp 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 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, 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. 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, 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. It's more like just turning the light green, you know, or. Or. Or hitting it with the stamp and say, yeah, this is good. Let's. 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, because 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 what I do with that feedback, I cannot just suddenly change the roadmap every week, right? So. 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 the structure that you're in. So 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, 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, 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. You know, so there's some amount of space that is like your choice that you get to use, right? And there's some amount of space that is not your choice because it's already something else that's on the roadmap, right? So wherever you have the open space where the question is, oh, here's. So maybe, 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, you know, and the, the framing can happen also on the, on the, 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, then you're going to be in the back of your mind trying to come up with what's the thing that I'm going to try and do as soon as I have a chance. And so that's the framing work, you know, and it, and it might not be monthly or weekly. It might be more that you have a running process that is like your, almost more like your private process of 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 teams. So is there any specific size of teams 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 J POP 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 these 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, no matter 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 is, 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, 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 Shapeup 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 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 Shape up 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. 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. 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?

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's. 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. 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 Basecamp 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, let's say, imagine we are, some of our audience is early stage startup or. And is 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, you might be in a, 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, 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, we're going to talk about strategy because they, 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 the picture here? It can also happen that you build something. And this happened to me at Basecamp. 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? You know, 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, okay, maybe 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 basecamp, 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, 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, you can't. You can't invest in building a year and then find out at the end of a year if your idea has any traction or not. Right. So you have to be very, very resourceful in order to use that method. Right. But it's also possible to do it like that. Yeah. So that's on the qualitative side then. The quantitative side is where 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 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. It's a big area. Right. But that's, that's kind of the rough starting point. I would say to. 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, do I understand what the problem is or not? Right. 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, you know?

Got it. Okay. Yeah, I think. Well, of course I can go in multiple directions thanks to this answer. So it's going to be interesting. But I think 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 maybe at the beginning. Right. Because they are too fast. Fix it into certain vision or product idea or stuff like that, which is something I see a lot, that people get in love with the solution.

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 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 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, or it can be from established companies, but they have an idea to build certain tech product. Right. They are already kind of fixated toward, okay, this is what they want. Right, okay, but, but they, but, but they haven't done any interviews. They haven't confirmed that it's, well, yeah, 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 cope?

Yeah, I don't try to do that. It's their money. Yeah, no, when, 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 when, when, if I have something that I want to do and I just want to do it and I, 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, if we see that, that, that there's a business person who is actually struggling to make the decision about what to do next or, you know, 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. Right. But they need to, 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 problem. It's really, it's just, 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. 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 take that big idea and let's make first a shape up what is possible to be done in the. Let's say in the six week cycle as you said. Right. And of course in the six weeks we are not going to build 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 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 viable scope is an important thing that we should do.

Yeah. I don't try to sell it. I talk about the problems. So if they're having trouble finishing things on time, if they're moving too slow, if the way that they're developing isn't going to scale because there's no kind of repeatable structure to it, you know, those are the moments when people are interested in learning a new way. 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 J Pop or changing their way to, to build.

I've seen kind of three, three main problems then 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. Yeah. People say why can't we finish things? We have to do something different. Right. The second One is when it's time to hire more people or you are trying to grow and you, you, you can't, 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, if you've seen Scrum and you've seen other things, you're like, okay, but I don't want to tell, 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? 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 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. You know, if you're an individual PM or you're an individual engineer, you are 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 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 buying into changing their way of work, right? 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 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 the product will be in Q1 will be X with this feature, this problem and in Q2, this problem, but you haven't even started in the framing or the shaping of that. And imagine that in the framing and in the shaping you discover, fuck it, I shouldn't be doing this, I should be doing that. How do you change the communication or the mindset of a company? Also because there are structures 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 a 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 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, 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, why are we here? What are we spending our, what are we spending it on? You know, and 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, 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, 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 and 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, to, to focus the, the, 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, leaving enough latitude that we can still formulate what the individual projects are so that they kind of accomplish those, those higher level goals.

Yeah, that's, yeah, that's a good approach of course about how to, to communicate between these, these two parts that at the end, as you mentioned, all of them are important. Right. Like a big vision of.

Yeah, we need all these levels for sure.

And yeah, everyone is focusing 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 a scrum and as a manager, Right. And they are kind of 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 is they will love it. 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 stamp pots or Something like that.

Well, 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 are taking something that we all wanted to do, and instead of understanding it as a whole, we are 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 pieces 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 used this paper shredder. So actually, if you have the paper shredder and you. 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 tried 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 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, of that the shaping or the framing don't have a fixed fix it time frame maybe compared 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 if the team is going to start, 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 their 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 too much. 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 these time variability there?

Maybe in practice what works really well is actually to do the framing and the shaping in sessions. So 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 do, 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. And yeah, it's a really, as you mentioned, is really efficient for sure that you have this focus time and then you will see if you need other shape of other shape pin session or not. Right. Depending on how much progress you do.

And usually you, like I said before, usually you simply are running out of time because you have to do something. So this is the thing, is that we cannot just do research forever because 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. So there is A back pressure there for us to, to get together and make decisions about what's happening next.

Good. Yeah. Now I will kind of switch gears to more your experience and advice as well in general or work experience. So yeah, so you mentioned before about your mentors but 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.

I, there are a lot of lessons but I'll just pick a couple that are at the top of my mind. I would say a very clear lesson from Jason is don't overthink things. We had this 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. And so I really learned from him. He like kind of. I like how to describe it. It's like 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 specialty of Jason. This is very good. David I think is 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 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 have to give something up. You know. So for example, if you look at the trajectory of Rails over the last five plus years, there's this trend toward something called Hotwire. And the approach there is that the, 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're not willing to do that and because of that they have 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. But because of that there are major productivity benefits. And that's something that's 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 from Bob, 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 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 and we need to be able to shift into this totally other space. It's like the supply side is the sale 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 for me, like all of the stuff about framing 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. But, but in particular, this trick of in 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. That's, 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, there's the, the 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, 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'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, I can look at it from a supply side and say one of these things is ten 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 so this is different ways that we can, we can, we can flip it around.

Okay, Ryan, I think we are on time now, but do you have like 10 more minutes if that's okay for you or you are in a rush to go?

I can give you 10 minutes. Sure.

Okay. Yeah. Thank you for that. Yeah. So, yeah, so you have 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. Towards having a mentor is something that you ask them personally. Be my mentor or 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, how do you manage that? Like, tell me more or show me more or help me to see better. And when, 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, then it can be a really fun relationship because actually both are learning and, 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 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 sometimes really great scientists will tell you about people who were very influential for them, who were a kind of, you know, someone who really like shot, shined that light in such a way that they said, oh, wow, you know, and they got a lot of inspiration and a lot of guidance like that. So I think we, these relationships, they are in every area of our lives and they really make us rich if we, 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 experiences right now. Maybe talking more, maybe not a mentor like a person or in person experience or something, but more about resources which kind of also are kind of guiding us, guiding 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, I. 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. She's amazing. She was a big inspiration. Yeah. I'm always looking too at people who are good teachers. And I was really impressed recently by Andrej 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 any specific podcast that you kind of listen to weekly basis or something like that or is not something you actually do these days?

I don't have anything that has like stuck, you know what I mean? I tend to go to individual. 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 and learn what I can learn. And then, and then, so I usually follow topics and people more than shows actually.

Yeah, okay. 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. Yeah. So like, okay, like, so for example, I like so many other people, you know, found out about Nvidia and Jensen Huang because of everything that's been happening. And I happened to hear an interview with Jensen Huang on, on Ben Thompson's Stratecherry and, and I was, I just, I, I, I, I, I like to listen to the, I don't, I only listen to a, a small percentage of them because, but I, I, I, I really appreciate his, 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 inter interviews, then that's a really good combination because I, 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, that's as much, that's, I'll try again after some more time passes maybe. And there's some new things, you know, so, 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 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 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, you know, 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 Sigma 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 the focus of everyone and. 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 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 I'd love to be in touch.

Yeah, maybe it's since you are mentioning about the future. Right. Like shaping in real life. So do you have a cohort coming soon or. Yeah. 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. Of 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.

Thanks a lot.

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 good. Thank you and see you around.

Cheers.

Thank you very much for joining us. We hope you have enjoyed this episode and gained valuable insights. Feel free to share with your friends and looking forward to seeing you next time. Sa.