A better way to plan, build, and ship products | Ryan Singer (creator of “Shape Up,” early employee at 37signals)

25:35So you guys are going to build, you know, the newsletter okay? But you only get six weeks to do it. So use your fixed time, vary your scope and enjoy your responsibility, you know what I mean? Which is just cruel, right? Because I think a quote, Bob Nesta who's been on your show a couple times, you can't put 10 pounds of crap in a five -pound bag. So, high academic statement, you know, and we can't just take any project no matter how giant it is and then throw it at a team and say, figure it out and ship something meaningful in six weeks by cutting away scope, right? So it starts to, it starts to raise questions about how do we actually decide together what this project is?

26:25Do we actually have clarity around what the idea is and what we're going to build, you know? Let me follow up in a couple of the elements. So, appetites, I think for any product manager, engineer designer, anyone that is like experienced, okay, we're going to, we estimate this, the landing page can take a couple weeks. Great, let's work on it in the minutes of being six weeks. Can understand why this makes sense. It's just like this landing page is not that important to us. Let us just say we will commit two weeks to it, we'll do as much as we can in two weeks and then we move on and scope is not allowed to go beyond that.

26:58Makes total sense. Like, this just makes so much sense as you listen to this, especially for people that have just fallen to the problems of estimates not being accurate. Then there's a six -week element and the key there is your, and this is kind of counter to maybe two weeks sprints like Scrum is that kind of the, where this comes from? So, you know, actually, it turns out that the six week is only a maximum. And that's really where this number does some work for us. If we think of six weeks as a maximum, that's going to force us to ask some really good questions to ourselves about where do we actually, what, what piece of this do we really think we can land?

27:39Because if you try to say, you know, in six months, we're going to ship this thing, you can't get your arms around, all of the problems that have to get solved for an entire six month chunk of work to actually happen. There are so many unknowns, there are so many ticking time bombs of things that we didn't understand or couldn't foresee, you know? But if we set a ceiling at six weeks, we have a much better chance of, I think that's a size of something where we can actually shape it and surface enough unknowns and reveal that complexity before we're in the middle of it, right? It doesn't mean that we can't use this technique to do a two week project, you know?

28:19Especially if you're on a gross team, you don't want to wait six weeks or, you know what I mean? You're going to have to artificially bundle things together to do six weeks. It's like, look, I've got, I've got something I want to, I want to ship in the next week. And then I've got a thing that might take two weeks after that, and then a week after that, right? So, it's more a question of what we're trying to take on, you know, it's really that upper limit. Okay, so it could be two weeks, cycle. It could be a two week thing. Cool. So it's like, we're going to build a sneil landing page, we're going to give it two weeks, and then the other shaping session on that.

28:48Now, the other thing, the other side of that is when it comes to feature development or, you know, building something that's going to be needy enough to sell, you know? Then there's very few things that are going to be a substantial value add to a product that you can do in two weeks, right? So then you get into a point where, well, now we're just kind of sprinting and we're just kind of taking one bite after the other. And then that's where we can land in that situation, where we feel like, I can never see the end of this. I just keep going back and saying one more sprint, one more sprint, one more sprint, right?

29:23But six weeks is long enough chunk, or sometimes four weeks, that the question is kind of what's big enough that we can actually get somewhere with this amount of time, right? And there's an implied element to this that I think is worth highlighting. The whole idea is you commit to the appetite, and if you are not on track to hit that instead of extending the date you cut in order to still hit it. This is a tricky one. So you're right that it's implied, but the thing is in real life, if you make a commitment and you get alignment that we are going to spend six weeks of engineering time building this thing, you know, if you get to that end of that six weeks and something is going wrong, you know, it wasn't shaped, we can't see the end of it, it's more complicated than we thought, all these different things.

30:17And by the way, we can also talk about kind of why those things happen, you know? But when we get in that situation, if we're at the end of the six weeks and it's not looking good, I mean, we can't just cut off what we agreed to that made this thing valuable, you know? We can't just like cut the scope and say, oh, well, now we manage the ship inside of six weeks, that's going to kill everybody's morale. Everyone's going to feel disappointed, we're going to feel like this wasn't really worthwhile. And now we go into the next cycle with this kind of like debt feeling, you know, that we didn't actually finish the thing, we were kind of supposed to finish.

30:51So now we're like over time, you know, none of that is good. And if we also go the other extreme and just say, well, like we actually we say in the book, you know, we had this principle at Basecamp, which was this notion of the circuit breaker. Like if a project is not on track to actually finish after the six weeks, we're just going to cancel it and rethink, you know? Almost no teams have the stomach for that. But the version of that that's more stomachable is look, we can't just we can't just cancel the project and then say, let's see what comes next, right? But what we can do is say, we're not going to keep reinvesting in something that we don't understand.

31:33You know, so let's take this out of build mode and bring this back into shaping mode, which might mean different people, a different conversation asking different questions, you know, suss out. Like what is it that's fuzzy here? What is it that we couldn't see? Like what do we not understand? That's right. How do we get to the clarity that we need so that we can actually say, like this thing is going to happen if we give it another whack. And let's just how real this approach is, not this like theoretical, okay, cool. After six weeks, you just, you scope and it's all that's cool. Yeah, you just cut the scope, you know?

32:11Yeah, no problem. But you got you got I've seen some shape up adoptions that looked like that, by the way. And that's it's, you know, it's that's that's not the way we the shaping step is crucial. And what you mentioned with your landing page example, by the way, it's so seductive because we can imagine, you know, oh, you know, Parkinson's law, right? If you give me six weeks to do the landing page, I'll find a way to use it. But if you give me two weeks, you know, then I'll stop after two weeks. But when it comes to real product work, you know, where there's some functionality that we have to figure out how to make it exist.

32:50We can't just cut the scope if we run out of time. So what it means is that the shaping work is really working hard together to figure out what are the main moving pieces of this thing. Right? How do we narrow down our understanding of the problem? And how do we identify what the moving parts are of the solution? And like what actually connects together for this feature to work? You know, and when we really get to the level where we can say, oh, we need to do this, this, this, this. And then the engine is going to turn, you know, that's that's the place where we can say, this is well shaped, you know, and that's it.

33:31That's a it's a different kind of work. We in shaping in real life, we call it, you know, we actually teach it as doing live shaping sessions. And this is how I did it for years with Jason, we'd get into the room, you know, and I had both the technical and the UX side. So the both sides were kind of represented there in one person in that case. But for a lot of teams today, we actually teach them how to bring the kind of the the senior engineering person who isn't just senior in title, but you know, like the one who actually knows where the bodies are buried, you know, like how the old stuff works and what's truly possible and what's hard and what's easy in our infrastructure, like the person that really knows, right?

34:12You ring that person together with the product person who deeply understands the backstory of why this is an opportunity and what we're trying to solve with this, you know, and then a designer in the room and they're like whiteboarding and wrestling with each other to get to what's a version of this thing that we believe in that's real that we can actually finish in that time. This is great. Let's let's go one level deeper on this shaping session. So if you tack to questions, how long are these sessions? It sounds like the people that join are the designer in an engineer and an MPM. So add anything else there.

34:44And when do they happen? Is it at the end of a site? Do you call a cycle by the way or sprint this six wish would period what I actually like is time box actually because the thing is that some teams need regular cycles because they have parallel teams and they need that cadence in order to kind of reduce management overhead, you know. But if you're small and you only have like one or two teams, you might not need to be on a fixed cadence or a cycle plan. You might be able to just set one time box after another, right? So the key thing is actually that that time is pushing back at you and that you're being intentional about kind of what's my time budget that I need to shape into.

35:24Let me take a quick tangent because if you're that's so interesting that time boxes can be very different lengths. Imagine at a larger company this gets complicated when other teams are trying, there's dependencies and timelines launch, go to market dates and all these things. What's like the largest company this this approach has worked at? Like what's the ideal company stage for shape up? It can function in very large companies. We have for example, I have some friends at a there, what is it called? They're doing clinical trials so they're in the pharmaceutical industry and I mean the companies, you know, thousands of people and it's not that every team is doing this but they have a few teams that are working in important areas, you know, and they're doing this and it's completely possible in that context.

36:16If you have someone who's at a senior level on the engineering side who is able to make the right architectural choices and also do some some negotiating and kind of be the backstop to make sure that someone isn't going to get pulled away onto something else. You know, you can kind of carve out of this system can be worked on independently of that system. This was actually what David at Basecamp has always been amazing at is this dependency how it's actually not it's not so many people are used to it and they think that it's just how it is but it's actually not. It is possible for engineering leadership, good engineering leadership untangle things.

37:00So we can work on this system without having to be thinking about this other system somewhere else, you know. So when you have some untangling with your infrastructure and with your architecture from an engineering standpoint, then you have some freedom and then if you can also figure out the capacity management side of I'm going to protect this team from that other work for this number of weeks, you know, you can really get a lot done. This insight that you can operate this way at a larger company and the whole company doesn't have to operate this way, I think is really freeing to a lot of people.

37:30What's kind of like the adapter and I want to come back to the actual shaping process but I can't help but ask this. Say the company's operating like a quarter of the cadence or six month cadence and then there's like a team operating on a two week sometimes six weeks, sometimes four week cadence advice on how to like what's the adapter that connects those two cadences. So there's kind of two different things. So like I've seen cases where they've decided on a like a four week plus two week or like so they'll do like a like five week and then one week of cool down in between and then they they they time it so that it adds up to a quarter.

38:07You know, I've seen that. The other thing I've seen is when the team is just continuously delivering meaningful things, it doesn't have to line up because from the executive level, if you are CPL or CTO or I mean in these bigger cases it's more like you know VP in some area but you're coming to the table where you're supposed to be reporting of what your group is doing and when you are consistently saying we said we were going to do this and nothing finished and now we're doing this and it's going to finish and the next time you say we said we were going to do that and it's finished, you know, without excuses and we thought well maybe another few more months or you know we're working at it like that.

38:47I mean that's what that's what everyone wants to see is that movement, you know. Yeah, if you're doing great people will leave you alone. That makes sense. For sure. For sure. I love that point. Okay, coming back to shaping one maybe one way that would make it really easy for people to understand what's the output of the shaping session. The output of the shaping session is so and by the way about shaping session, you know, let's maybe we can talk a little bit about what shaping is not, you know, because we need the contrast sometimes. So very often when people try shape up what I see is a product team kind of creating either a lot of figmophiles or maybe a lot of documentation, you know, like a like a PRD with a bunch of requirements and a bunch of backstory and good reasons why we're doing this and stuff like that.

39:39And what you see is that when you when you give that to a team as like this is what we shaped, what happens is like it blows up. So I mean you probably know about what happens when the figmophile makes first contact with the engineering team. There's a reality check that happens there, you know, and very often there's a kind of a back to the drawing board. So when there's a lot of solutioning all the way down to detail without engineering involved, usually that's a painful recipe, you know, and then it's kind of like no, we can't do that. Actually, it doesn't work like that. And then on top of it, the other big challenge is that there's so much that you can't see on the surface of a UI, you know, how do we flow from here to there?

40:27What are the different cases of logic? Like in which case do we move from here to here to here in the flow? Like what is happening behind the scenes? It's like the engineering team, they have to put on their x -ray goggles and like study this thing to try and understand like what's happening underneath, you know? I often use this analogy of like if you're doing a home renovation, you know, you can have like the most like a beautiful rendering of here's the new here's the new bedroom and we're going to have these lamps on the side of the bed, you know, that are coming out from the wall. These like, you know, and you can have the perfect rendering in the perfect lamp in the perfect color, but if you haven't checked if there's electricity in that wall there or not, right?

41:08It's going to drastically change the cost and the time and everything if you're going to have to rip open those walls to feed some lines up to those lamps, right? So what we need to do in a shaping session when it's going well is we come out with some kind of drawing or diagram where engineers, product and design are all looking at that and they're saying we understand that. I know exactly what to go build, right? I'll use the example of the calendar from the book. So what is a calendar? You know? So first of all, there was this work that we had to do before we could even shape it, which is like, can we actually narrow down this problem?

41:49In shaping a real life, we call this framing. And in the book, there's a chapter called setting the boundaries where we get into this. And it's like, look, we're not going to just build calendar, which is like Google calendar, you know, we who knows where it ends, we narrowed it down to we understand that for our specific customers who are requesting this again and again, it's more about I need to see empty spaces. And in the existing agenda view, I can only see things that are already scheduled and I can't see free spaces where I could book something. Okay. So we got to that point of like, so the what we're trying to solve here is the empty spaces.

42:27So that's a good frame. Then what are we actually going to build? We came to, here's a good rule of thumb. If it's shaped well, you can usually describe it in less than 10 moving pieces. Okay. If I can say it's going to have this, this, this, this, this, and this. And that's how we're going to let people see the empty spaces, you know, that's a good indicator that it's clear enough that it's that it's that it's shaped well. So in this case, we had a, you know, when you go to an airline and you and you want to book something, you see this like two month grid, right? So it's like, there's going to be two months side by side.

43:05But they're just going to have dots in them to indicate if there's if there's a free day or not. Or I mean, if there's something in that day or not, kind of like, you know, the iPhone calendar, I think still has this where it's just dots on the month view. And then if you tap a day with a dot in it or without a dot in it, there's going to be an agenda view that slides underneath, which is going to show you what's scheduled in that day, right? And then there's going to be navigation to go forward and back in the months. There's going to be a create button to create an event, right? And that's more or less, that's more or less it.

43:38So what you can see here is it's not like, what is a calendar? You know, it's not a calendar. It's a it's a two month dot grid with scrolling agenda view underneath, right? And the ability to hit new when you're looking at an empty space to create something and what you're viewing, right? So that's the kind of thing where that's shaped. And we can talk about what that means and what it entails. And we can have a really practical, realistic conversation about, is that a thing we can do in six weeks? You know, that's that's going to be a real conversation and not looking at a whole bunch of mock -ups and and trying to x -ray to figure out what's actually the intent here and what's really real and what's not and what's possible and what's not.

44:22That was a great example. This is really helpful. So if I were to try to describe this, essentially what you're coming out of it with a shaping session with is kind of like the user, the user experience with just like wireframes, slash sketches of the screens and the key buttons and flows. So it's kind of like the architecture with key components, not like a dock of spec and not final design and also not just like a user story. As a user, I need to be able to see empty spaces. Exactly. So because that's the thing where it goes wrong, if we're going to commit engineering time and it's like we believe there's some way to see empty spaces, but the way is a question mark.

45:08It's a really risky way to spend that time. Because you're committing, right? Yeah, we're committing and that time is really valuable. That's six weeks of engineering time. And that time wasn't easy to get in the first place, because of course there's all these other forces in the company that want to be doing something with the engineers. Right. You know, so if we want that team to be really using that time well, where they are moving, they understand what they're solving and they're creatively engaged because they know what it's supposed to be doing. Right? You know, they need to have that clarity both on the problem side of this is about the empty spaces and on the solution side of it's a dot grid with two months in a scrolling agenda view and a button.

45:51There's still a million interesting creative tasks there in the actual high fidelity design in the code, you know, there's so many things to solve there, but that is something that they can all hold in their heads and understand and work on. This episode is brought to you by AirTable Product Central, the unified system that brings your entire product org together in one place. No more scatter tools, no more misaligned teams. If you're like most product leaders, you're tired of constant contact switching between tools. That's why AirTable built product central after decades of working with world class product companies.

46:27Think of it as mission control for your entire product organization. Unlike rigid point solutions, product central powers everything from resourcing to voice of customer, to road mapping, to launch execution. And because it's built on AirTable's no code platform, you can customize every workload to match exactly how your team works. No limitations, no compromises. Ready to see it in action. Head to airtable .com slash Lenny to book a demo. That's airtable .com slash Lenny. You mentioned, and I think a lot of people listening to this are going to be like, oh, I'm scared of doing this is if you get too detailed, the engineers and designers on the team are just like, what the hell?

47:09You're just telling me what to build that sucks. I don't want to, I don't want that kind of work. So what's like, is the solution to that? The engineering lead was super involved in detail and the design lead was super involved. And so you can trust that it's that you're not just the code monkey building or anything they told you to build. That's really interesting. I got to tell you, the dominant failure case that I see in the real world is always again and again, not enough detail. And it's also the most common failure mode where engineers run back to the product folks and say, I'm not getting enough from you.

47:49It's really like that. But I can understand why the hair stands up on the back of the neck a little bit. You know, thinking about it because of course, if you give a senior engineer, like, here's how I want you to go implement the schema for this database change for this model. They're going to be like, what do you like wake or do you or you? But what's really interesting is it's not a universal thing. The amount of detail that the team is going to feel helps them is a dial that we can turn that depends on who's on the team. So if you have a more junior person who's on the build team and then you have a more senior engineer who's involved in the shaping, they can make that junior engineer much more successful with additional detail.

48:42So we're going to do this and I would suggest approaching it like this, this, this, and this. That junior person is when they don't know how to do it, they're not going to ask because they don't want to show that they don't know. And they're going to hide the fact that they're lost and it's going to blow up later in the project. And on the other hand, if they are given more guidance, they're going to be able to be successful. They're going to learn about, you know, this is how this person who knows well kind of approached it. And then in the next round or a few, you know, a few projects later, you can dial it back and say, well, let's give less detail and see how they handle it, right?

49:19So you can really give people bigger shoes to grow into and and help them to be successful. And then of course, you can also do it the other way around where if you've got some really stellar talent on the team and you have a long history and you have a lot of trust that they are going to be able to understand and solve it, then of course, you can leave things out, right? But the the the thing that I often see is if there's someone on the bill team who really feels that they should be involved in the fundamental decisions about the approach, then a better solution would be to actually bring them into the shaping and have them play that technical role in the shaping session.

50:00You know, if they're re if they have the right skills and the right perspective and the right knowledge to play that role well, then just bring them into the shaping, right? So it's all about how do we bring people into a moment where we are using their strengths, you know, and then we're giving them an input so that whatever their kind of work step is that they're able to apply the maximum creativity, but also have the maximum clarity so that they can really use that time well and also like feel good about what they're doing. It feels like the core of this is the risk, the biggest risks, and address the biggest unknowns as much as possible.

50:36Like there's probably this 80 % of here are the risks. Let's just understand them deeply before we commit to this appetite. That is exactly right. There are these, you know, we can call them rabbit holes, we can call them time bombs. There are these things where we say, oh, you know, it'll be fine. You know, like one example, like simple example, I worked with the team and they they had a step of onboarding in a FinTech product. Okay. And there was this step of onboarding and they would lose a lot of people in the funnel at that step because you had to fill out a whole bunch of information. And they figured out that they could actually pipe that data in from one of the partners that they had because they were partnered with banks and they're like, we don't even need to be asking people this, right?

51:19So we're going to, we're going to fix conversion. We're going to eliminate a step from our user experience. It's going to be great, right? You know, the thing that they didn't look at was if you go into the code on that step of the onboarding, it's not actually one step. There's like three different branches of that step depending on which bank the customer is is integrated on, you know? And so that's the kind of thing where it all sounds so great and simple. And then you get into the weeds and you realize like, oh, wait a minute. You know what I mean? So now we have decisions to make. Now, if you're in the middle of a project and it's already been resourced, right?

51:56And people are already on the hook that we're supposed to be doing this. And you already got the alignment that the engineering time is happening for this. And you're finding that out in week four. You know what I mean? You did all these beautiful drawings, by the way. And now you're finding this out in week four. Like that's a bad place to be. But if we're in the shaping room and we didn't kick this thing off yet, right? We didn't even green light the project yet. And we have an engineer there, not just the product people, not just the designer, but we have that engineer who really insists on.

52:29Sometimes I like to think of it, you know, like the grumpy old plumber who's seen everything. And he insists on opening up the walls and looking at the pipes before he'll give you a quote, right? So it's like, we've got that person in the room. They're saying, yeah, that all sounds great. Let's take a quick look at the code and figure out what screen you're actually talking about. Just let's just take a quick look. And it only takes a moment to open up the code, find this thing that we're talking about, and really look at it and say, oh, you know, it's more complicated than we thought. And now it's not like, okay, now we're screwed and the project is going to be bigger.

53:03No, now we can have a really cool conversation about trade -offs. So let's say we've got three different integrations here, three different segments integrated into different banks. How big are they relative to each other, right? In terms of the deals we made or the percentage of customers who flow through those three different conditions, right? If we just did this on one of those branches, would it be a win? You know, and like if we did it on all three, how much more time would we have to negotiate for? And would it feel worth it? You see, like we're getting into this horse trading of like, what is important, what's worth it?

53:39What do we need to get out of it? And that's really productive. That's and when you're doing that before the project starts off, that feels like, oh, we're talking about the important things. We're not failing right now. We are engaged in the hard questions that are getting able us to really ship something that's successful later. Let's go one level deeper on the shaping session because clearly that is so core to this working. And I know you'll hold book about like, how to actually do this. So we're not going to answer all the questions. And there's a lot of detail on new ones. But a few questions, how long do these usually take?

54:09It sounds like a whole day kind of experience. And then it sounds like you invite as few people as possible, but not too few people. What's your guidance on who should join? So we run in this shaping and real life course. We've been doing workshops where we try to help people to learn what it's like in a shaping session. And one of the things that's always interesting to me is how, so like, Katya and I will be running the session. And we have to like, people aren't used to working so fast, you know, to like, like, what are we actually doing right now? What's the decision? Like, what's an idea?

54:46Like right now, we're not going to go away and draw something. And then, and then all comment on a document and then come back and get together tomorrow. Like, what ideas do we actually have right now? Like starting from zero. So like, imagine, I like, imagine like, we, we've narrowed down the calendar problem too. It's about empty spaces. Right. We are willing from a business standpoint to spend six weeks on a whack at this where it's solved. We believe there's a way that's possible. So what can we come up with? And that's how you, that's the input to the framing session or sorry, the shaping session.

55:27Exactly. So that's so the, the having a narrowed -down problem from the framing work. And this is a whole other topic of, you know, very often the PMs are sometimes just taking something at face value and not negotiating down to really narrow down what is this really, you know, and where is the value in this? But let's suppose that that's happened, right? That we've narrowed down the problem. So now we've got a narrow problem. So now what we need to do is try out different ideas. And, and this is the real thing. We have to try to break them. So I want to draw an idea. And then I want the technical person to find like, oh, this isn't going to, you know, I mean, this isn't going to work because of this reason.

56:11Or the product person is going to be looking at and saying, I don't think like, I get that that's really an easy way to do it technically, but I don't think that we're actually delivering the value if I play through the customer scenario here. You know what I mean? So there's these different angles where the idea can fail. And one of the things that we also coach people to do in a session is not just to go down one path and then be sort of stuck in one idea. And now you're kind of going in circles around little details of one idea for three hours. But to really step back and say, here's an approach, you know, what if we had the scrolling agenda view?

56:48Okay. And that's idea A. Like, then what's what's a very different way of doing this? You know what I mean? Like, if we didn't want to have the agenda view there, like, is there a way to do this where it's just the month view? Let's like see if we can draw that. You know? So that's that's the kind of thing that's happening. You asked about the time. And I started with like, people aren't used to just going all the way in to actually trying ideas, you know? So there is a little bit of a learning how to just face that blank page and start trying things together, you know? What we find is that a three hour session can be very, very productive to help you figure out kind of what what do we already have that are possible approaches to this?

57:38What are some major missing things? You know, like, okay, I've got the calendar dot dot grid. I've got the agenda idea, but like, what about what about multi day events? Do you know what I mean? Like, so there can be these things these like, what about? So then maybe we break and we think for a little bit and somebody sketches some ideas on that and does a spike or two on something. And we come back again, you know, for another three hours, we come back the next day, right? And what I would say is if the project that you're trying to do is doable with, let's say, your existing technology, right?

58:19You're not inventing a new algorithm. You're not inventing some new database or you know what I mean? You're not doing a new new AI model. It's more about like, how do I use the APIs and the frameworks and the tech stack that we have? How do I put that together to build something? You know, then, you know, if if the problems clear and the time is now like, you will be able to come to a conclusion about what's possible to build in, you know, three sessions, something like that. You know, the key thing is leaning into those sessions and really wrestling with each other, you know, if you have just the product and the designer there, and and then it's kind of like, well, we'll show this to the technical person later, then it's it can all blow up and then you find out it's more complicated than you thought.

59:07You have to go back to the drawing board. We need to have the right, all the right, the necessary information in the same room for these sessions to go fast. There's so much genius built into this approach and it like sits on top of human nature. One is just you need to actually spend like, go into the deep edge cases and nuances and not just like, let me let me, yeah, that's fine. Let's go. More concreteness. Very concrete, very like in depth and the appetite. There's just like so many elements of this that just connect with the way humans work versus a theory of just like, yeah, well, it's not all in this will take.

59:46It'll be go great. And we'll figure it out as we're building. We don't need to really figure this out. Yeah, we don't have time for that. And we're solving a puzzle together. If it needs to be doable in this amount of time, but it also has to hit these points in terms of the problem we're solving, you know what I mean? It kind of has to do these things, but in this time and one other thing that I would mention is that we can't be drawing Figma files. By the way, I'm being very mean to Figma, you know, so far in this conversation, there is a time, right, when it's the right time for the Figma file, right?

1:00:24What we want to do is have that clarity around, you know, the, let's say we already know where the sink is going in the kitchen. And now we can make final calls about the tile and the exact fixture and stuff like that, right? And grout color. We don't want to have to throw it all away every time something changes, you know? So there's a time and a place where Figma is amazing and feels good. And it's like, oh, now it's beautiful, you know, now it's amazing, right? But in a shaping session, you can't collaborate on something so high fidelity, right? And so we need also some ways to collaborate.

1:01:01And this is where you see these techniques in the book, like breadboarding and fat marker sketching. These are tools to help us express an idea very, very clearly in detail, you know, we're going to hit this button and from this button go to here, this calculation runs, then we get this answer and then we have this choice to go here or here, right? Like that's the kind of thing that we need to be seeing. And that's that's kind of the sort of the level of detail where we can move fast together, but still see something real as more this kind of breadboarding level. Fat marker session is like very pocketive of what this whole session is about is like very high level sketches.

1:01:39That's a great term. The danger there that I often see is that what we don't want is to say, oh, Figma isn't the right thing at this level. So instead we're going to do fat marker sketches. And what you get is the equivalent of a blurry Figma. You know what I mean? Just less detail. What we need from a fat marker sketch for it to be valuable to us as builders is it has to really communicate the idea. So when I look at that, I'm like, oh, now I get it. Right? And if it's kind of more this sort of general wireframe of like, you know, dashboard goes here and there's going to be four reports. And it's like, I still don't know what to build.

1:02:21Right? So if it's not telling me what to build. So maybe this is a way to come back to your question about what's the output of the shaping session. It's like, it's shaped if we can give this to a technical person and they say, yeah, I know what to go build now. I'm very happy with our overview of the process. I think we've done a really good job giving people the gist. And obviously if they want to actually implement it, they can get the book and dive in or work with you, which will point people to say, someone's like, this is awesome. I want to do this. What would you say is a good first step for a team that's currently, let's say like they're in startup land and they're just like shipping every two weeks, maybe a week.

1:02:59So maybe for that bucket of folks. And then also for a larger company that's, you know, I don't know, agile scrum safe. And they're just like, oh, let's try some different. Sometimes dev teams, they like the idea of not having the scrum ritual. So they want to take in the six weeks. But unless the engineering and product come together to figure out how to collaboratively shape, like we talked about before, you know, that time box isn't going to go well. So I think they're going to not have to do stand -ups, but now it's like a day of hard thinking. It kind of turns into even more meetings because we don't know what to do.

1:03:40And the more meetings is just that shaping session specifically. No, I mean is that if we didn't, if we only adopted the, if we only adopted the six -week cycle and said, we're going to figure it out and we didn't adopt the shaping, then we just don't know what to do. And then we reach the end and we're basically scrambling to shape it as we go. And then we run out of time. And then we feel like this wasn't, you know, it was nice to get a break from the from the scrum rituals. But we can't say that we are, you know what I mean, knocking the champagne bottle on the boat because we're celebrating the launch, you know, or whatever, you know, again and again.

1:04:13Right. It's a good actually time to maybe talk about. There's obviously the sprint kickoff in scrum. What's like the main difference for people because they may be thinking, oh, that's just like a sprint kickoff. That's a good one. That's a good one. So what you often see in a scrum team is that there's somebody who creates these tickets. I've like, these are the things that are going to happen inside of the sprint, you know. And really in my opinion, too many cases, it's not the person who's doing the building who's creating those tickets. It's like a product owner. So there's a big, big gap there.

1:04:49There's a, we could talk a lot about that. But there's, there's gaps in context. The person who's writing the ticket doesn't actually understand the work that's involved. You know what I mean? So there are so many unknowns and time bombs waiting in those tickets that sound reasonable, but they weren't really created by the person who understands the work that needs to happen, you know. So the key difference is two things. So in scrum, you have, you have a person who's not the builders making tickets. And this is what in, you know, in the, in the cruel picture, is the paper shredder. In the shape up world, you have a single idea that was shaped.

1:05:32This is the thing we shaped, right? With the two months in the agenda view and da da da. Go make your own task. Because you're the professionals. Do you know what I mean? So like the contractors, you know, like if you're building a house, like they have to know the plans, but you don't have to tell them, now take the hammer and go over here, you know, that's their expertise, right? So in a shape up world, a kickoff is, uh, here's the well -shaped idea. And now this time box starts. And, um, at, at base camp, it was, it was really, really loose because I mean, they are just stocked with senior people.

1:06:09I mean, they have so many very senior engineers and all the designers are coding. They're very technical, really, really skilled people. And what I found is helpful when the team is a little bit more mixed, if they're not all super senior is a simple exercise of at kickoff, take whatever was shaped and just draw grid with nine boxes. And give me nine boxes of the nine major chunks that you think have to get implemented from an implementation standpoint. So like translate this into nine major scopes of implementation that need to somehow happen over the time box. So really, really useful exercise to kick things off.

1:06:50And we have a lot of teams doing that now, you know, if you take six weeks, that's like a 30 business days, you divide that by nine. It's like kind of like four days per box, you know, so you're going to get a lot of clarity from a quick exercise. And again, this is done by the builders. This is a really also good exercise for them to notice like, oh, wait a minute, we think there's too much scope here. Even though it seemed reasonable, when we put it into nine boxes, it's like, I, you know, I don't think we can do this all. Or it's also a good moment where somebody who's more junior might kind of describe their implementation approach.

1:07:27And then someone who's senior can review that and say, actually, you know, we've done that before and we'll run into this trouble if we don't use this other thing, you know, so those kind of really nice kind of coaching moments can happen. So this is like, if you were to try this approach and have a shaping session, this is a sign you're heading in a good direction is if the output, the team that's building it can come up with nine. And is it like more like does that have to be nine? Is it like six, cool, 10 cool? What I found is if it's if it's more than 10, then you just get into ticket land of here's a million things I have to do, you know what I mean?

1:08:05If you have a hundred things, it's like, that doesn't tell me anything. But if it has to be nine or less, you know, less, okay. I actually think I actually think I'm speculating here, but you know, the UX designers in your audience will know about this rule of seven plus or minus two. It's this cognitive science principle that was found about how many things someone can hold in their head at once. Yeah. And so this nine is the upper limit of seven plus or minus two. And it basically, you know, it's kind of like, do we actually have a picture of what it means to build this that we can also hold in our heads?

1:08:39Can we kind of see the whole castle? So what I'm hearing is like, if you're an adgel scrum team today, if you want to start trying this out, it's schedule us shaping session, assume it six weeks to start, try to get into it with a framing of like, here's the problem we're trying to solve. Is that a good way to think about it? Like the problem we're trying to solve? Yeah, for sure. The question is what problem we're trying to solve, you know, because the shaping work is more what are our options for the solution? You know, and if the problem is too fuzzy and big, if the problem is just calendar, you know, and the shaping is going to be this ever -expanding, never -ending thing, and we're not going to be able to get anywhere.

1:09:16Yeah. Okay. So you spend like three hours, maybe six hours, like in the first session, would you recommend like try to keep it to this many hours when you're first trying it out? No, I wouldn't do that. You know, I think the key thing is actually, if you get to the point where you're trying to hold a shaping session, and you manage to get product and engineering into the same room to do it, you are far along. You're doing great if you're at that point, you know. So much of the challenge is getting to the point of kind of aligning between product and engineering that we cannot have projects that are dragging and dragging and dragging.

1:09:59We can't keep ending in a place where like, this is the end of a sprint or the end of a cycle, and we still can't see the end of it, you know, or we have to make so many cuts and compromises at the last minute that it's not the quality of, or it's not really matching what it was supposed to be in the first place, when those problems are happening, or you know, also by the way, this is surfacing at the exact level. Imagine, you know, you're the CPO, you're the CTO, and you're supposed to be answering to, how's that work going, right? And it's like, well, actually, you know, we're working on it.

1:10:35I mean, oh, I can just think of a couple times when I needed to go to Jason, and he expected me to be making progress on something, and I had gotten nowhere on it, you know, and that feeling, you know, when you're with top leadership in the room, and you don't have a good answer for where you are, and something is like, oh, it's brutal, right? And then from the CEO's perspective, it's like, where's the movement? We're running a business here, like, really, nothing is shipping still, you know, this is, this can't just keep happening, you know? So there's some recognition somewhere either at the top higher levels, or within the team, you know, I've like, we don't want to keep dragging, we don't want to keep being lost in the weeds, and then this can be the, you know, like the activation energy, like you gather the power to be like, okay, we actually want to try something different.

1:11:26And in that case, what I would say is what usually works best is, okay, we're going to try a pilot project. And what we want to do is, as you said, kind of choose a problem that's important enough to all of us that we think it's meaningful, it's going to be worth, you know, trying to do well. And it doesn't have to be six weeks. It could be something that is a little bit smaller. Maybe you feel comfortable taking on a three -week thing for the first time. What's important is just matching, matching these things together, right? Here's a problem that we actually care about. It's timely, something that we would like to be shipped soon.

1:12:02It's not so small that we're not going to actually learn this new muscle, you know? And it's big enough that it's going to feel like we really achieve something, right? So maybe that's going to be four weeks, maybe it's going to be six, maybe it's three, I don't know. And then kind of getting to a place where we have we wrestle a bit with the problem to get the problem narrowed down, we get into our shaping session. And then we do our best, do you know what I mean? And usually what happens to is, if we have an engineering team that's going to become free to do this work for those X number of weeks, that's the upper limit on how long we can spend a shape.

1:12:42And that's another kind of like real life thing. Sometimes we talk about like, you know, like if on the one hand there's this universe of kind of never -ending documents back and forth to get feedback and comments, you know? And then on the other hand, there's like the team is going to be available. We're trying to actually do this. So actually, we've got a week to shape because engineering needs to kick off next week. You know what I mean? That's kind of a little bit more the real scenario when you're actually in this aligned world of like, we want to we want to ship something now. Yeah, real life constraints.

1:13:17That's a really helpful way of telling you how much I'm going to have to do this. For people that are just like, this is like, like I don't know any friends that are using this, it's like weird, this way of working. Like it's not a thing I hear about all the time. What can you say to them to help them be like, okay, I should actually give this a try. Here's like how many people are using it. Here's impact they've seen anything. You can share it there and help them get over that. I would say, um, wait until it hurts more. You know, if if if if if the unfamiliarity is kind of the big problem with it, you know, then then maybe the things are fine.

1:13:55I mean, because it's not like this is the only way. Uh, it's more like, um, I mean, changing is really hard, you know, and, um, if there's a good reason to do it and it's like, look, we've we've done it the old way. We've tried different experiments. You know, we've even already churned through a new head of product or we've cut a different CTO in, you know, and we're still having the same problems. Then there comes a point where it's like, like, I know that this is uncomfortable and I don't know somebody who's done it, but, you know, like, I think we need to try something different because we can't continue this way.

1:14:30That is a great answer. Following that same thread, just what are signs that it's time to try something like what sort of pain do you often see? That's like, okay, this is, you shouldn't look into this seriously. You know, there are pains all along the journey. So, I mean, I think the the place where it's most obvious is at the end of the line when we thought we were going to be done and this thing is just dragging and dragging and dragging, right? Like the teams, like, we're not shipping things, we're running in place, we keep going in circles on this, like, we don't see the end. Of course, that's kind of like the culmination, you know, but there's also a lot of pain points along the way.

1:15:11So there's, if we go all the way upstream, you know, there's, if we go to the source of a project, right? Sales talk to a customer, you know what I mean? Or sales talk to a lead and we and want us to, they have this idea of this thing we need to build, right? Or the CEO had this idea on the shower the other day, or the product team did a whole bunch of research and they have a big case for why this is the thing that's important to build next. Whatever it is, there's a source, right? For the, from the business perspective of like, this is the thing we should do next. If it's, if we just say dashboard and we don't negotiate with that means, if we just say calendar and we don't negotiate like what that actually is, then what do we experience?

1:15:54This kind of fuzzy, fuzzy thing where, you know, like, it's really hard to get to a conclusive answer about like, yeah, that's what we need to go do, you know? It's kind of like the ever -expanding blob, you know? So if we, if you felt that before, that's already a first pain. And then of course, where does it go from there? So we say calendar. So we don't know what it means, but we say calendars. So now we give it to product and we've either got a whole bunch of figmophiles or we have the PRD with a million requirements about what a great calendar is, you know? And of course, you know, I don't want to be cruel to the people who are putting their hearts into that work because the figmophile is beautiful, you know?

1:16:38It's just coming a little early, right? And the PRD is full of a lot of true things that are probably really important for decision -making in the project. But the way that it's packaged at that moment isn't something that gets absorbed, you know? I mean, you write this document and who, I mean, who actually, I'm sorry, like, who actually reads it, you know what I mean? Like, and I know it's painful, but it's like that, you know? And then even when we try to read it, because it wasn't shaped and we didn't get down to it's this, it's that, it's that, and that's how it works. It's hard to, it's hard to walk away from reading that and kind of have anything that's in your head, you know?

1:17:19As like, this is what we're going to go build. It's kind of like a million puzzle pieces that you're going to have to solve, right? So what we see is either, you know, there's the figmophile and then there's the pushback from engineers, you know? There's the, there's the, the PRD, but then it's like, okay, but we still don't actually know what to build. There's kind of all those things where instead of moving forward, there's like more and more questions, more and more pushback, more and more going back to the drawing board. So that's another kind of big indicator that something is going wrong.

1:17:50And then, and then when we're in the building and we thought we knew what we agreed to, we thought we all said, yeah, this is what we want to go make. And it's just more and more questions coming out, you know, more and more unexpected complexity, things that we didn't anticipate, you know, and it's just, it just doesn't feel like we're getting warmer and, and coming closer, it just feels like it's getting harder and harder, you know, those are all, those are all the signs that like whatever process you use, you know, that there's a lack of, there's a lack of clear shaping and there's a lack of clear framing because there's a lack of clarity, right, around what it is that we're doing.

1:18:26Before we started recording, you made this interesting point that there's all this talk of feature factories and that, uh, rarely are they actually like efficient factories, like they do, like work. Yeah. Talk about that. Yeah, well, I understand what the feature factory critique is supposed to be. It's actually to the framing point of, um, we're not negotiating the value and the outcome we're trying to get from something. We're just kind of taking it and building it, you know, and then of course, in the end, uh, according to the feature factory critique, we just built it because somebody said we should build it and then people didn't use it and didn't value it and the product is just getting bloated, right?

1:19:04The thing is that like, I would say, if you have a feature factory meaning you're continually cranking out features, you're probably quite healthy. All you need to do is feed a different input to the beginning of the factory, right? What most teams are struggling with is that they can't, they can't, they don't have predictable, repeatable shipping of things, you know, I mean, at least from my experience, the bigger, really widespread struggle is like stuff isn't moving, it's dragging, I can't see the end. I'm losing my, like I'm feeling burned out, you know what I mean? Like it's not exciting to work on this anymore, like all that kind of a thing.

1:19:41Maybe last question here is what's, what's kind of like the sweet spot stage for a company to start using shape up? I know you basically worked in this way from the very beginning when it was just three people. What do you find is like should startups that are just starting out, start breaking this way or do you find it's more useful later on? We didn't formalize it until we had to and there was a long time where there wasn't a fixed length for projects, there was just an understanding of the urgency and kind of a feeling of what too long felt like, you know, and it didn't actually click into, oh, this is a cycle length and this is six weeks and then we pause and this is how this is who comes together to make the decision of like what's the next project and here's who is mainly doing the shape.

1:20:23You know what I mean? Like all that stuff didn't get solved until we had reached a certain size. Usually the main tipping point, if we start from smaller to big, is you know, there's a phase when the founders are still involved in everything and so it doesn't matter what your process is, it's going to be fine. But then you start to hire the first other people and then for the first time you try to delegate some of those things and the founders try to be less involved and that's often where a lot of problems start to appear and the founders start to ask themselves like, we used to be fast and now we hired people because we needed a scale but now we're slow, you know?

1:21:00So like how will we be fast again? Because we know what it's like if we if we just got back in there as founders and you know, got our hands dirty like we could make this go but how do I get, how do I get these, like the people that we've brought in to make these, make these trade -offs and make these decisions and how do I get the work to flow again, you know? So that's something that we definitely see there. So that's a really good moment. I'm onboarding new people. I don't know what to tell them how to work. I don't want to introduce a bunch of scrum rituals. Just winging it on Kanban isn't working because they don't have enough clarity.

1:21:35I run what to go after so I have to babysit them all the time. You know what I mean? Like these kinds of things. There is another extreme which is, we've already gone past that. You know, we've been scrum or whatever for years. You know, the company has been growing like revenue is coming in like sales is doing their job like things are running but man, nothing is getting out the door. And we're years in and we have an entrenched development. We have like an entrenched engineering team which is a wall away from an entrenched kind of product team and everybody's apart and this thing is like we're like stuck.

1:22:19And that is more where there's going to be some tensions that are starting to appear at the executive level. There's going to be some finger pointing. There's going to be some like, why isn't this moving? Why isn't this happening? How can we be spending so much money and all these engineers and we don't have anything to show for it? You know, and that's a point where there can be kind of a, so hard, some hard conversations need to start happening about how do we actually start to negotiate around how we spend time. And we can't just have endless refactorings and infrastructure projects but we need to be actually building things that we can sell again.

1:22:54What an idea. Yeah, you know, but it can, you know, there are a lot of kind of engineering works that have been standing around for a while, you know, and it's all refactoring all day and tech debt and stuff like that. And there's reasons why all those things got there, but there comes a point where we have to figure out how to cut through it and make some hard choices so that we can carve out time to build the stuff that's actually going to, to be needle moving again and not just sustaining us where we are to like run in place. Imagine the slatter bucket as you mostly work with the kind of companies that bring you in.

1:23:29Actually, it's been so far a lot of the, it's been a lot of the folks who still remember what it kind of newly too big and they don't like being slow. I've had a lot of that. I actually think that there is, I think that your intuition is right that the market for the last category is the biggest, but it's hard, it's hard to reach them. It's not easy to talk about these things. These are sensitive topics, you know what I mean? Like our engineering team isn't shipping, you know, and like it's like the, and it's happening at leadership level. There's a ton of complaints happening deeper in the org, but nobody down in the org can change anything.

1:24:10At the end of the day, it's actually the interface at the executive level of being able to say, how are we using our time? Like we have to change something to make it even more concrete in that first bucket. What's like the size of org that you find is most in you to this is like how many engineers or is it like when they hire the first PM? Like what's kind of the, I sometimes have the like how the heck do I hire the first PM? And what do they do? Conversation, you know? But usually it's later than that. It's after they hired the first PM, after they hired the second PM, and maybe even the third, you know, and they're kind of getting to like the product and engineering together are like 30, 50 people, you know?

1:24:48And it's like we thought we put everybody in the right roles. We kind of did what we were supposed to do and everything is just grinding and like why are we so slow? Perfect. So 30 to 50 -ish people seems like a good time to that's probably like basically you're finding that's when things start to really break down. That's when they show themselves, you know? And I think I mean if someone kind of hears this and it all starts to make sense and they're earlier in that wave, then of course the earlier that you can anticipate it the better, right? That's a good point. So if you're, it's too late is when they come out.

1:25:18I, I mainly hear about it when it's too late, you know, that's why they're reaching out. Yeah, that's maybe closer than 30. Okay. But I think I really think it honestly, I think it starts the first project where, for example, the founding engineers hands off and then the new hire is taking over responsibility or the person who was like sort of founder slash CEO is like first giving it to a PM to kind of thinking they're going to carry it through, you know? And then it's not exactly meeting their expectations of what they thought was going to happen. You know, I think that's when this connects actually start.

1:25:52It's, it's the first step away from the work where the seeds of all of these problems actually start. I want to talk about base camp and how maybe not every company can operate like base camp before we get there. Is there anything else along the lines of shape up that you want to add or share? Yeah, there's, there's one key thing, which is the role of the PM. I think what we see today out of necessity in a lot of teams is that the PMs spend a lot of time kind of chasing around inside of the build phase inside the time box to try and make sure that, you know, people aren't stuck and getting lost in the weeds and try and keep things moving, you know?

1:26:36And it can sometimes be too close to project management rather than product management, you know? And what we see in really in shape up teams when they hit their stride is that the PM moves upstream. So the PM is less busy with how do I get this project to like not be in a bad state when it's getting built? And they're way more in how do I understand the business context? How do I narrow down the problem? How do I negotiate back and forth with maybe the CPO who kind of brought this to me to understand where the core of it is? That that really getting deeper understanding of the business and the problem and the customer domain and like what problem is worth solving and what's even slice of that problem is the valuable slice to to argue that we should spend a few weeks on, you know?

1:27:32That's the place where the PMs can really contribute a lot in the shape up world there. That's kind of what they do rather than shepherding the process or being a ritual master or something like that. That sounds pretty wonderful. I've been doing something thinking about what a world, an AI oriented world does to the role of PM and it feels like very similar to that actually where the building now is going to happen for you with AI tooling and that means the bigger question I was like, what the hell should I build? And is the thing I built, right? Incorrect and likely to work and I feel like this is similar.

1:28:08It's like the PM spending a lot more time up front thinking through what to build and then the building is more a lot more hands off. So hands off it gets done in like five minutes when you're just like, oh, build this thing for me, but I'm there it is. Yeah, let's see, let's see. Yeah. Let's see. I'm also very curious. Yeah. Oh man, what a well time. Okay, let's talk about base camp. I think we talked about this ahead of the podcast that I think you want people to know that it's a base camp is very unique and not everyone can work the way base camp works. Just talk about your insight there and advice there and people see all this advice coming out of base camp.

1:28:44I can tell you I had no idea how unique we were until I was outside and there are so many things, for example, it's a lot of the things that people ask me about that are kind of not in the book that started to reveal those things to me, you know, I have so many things that I was just taking for granted. I mean, every designer codes. Imagine, if every designer codes and not and I don't just mean HTML, I mean like running the app locally, going into the place where that view is rendered to make that thing look the way that they wanted to look or whatever, right? I mean like really codes, every designer.

1:29:22So every designer codes, where's the wall between design and engineering? Where is that? Where's the moment where you arrive with the figmophile and then all of your, like the disappointment and all of the your hopes get destroyed because the engineers tell you know, right? Like those moments don't even exist, right? In that world. And then also, I think also there was this lack of distance between sort of the business objective, the thing we're trying to, the reason we want to maybe do this project and the blessing of the founders and the like there wasn't this kind of you know, executives far away with some big targets and then some layer of PM and then some building.

1:30:07I mean, the founders were always there right there in the problem definition still. I mean, I can't say today, but I mean up until 2021 when I was still there, you know? So it meant that there was so much clarity all the time around what we're solving and why and why we're making time for it. And then of course on the engineering side as well, I mean, imagine you have no sales org, you have no marketing that all of sales selling and marketing is happening by the unicorn founders. So it means that there isn't contention for engineering time, that there isn't kind of like all these different sources of requests that you have to wrestle with, you know?

1:30:49And David did such an extraordinary job of, I mean, the more I see the world, the more I'm amazed at how every six weeks there was clear runway in engineering of like we have time for whatever the whatever we'd agree together is the most important thing. Just blank check like six weeks at a time, you know, that'll blank check, but you know what I mean? Like a blank six weeks. Yeah. Again and again and again, years without end, you know? Keeping that engineering capacity focused on readiness for product, you know, and totally leaning into like what's exciting to do to build for the product and not getting lost in all this refactoring and new infrastructure and technical dad and stuff like that.

1:31:36I mean, that's those are amazing. So those are some really big differences. And it doesn't mean that you have to be based, kept to do shape up, but what it does mean is that when we say, oh, just have a shaping session. And if you have the the pressure of the time box, then you can make trade -offs together. It's like, well, if if if we are used to having a big wall between, for example, engineering and design, then we're going to have to learn somebody who wants to start shaping is going to have to learn like, well, I need to figure out kind of who to bring together and how to have that session and how do we interact with each other so that we are combining all of that knowledge that maybe at base camp was all in the same head in a lot of cases.

1:32:18This is such an important point for people to hear because there's so many people that come on podcasts like this and share here's how to do it based on their experience. And there's so many just assumptions about their resources, the people they hire, the way the founders operate, like no sales team, I think that's like, I don't even think about that. Yeah, I imagine you never, no such thing as a request from sales. Yeah, no such thing as pressure of like, we need this thing in order to upsell, right? Or to close the steal. Never. It sounds like you're kind of in this like by the way, it was like, 37 signals, like it's interesting, it's not a base camp, not 37 signals.

1:32:53Yeah, I mean, so it's just like the timing of when I left, you know, we were originally 37 signals and then base camp became so big that we renamed ourselves to base camp. I didn't know that. Yeah. And then so for example, like on the book, you know, on the, it's the shape up and there's a base camp logo on the bottom, not a 37 signals logo, you know, but then they since I went back, so it's 37 signals again. So I sometimes struggle with, I don't know what to call it, you know, but it's both whatever, whatever people can recognize, it's the same, you know, it's the same powerhouse. Okay, cool.

1:33:25I'm glad I'm not the only one that's confused, but 37 signals, the name, great. Yeah. Yeah. So you said that it kind of felt like you left and it was like this bubble you got out of, what was, was there like a moment where you're like, you wrote this book, everyone, you're like, hey, this is how you should work and then you're like, oh wait, this doesn't actually work in real life, for a lot of people, is there a moment there? It wasn't that this doesn't work. I was just in a, like a foreign country, you know, it was like, um, we tried it and it didn't work, you know, one of the common things I would hear is, um, the projects kept running over, you know, we weren't finishing them at the end of the cycle, they kept running over and running over.

1:34:03And then I would be like, huh, so can you show me your shaping work? And then they would show me a PRD. I'd be like, like, well, that's not, that doesn't look like what's in the book. And then, uh, and then I would, and again, like, can you show me your shaping work and they'd show me like a bunch of figma files, you know, and then, and then what I started to understand was like, we have some people in a role who were used to making a certain artifact at a certain step, and they just kind of kept doing that, you know, and, um, I didn't appreciate it. It took me a while to realize, like, there's no engineer in the picture here.

1:34:40And, uh, and it was when we started to actually do the course, as well, I did actually a couple projects where I helped teams hands on and I learned that they, they, I was the first actually consulting project, as you know, I helped a team who was stuck. And what we did was we, we, we, we chose the engineer who was best suited to come over to product and be there in the shaping. And that was the moment when it was like, ah, now I'm in the world, I know again, when we, when we had all of that mixed in the same room again. And so that was kind of like, that was really something, I mean, it was a total learning curve for me, you know, and there's a lot of things like that.

1:35:20But that was, for example, a really big one is like, oh, we have to get engineering in there. You're the type of guest, I most love having him as podcast because you basically work with many, many companies, study what's working. What's not. You're like, in, you're not like in the clouds pontificating about something and you're like working with teams to make things better. And then you take all of that learning, put it into a book and share with us all. And so the ROI is just incredible for us all because you've spent so much time doing this and you've actually done the work. You're not just in theory about it.

1:35:53So, so this was amazing. But we're not done yet. One question I wanted to ask is Jason was tweeting that there's, he's working on a, in the follow up, shape up book. What's happening there? Are you involved in that? What's the story? So I also saw the tweet. And, ah, I have to admit, I was a little surprised when I saw this tweet, you know, but I had had a conversation with Jason a year earlier. And he reached out and he said, hey, you know, we're and my first reaction, I mean, I was imagine I was actually really in the middle of learning, you know, all these things that teams need to learn in order to kind of catch up to what was natural for base camp to do.

1:36:36And, ah, so for me, it was like, interesting. I have a lot of new things. I have a lot of new ideas, maybe a second collaborating on the second edition could make sense. But what I understood was that what he wanted to do was to kind of make an updated version of how, of how they work. Because that's always been kind of a big thing of how I have to show you the right name, 37 signals of how they, how they market and also how they lead is they like to really show a clear example. Not like this is how you could do it. This is how some people do it, but like this is how we do it. And I think it's their strength that they are very, very clearly, like this is how we do it and kind of take it or leave it.

1:37:15And what I understood was that if I did another version of the book that was just kind of how base camp does it, I think it would leave so much opportunity on the table. Like there's so many people where what they need to learn is more like how can it come closer to where I am? If I have the wall today between product and engineering, how do I bring the right people together into a shaping session? How do we actually do that? How do I overcome all of these little challenges because this is so far from our current way of working? So the work that I'm doing with, for example, with shaping in real life is kind of all about those gaps.

1:37:50And then I don't know what's going to be in the second edition, because they are, I guess someone there is going to be working on that. But what I'm guessing is it's going to be an update on kind of up on top of the mountain over here. This is what base camp is doing. So hopefully it'll be kind of a cool thing to look at as like here's a model of what they're doing. And then the question is what can I take from that? And what do I need in order to actually be able to make it work in the real situation I'm in? You know, and that's kind of where, well, that's my focus. This is so interesting. Thank you for sharing.

1:38:22Sounds like a fork, fork, he forked it and these going potentially in different directions but inspired by each other. Totally. So interesting. Ryan, is there anything else that you want to share before we wrap up? One thing I could throw out there is sometimes people reach out to me because their projects aren't shipping. There's a lot of straw gold. There's a lot of lack of clarity. But the root cause is actually that the input at the very beginning of the process is too unclear or you know, like we don't actually know what's important to customers or not actually sure where the value is or this kind of a thing.

1:39:03You know, so there is this link, this framing step that we talked about of what is really the problem before we go into shaping. This is the link to product strategy also. And this is the place where it can be really useful to reach for a lot of, for example, Bob Mesta's stuff with the jobs to be done and the demand side work of trying to get clear about things. So that's the tool that I reach for at that phase. And you can think of kind of this, you know, before the problem definition, there's this question of like, what's the demand? Where are people struggling? Where is really the place that it's trying to scratch, you know?

1:39:42And then a lot of the shape up stuff is kind of when I have something where I think there's an opportunity or I think there's something meaningful there because of what we learned from customers or the job to be done research or whatever it was. Now, how do I turn that into something that we can actually go do and ship in a reasonable amount of time? That's kind of the supply side. That's where the shape up part fits in. So maybe it just might be cool for people to sort of seal the link there. That's a great plug for Bob Mesta episode. We talked in depth about the jobs to be done framework and had actually applied.

1:40:13What's the book you'd recommend there? Sounds like basically it's like shape up plus this book gives you a lot. Actually, the one that I recommend the most is a demand side sales 101. And it's funny because it's like sales, you know, especially for a product person, like you're like, I'm the product person, not the sales person, but it's such a good dive into what are people really trying to solve and getting into that mindset of what's the struggle, what's the problem? I think that's a really good entry point for that. Yeah, I don't know of that title. I feel like you could have done better there with that book's title.

1:40:48It's a, yeah. You know, what's interesting about it is that it's very, very pointy for like if you are trying to make progress on sales, then it's this other kind of sales, this demand side sales, you know, so I think maybe it's more for us who are kind of using it for different purposes. Like we're the product people trying to pull something out of it that it's a little bit less aligned, but it's it's still useful. Yeah, but basically it's like the the jobs to be done book. Yeah, it's kind of like the jobs to be done book. That's a bit more tactical, you know, if you're really curious about the general spirit of jobs to be done than competing against luck is a really good intro.

1:41:24That's the one that Clayton Chris Clay Christianson wrote with a lot of I think I think I think there's a lot of stuff that Bob worked on that's in there, but for a little bit more tactical, like what's it look like to do the interview and how to think about the struggling moment and stuff like that, this demand side sales is good for this strategy stuff. Awesome. And we'll also link to this episode where you could get the gist of it in one hour's time. Oh, that's right. You did that episode was great by the way. That's yeah, but thanks Ryan. Okay, we did it. This was amazing. I think this is going to help so many people.

1:41:57We got through it. We're not we're not done yet. Two final questions for you. Where can folks find the book find you if they want to work with you anything else that you want to share and how can listeners be useful to you? Well, they can find me at my website that's Ryan singer .co. I'm also on on X RJS. I'm on LinkedIn. So just reach me there. And how can people be useful to me? I love hearing from people who are having these problems. If you're having these problems where it's like things are dragging or we can't see the end and we're not getting the quality we need and all this stuff like, and this is how I learned all this stuff is by talking to people who are in it.

1:42:37So even if it's not clear, what's the next step yet? If that problem is real, it would be cool to hear about it. I'd love to chat. Be careful what you wish for about Mesta. I was just on the podcast and he told me he's got over 100 LinkedIn DMs of people sharing their struggles with their job search. So here you go. Oh, yeah, my job moves. That's a big one. I think that's a broad appeal. Yeah, that's true. I'm going to ask you to explain that when you do consulting work, just like how does that work? Who's that for? Just because that's something else you do. So it basically starts with either off and first CPO or CTO often reaches out first.

1:43:18What it works well is when we actually get them together. And then they understand that they need to change something or we have a head of product and a head of engineering, that kind of a thing. If those two are both seeing eye to eye that there's a problem, then we can start a conversation around. Who would be the right people for a pilot team? What are the things that are going on business -wise that could be a good pilot project? And then I can help to figure out how do we actually almost like guiding through narrowing down that pilot project framing so that they have the support that it's going to be successful in shaping.

1:43:53And then coaching the team so that they actually learn those shaping skills so that they can get through a session and come out with much more clarity. How do they actually run those sessions? It's first working with leadership. Who do we need to get to do this work? Who are the right people? How do we bring them into a pilot project? Narrowing down, doing some framing work on the pilot so it's going to be clearer in the shaping and then giving some guidance on how to get through that shaping with some feedback rounds. This is usually a good approach. Amazing. And they can find this in your website if they want to explore this.

1:44:24Yes. Amazing. Ryan, thank you so much for being here. Yeah, thanks a lot. You had amazing questions. It's a subject that can go in so many directions and you kept bringing us on to some kind of a main track. So I'm really pleased. It was really nice. Thanks a lot. You made my best. Thanks Ryan and bye everyone.

1:44:45Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts Spotify or your favorite podcast app. Also, please consider giving us a rating or a leaving review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at linniespotcast .com. See you in the next episode.