Ryan Singer: Why appetite beats estimates in Shape Up's plan

1. 0:00 – 4:38

   Ryan’s background

   1. RSRyan Singer0:00

      (instrumental music) I often use this analogy of, like, if you're doing a home renovation, you can have like the most beautiful rendering of the new bedroom, and were gonna have these lamps on the side of the bed that are coming out from the wall. But if you haven't checked if there's electricity in that wall there or not, it's gonna drastically change the cost and the time and everything. What we need to do in a, in a shaping session is we come out with some kind of diagram where engineers, product, and design, they're saying, "We understand that." So the first thing is we are not going to start something unless we can see the end from the beginning. We're not going to take a big concept and then say, "What's the estimate for this thing?" We're gonna go the other way around, and we're gonna say, "What is the maximum amount of time we're willing to go before we actually finish something?" How do we come up with a idea that's going to work in the amount of time that the business is interested in spending?

   2. LRLenny Rachitsky0:52

      (instrumental music) Today, my guest is Ryan Singer. Ryan was one of the first few hires at 37signals, and through his experience of building Basecamp and his 17 years of building products at 37signals, he wrote a book called Shape Up, which shares a very different approach to building software. Appetites instead of deadlines, a big focus on bringing design engine product together into a room to shape the plan, versus writing long PRDs or trying to finalize designs before you start building. I've noticed more and more teams adopting the Shape Up method, and especially with AI starting to change how we work and build product, there's a shift coming in how product teams will operate. And so I thought this was the perfect time to do a deep dive into the Shape Up method. This episode is basically gonna give you everything you need to give Shape Up a shot on your team or at your company to see if it fixes the problems that you're having shipping great products. A big thank you to desk trainer, Bob Mesta, and Chris Speck for suggesting questions and topics for this conversation. If you enjoy this podcast, don't forget to subscribe and follow it in your favorite podcasting app or YouTube. Also, if you become a paid subscriber of my newsletter, you get an entire year free of Perplexity Pro, Notion, Superhuman, Linear, and Granola. Check it out at lennysnewsletter.com. With that, I bring you Ryan Singer. This episode is brought to you by WorkOS. If you're building a SaaS app, at some point, your customers will start asking for enterprise features like SAML authentication and SCIM provisioning. That's where WorkOS comes in, making it fast and painless to add enterprise features to your app. Their APIs are easy to understand so that you can ship quickly and get back to building other features. Today, hundreds of companies are already powered by WorkOS, including ones you probably know, like Vercel, Webflow, and Loom. WorkOS also recently acquired Warrant, the fine-grained authorization service. Warrant's product is based on a groundbreaking authorization system called Zanzibar, which was originally designed for Google to power Google Docs and YouTube. This enables fast authorization checks at enormous scale while maintaining a flexible model that can be adapted to even the most complex use cases. If you're currently looking to build role-based access control or other enterprise features like single sign-on, SCIM, or user management, you should consider WorkOS. It's a drop-in replacement for Auth0 and supports up to one million monthly active users for free. Check it out at workos.com to learn more. That's workos.com. This episode is brought to you by Merge. Product leaders, yes, like you, cringe when they hear the word integration. They're not fun for you to scope, build, launch, or maintain, and integrations probably aren't what led you to product work in the first place. Lucky for you, the folks at Merge are obsessed with integrations. Their single API helps SaaS companies launch over 200 product integrations in weeks, not quarters. Think of Merge like Plaid, but for everything B2B SaaS. Organizations like Ramp, Drata, and Electric use Merge to access their customer's accounting data to reconcile bill payments, file storage data to create searchable databases in their product, or HRIS data to auto-provision and de-provision access for their customer's employees. And yes, if you need AI ready data for your SaaS product, then Merge is the fastest way to get it. So, want to solve your organization's integration dilemma once and for all? Book and attend a meeting at merge.dev/lenny and receive a $50 Amazon gift card. That's merge.dev/lenny.

2. 4:38 – 7:40

   The origins of Shape Up

   1. LRLenny Rachitsky4:40

      Ryan, thank you so much for being here, and welcome to the podcast.

   2. RSRyan Singer4:46

      Yeah, I'm really happy to be here. Thanks a lot.

   3. LRLenny Rachitsky4:48

      I think this is gonna be a legendary episode. There's a lot of interest these days in different ways of working, uh, especially ways that aren't Agile and SAFe and Scrum and all these ways that people kind of hear about working. Especially in this world of AI where everything's just changing, feels like there's just an increased interest in exploring different ways of working, and specifically feels like there's been a rise in interest in Shape Up, the stuff that you talk about. So, I am really excited to basically help people understand what is this way of working, uh, is it right for them? What are ways to start implementing it? What are maybe some pitfalls you may run into? And as much as possible, get into a lot of real talk about how things are actually going in product teams that people often don't like to hear. So first of all, just do you... Have you also seen this increased interest in Shape Up?

   4. RSRyan Singer5:38

      Yeah, you know, I think it's interesting that we're talking now. (laughs) You know, I mean, the book came out in 2019, and, uh, it's just... I've been hearing more and more like, "Oh, we s- we know somebody who's trying it," or, "We're hearing it when we go talk to other companies." You know, like, so I, I think it's a wave that's slowly building. And i- it's funny, you know, like, (laughs) When it came out, I even tried to have like an online forum to get everyone to, who's interested to talk together. And what I started to learn pretty early on is that people don't like to talk about their struggles shipping. Especially, you know, CPOs and, uh, CTOs don't like to go in a public forum and say, "Our company isn't shipping," or, "Our engineering team is stuck," or, "Our team is always lost in the weeds," you know? That's not a, uh, it's not an easy, uh, community, uh, topic on a, on an online forum, you know? So I think there's also some reasons why it's been word of mouth, kind of slowly gathering steam.

   5. LRLenny Rachitsky6:33

      That's something I struggle with on this podcast, you know? It's, as you said, it's a product and product teams don't wanna be sharing that things aren't going great. That's why I introduced Failure Corner on the podcast where it's like, "Okay, but tell me a time things didn't go well."

   6. RSRyan Singer6:45

      Oh, yeah, that's great. Yeah, 'cause it's so hard to get to that, right? And it's not all just this golden path rosy where we're all, you know, shipping beautiful, meaningful things all day, you know? It's a, it's a hard business and there's no, like, perfect school either that kind of produces expert product managers and, and CPOs and CTOs and stuff like that. So we're all, like, trying to figure this out and we don't have a lot of sources, you know? So it's, uh, there is a lot of struggle.

   7. LRLenny Rachitsky7:12

      And there aren't, like, many options for how to build product. Like, all people really read about is Scrum/agile/safe as they scale, and then there's, like, Waterfall, which I'll never do Waterfall. And then there's, uh, like the startup way of just, like, ship in maybe one or two week cycles, and then there's Shape Up. So it feels like it's one of the rare other options that exists. And so-

   8. RSRyan Singer7:33

      That's one of the things I've been hearing. It's like, I hear, like, "Oh, we thought there was only Scrum or Kanban and then we heard there was this Shape Up thing.

3. 7:40 – 9:56

   Implementing Shape Up in different companies

   1. RSRyan Singer7:40

      Like, what's that?"

   2. LRLenny Rachitsky7:40

      Hmm. And I, I think it's always been connected to Basecamp. We're gonna talk about that just, like, it's, like, it works for companies that are n- nothing, like Basecamp. Maybe j- maybe just ta- touch on that briefly.

   3. RSRyan Singer7:53

      Well, I mean, that came as a surprise to me, (laughs) you know? Uh, I mean, when I wrote the book, I had been in Basecamp at that time, I think, 15 years, and, uh, uh, I actually didn't even know the outside world, you know? I mean, it was Jason's idea to even write the book 'cause he said, "Look, like, a, a lot of people are gonna wanna know about this. A lot of people are struggling." And I'm kind of like, "Well, okay." Like, I knew our inside story of we had some growing pains and we had to be able to formalize the way that we were working in shipping so that as we brought new people in that they could participate in that and we could stay fast, you know? So I knew our, like, internal struggles, but I honestly didn't know anything about the outside world (laughs) . And it was only after the book came out that it gave me this kind of excuse to start talking to people from all kinds of different companies, and it's been really interesting. There are some really amazing cases of companies of very different characteristics from Basecamp, like VC funded, you know, significantly bigger, like, very different pressures, different team structure, different skills who are doing it. And at the same time, there's also a lot of questions that are coming my way because honestly, there are so few teams that are structured just like Basecamp that there are a lot of gaps in the book of, like, "Well, what about this and what about that and how do we do that in our situation?" So, like, a lot of my focus today is actually kind of closing those gaps and helping people figure out how can I make this work for me or for our team?

   4. LRLenny Rachitsky9:19

      And you specifically told me you now call it, instead of Shape Up, it's Shape Up in Real Life or Shape Up for Real Life?

   5. RSRyan Singer9:24

      Yeah. Well, you know, um, my wife heard me saying the same thing over and over again on every phone call, and she's, she's overhearing me and she's like, "You got... You have to make a course. You have to do something 'cause you're just... m- you're, you're always saying the same thing." So then this, this led to this, uh, course that we made, which is called Shaping In Real Life and well, yeah, the idea is the real life part, right? How do I make this work if my designers don't code, if, you know, if I have... Actually, uh, it's very contentious to get engineering time. You know what I mean? Like, when there's all these different pressures that Basecamp didn't have.

4. 9:56 – 19:02

   How Shape Up is different

   1. RSRyan Singer9:56

   2. LRLenny Rachitsky9:56

      We're gonna get into the nitty-gritty of how this actually works and the key elements, but can you just give, like, a very short, overar- overarching summary of how Shape Up is different from how other product approaches are?

   3. RSRyan Singer10:07

      I think the way it's different starts with kind of how the way we were working was a little bit different. Um, so I started working with Jason and David on the first version of Basecamp, you know, the... which was, like, the flagship product of 37signals back in 2003. And we were a team of three and, uh, we were... I mean, I think it's... for any really small team when you're just starting out, you don't need a process, you don't need a way of working. It just kinda happens organically 'cause you're together, you don't have to explain it to other people, you know? It just kind of happens on its own, right? But there was always this really intense urgency from both Jason and David, like, "We've gotta get to something we can ship. We have to finish this and move on. We, we have to get to something that's done." There was just no tolerance for kind of big things that got fuzzy and started to drag. We... There was always this, like, sharpening to get to what is this thing really and when are we gonna get to the end soon? And on top of that, even when we were building V1, David wasn't actually full time as the, as our only technical person. He was programming 10 hours a week so we had this really intense pressure of like, "How can we really use David's time well?" You know? We don't wanna ever kind of give something that this is the thing we wanna build and then it turns out not to be what we want and we have to throw it away and then come back again or... You know what I mean? Like, th- those kind of, uh, bad cycles of waste.

   4. LRLenny Rachitsky11:32

      Let me actually ask about this 'cause this is really interesting. So this is DHH. Uh, he was working part time when, when you started 37signals.

   5. RSRyan Singer11:39

      10 hours a week, yeah.

   6. LRLenny Rachitsky11:41

      Was he working on, like, Ruby basically and that whole thing?

   7. RSRyan Singer11:44

      Uh, well, Rails came out-

   8. LRLenny Rachitsky11:47

      Rails, right.

   9. RSRyan Singer11:47

      ... of, of, of the fir- so he, so he told, he told Jason, "I wanna try building this in Ruby." And, uh, 'cause before, they had done some collaboration and David had done things in PHP before that, and he had this new idea he wanted to try Ruby, this language he fell in love with. And then, you know, the framework Ruby on Rails, he, he ended up releasing that after Basecamp was standing 'cause it was kind of extracted from, uh, the things that were necessary to get V1 of Basecamp to stand up.

   10. LRLenny Rachitsky12:16

       So that's what he was doing the rest of his time instead of-

   11. RSRyan Singer12:18

       I don't know, I don't know what he was doing the rest of his time, you know? (laughs)

   12. LRLenny Rachitsky12:22

       Probably something great, something

   13. NANarrator12:23

       But-

   14. RSRyan Singer12:23

       But he's always, I mean, he's always been like that, you know? He's always doing something interesting, like he's either racing or who knows what, you know what I mean? Like, uh, so. But all I knew is that we got 10 hours of- of that time.

   15. LRLenny Rachitsky12:33

       Yeah. I love that that was, like, a constraint to design a way of working that uses engineering time most efficiently.

   16. RSRyan Singer12:39

       Yeah, I mean, put that, put that together. So David's constraint of 10 hours a- a week, and then Jason has this, I mean, I think many really successful founders and especially CEOs have this thing. It's like all they wanna see is movement. You know what I mean? Like, forward, forward, forward. So like, when do we get to see it? When do we get to try it? When do I get to put it into somebody's hands? So that combination, there was just so much urgency, even though there was no outside pressure. You know what I mean? It was completely just, like, let's say cultural energy of like how do we kind of keep getting somewhere and getting to something that we can celebrate and get excited about.

   17. LRLenny Rachitsky13:16

       Hmm. I love that. That's in- that's, like, an attribute, I think, of a lot of successful founders so that makes sense to hear that.

   18. RSRyan Singer13:22

       Totally, totally. And that's why where I come back to you, like this is the part of the story where I think so many companies would say, "Yeah, I know that experience," right? Because they think that's probably the seedling of a lot, as you said, of successful companies, is that- that combination of urgency and also that those guys were so talented and that they- they had a clear vision of what they wanted to do and all of that. It's this amazing time, actually, these early days.

   19. LRLenny Rachitsky13:44

       Is there anything more to the backstory that's important to share, super interesting?

   20. RSRyan Singer13:47

       Yeah, I mean, the other big piece of it was, so Jason and I were like this kind of product, what do you call it? Like the two-thirds, you know? And then there, and so I was doing UX at the time. And I was doing hands-on coding as well. So we're very, very integrated. Everybody kinda does a little bit of everything. All of us were coding. Like Jason was in the actual app templates as well, doing HTML and CSS to do the views. He's doing hands-on design. We're all, like, very much connected with like, "Why are we building this? What is this?" You know, David's doing the, David's doing the bulk of the programming. And Jason and I were having these little sessions. These little sessions where we would really figure out what the idea was. And there would be this moment where you would have a few strokes of the Sharpie pen on a big pad of paper, and all of a sudden you'd be like, "Oh, yeah. Like that's the idea. That's the thing we wanna go try to build." And for me, like those- those sessions with Jason, they were these short, very, very intense sessions where you're trying to crack the nut together. Like, where's the idea? What's the concept? Like how can we go... what's this thing that we're gonna go and like ten hours later, right, David's gonna come back and we're gonna be like, "This is awesome, this thing works and it does something we're excited about," right? That was really kind of the seedling. I mean, actually that continued over years and years and years, those sessions. And that's the seedling of- of this word in the book Shaping. What does it mean to do shaping? It wasn't, uh, sitting alone, um, writing a document. It wasn't making a bunch of requirements. It wasn't making a beautiful Figma file to represent a concept that could maybe be a feature, you know? It was this, like, super intense, really exciting collaborative, like, "What about this? What about that? Oh, maybe this." You know? Uh, so that was, uh, a really big part of- of how we worked also. Very intensely collaborative sessions to figure out what the idea is, and getting it sharp enough and- and crispy enough that we could very confidently get a yes from David, and that he would know exactly what it is and what it means and come back, and it would be what we pictured and it would work the way that we hoped so that we would kind of keep going and we wouldn't have to reverse or- or go back to the drawing board.

   21. LRLenny Rachitsky16:15

       What it sounds like is essentially you're kind of trying to maintain the startup way of working as the company grows. Like everything you're describing is how it feels to be at a startup, and this is a method to keep that. Does that sound right?

   22. RSRyan Singer16:28

       That's exactly what- what kind of became Shape Up was how do we hold onto that as much as possible? I mean, one big ingredient, we had an advantage also which was that Jason and David hired so deliberately slowly. And this is kind of, um, like a fortunate side effect of the fact that they didn't take investment money. So there was kind of, there wasn't, there was never that moment of like now's the moment when we grow. It was always like one person, and then kind of the organism adapts. One more person, you know? And so this- this natural way of working, it was, it was organically spreading. They, there were, I think, maybe 10 years before we had the first kind of like, "Wait a minute, what just happened?" Like, "That's not," like, "that project didn't go well. That's not how things normally run." You know, I mean, we really, it was, it was s- I mean there, of course there were always, like, ups and downs but there was, it was, it was about 10 years later when we had the first project, I- I mean, I remember the project. I remember being at the end of, it- it was at that time already kind of, it- it was maybe, it had been like maybe six weeks or seven weeks. We hadn't yet completely locked the six-week thing that went into Shape Up. And I remember we had a review session and there was a fairly new, uh, new person who was leading the- the, uh, who was doing half of the work on that team. We had the review session and it was like instead of, "Oh, look. This is about ready to ship," it was like, "There are a lot of open questions here. And not only are there a lot of open questions here, we're not getting quick answers when we have w- you know, as we, as we're asking. And what we're starting to realize is, like..."Oh, this is... Not only is this not gonna ship, but we can't even see the end of this, you know? And, uh, and that was like one of those moments where you're like, "Oh, this isn't going to automatically organically just keep spreading as we hire forever." You know what I mean? We did reach a point where it's like, "Oh, this... We're gonna have to figure out when this goes well, why does it go well, and what do we do differently, and how do we kind of formalize that so it's, it's reproducible as we keep onboarding more people?" And that's, that's actually when Shape Up as a, as a framework started. That's when I really kind of started to lean in, and I sort of took over that responsibility of, "Okay, how do I

5. 19:02 – 26:29

   The core elements of Shape Up

   1. RSRyan Singer19:02

      systematize this?"

   2. LRLenny Rachitsky19:03

      That's a great segue to let's actually talk about how the Shape Up method works. What are maybe just at a high level, what are like the core ingredients to the Shape Up method?

   3. RSRyan Singer19:10

      There's basically, um, kind of like three, uh, maybe big things. The, so the first thing is this notion of we are not going to start something unless we can see the end from the beginning. So we're not going to take a big, a big concept and then say, "What's the estimate for this thing?" We're not gonna say, "Oh, we need to be build a calendar and then do a whole bunch of Figma files or write a whole bunch of requirements and then ask for an estimate." We're gonna go the other way around, and we're gonna say, "What is our appetite for this? What is the maximum amount of time we're willing to go before we actually finish something?" And we have that startup moment that we talked about, that moment of like, ah. You know what I mean? It works. We got somewhere. We... This, at least this, if not the whole project, this meaningful piece we can literally walk away from. So, um, then what we found was that there was a lot of experimentation. We found that six weeks is kind of the maximum that we could see into the future, or we could actually say like, "How do we work backward and figure out something we could build in that six weeks and really land it," you know? So that's kind of the first piece, is working backward from our, the amount of time we actually want to spend on something and say, "What can we do? What could we shape so that after that amount of time we've gotten to somewhere we wanna be?" You know, it's kind of like if you're gonna buy a car or you're gonna, you're gonna, you're gonna buy a house, or you're gonna rent a new flat or whatever, you have to have like a budget in mind, right? (laughs) And the, the, the budget then is how you choose between all kinds of alternatives and make a lot of hard choices and trade-offs to figure out like, "Well, you know, I, I, I want the faster engine, you know, but I can't af- you know, but I have to give this up, or, you know, I, I want it to be fun to drive, but we also need space for longer road trips."

   4. LRLenny Rachitsky21:05

      (laughs)

   5. RSRyan Singer21:05

      And, you know, you're making all these trade-offs, right? So this is kind of this, uh, this second piece is, is this work that we call shaping. And the shaping work is how do we actually take this fixed amount of time that we've given ourselves and vary the scope? How do we come up with a idea, some version of this that's going to work in the amount of time that the business is interested in spending? So, um, this is that, those creative sessions that I was talking about where we're jumping all over the, all over the room in front of the whiteboard and, uh, and, and getting to an idea. And there, the really key thing is that we're getting to an idea where we can see the idea. You know, we understand like why we're doing this. We're wrestling with the problem, and we're wrestling with the solution until we have an idea that we can actually say, "Uh, this is what we want to go build." So it's not just calendar or dashboard or, you know, uh, newsletter builder, but it's like this idea of how we're gonna tackle this problem about the calendar request, right? So that's the shaping. And then the third piece is when we've actually carved out a fixed amount of time, when we've shaped a solution that is from a experience standpoint, from a functionality standpoint, from a technical standpoint, doable and desirable, something that we can make happen in that amount of time, then we can give it to a team. And we don't have to do the sometimes called Scrum, the, the paper shredder, you know? That's where you take an idea, and then you split it into 100 tickets, right? And you hope that it all glues together still after you've done that step, you know? We don't wanna do that. Instead, we wanna have a whole idea, give it to a team, so they see the whole. They really understand it, right? And then they can come up with their tasks, and they can figure out how to track that and break it into pieces, so they can actually take more responsibility. And so what we see is way more engagement, you know, especially from the technical team, right? Because instead of like, "Here's your ticket," right? Or, "Here's your user story," it's like, "Here's the thing you understand that makes sense. And now you're going to have freedom to figure out how to actually make this a reality." There's gonna be a million things to solve in the implementation detail, and now you have a bunch of fun problems, and you don't have to keep asking questions to other people to understand what this is or how do I make a trade-off or that kind of a thing.

   6. LRLenny Rachitsky23:44

      One of the core elements of this th- and I wanna confirm is that you can pick and choose these things into your team. You don't need to do this wholesale. Correct?

   7. RSRyan Singer23:53

      Uh, you don't need to do, uh, yeah, any of it. (laughs)

   8. LRLenny Rachitsky23:58

      (laughs)

   9. RSRyan Singer23:59

      So, so this is where we kind of... It helps to, it helps to look at like what's going wrong and what are we trying to fix-

   10. LRLenny Rachitsky24:04

       Yeah.

   11. RSRyan Singer24:05

       ... and then, you know, what do I wanna bring into this, right? And usually what I notice is that people, they like to start sometimes with, "Oh, I wanna give the team, let's say, six weeks, and I, and I wanna give the team more latitude or let's say more creative freedom that they're gonna be responsible in the six weeks to figure out how to make it happen," right? And usually, a lot of the drive for that is, "I'm getting tired of having so many..."... meetings and rituals and things that are not actually working on the problem and doing the work, you know. I mean, especially Scrum teams, they, they often complain about that. So what they sometimes see in this is like, "Oh, I love this idea that the team is just gonna be cooking for six weeks and they're not gonna, you know, we're gonna meet as needed and we're gonna workshop things, but we're not gonna be busy with all these rituals all the time." Right? Uh, now the thing that's tricky is that if you want that reality of the team happily buzzing and humming like a, you know, (laughs) like some happy bee colony, you know, for this, uh, six weeks, they need to have a lot more clarity around what's the thing that we're solving, right? And so when we start working backward from that, then what we see is that, oh, well, if we don't shape better, then the team isn't gonna have the clarity that they need to take over that responsibility, you know, so they can make choices and make decisions and make trade-offs so that they can get to the end of this thing. And worse, yeah, the worst is that I sometimes see cases where people are like, "Okay, we're doing shape up. So you guys are gonna build, you know, the newsletter builder, okay? But you only get six weeks to do it. So use your fixed time, vary your scope and, and, and, and enjoy your responsibility." You know what I mean? (laughs) Which is just cruel, right? Because y- uh, I think I'll quote, uh, Bob Moesta, who's been on your show a couple times, "You can't put, uh, 10 pounds of crap in a five-pound bag." So, uh, (laughs) you know, it's a high academic statement, you know, and, uh, 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, and ship, ship something meaningful in six weeks by cutting away scope," right? So what start, it starts, it starts to, it starts to raise questions about how do we actually decide together what this project is, and do we actually have clarity around what the idea is and what we're gonna

6. 26:29 – 37:23

   Shaping sessions and timeboxing

   1. RSRyan Singer26:29

      build, you know?

   2. LRLenny Rachitsky26:30

      Let me follow up on a couple of the elements. So appetites, I think for any product manager, engineer, designer, anyone that is, like, experienced, okay, we're gonna, we estimate this will, this landing page is gonna take a couple weeks. Great, let's work on it, and it ends up being six weeks. Uh, 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. Makes total sense. Like, this just makes so much sense as you listen to this, uh, especially for people that have just fallen to the, the problems of estimates not being accurate.

   3. RSRyan Singer27:08

      Mm-hmm.

   4. LRLenny Rachitsky27:09

      Then there's a six-week element, and the key there is you're, you're... and this is, uh, kind of counter to maybe two-week sprints, like Scrum. Is that kind of the, where this comes from?

   5. RSRyan Singer27:18

      So, you know, actually, it turns out that the six week is only a maximum.

   6. LRLenny Rachitsky27:23

      Hmm.

   7. RSRyan Singer27:24

      And that's really where this number does some work for us. If we think of six weeks as a maximum, that's gonna force us to ask some really good questions to ourselves about where do we act- what, what piece of this do we really think we can land? Because if you try to say, "You know, in six months we're gonna 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, 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, especially if you're on a growth team. You don't wanna wait six weeks or... You know what I mean? They're, you're gonna have to artificially bundle things together to do six weeks. It's like, look, I've got, I've got something I wanna, I wanna 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, uh, it's, it's, it's more a question of what we're trying to take on, you know? It's really that upper limit.

   8. LRLenny Rachitsky28:39

      Okay, so it could be a two-week cycle and the appetite is-

   9. RSRyan Singer28:41

      It could be a two-week thing.

   10. LRLenny Rachitsky28:43

       Cool. So it's like we're gonna build this new landing page, we're gonna give it two weeks, and then do a shaping session on that.

   11. RSRyan Singer28:48

       Yes. Now the, the other thing, the other side of that is when it comes to feature development or, you know, building something that's gonna be meaty enough to sell, you know, then there's very few things that are gonna 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, "Oh, 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? But six weeks is a long enough chunk, or sometimes four weeks. The question is kind of, what's big enough that we can actually get somewhere with this amount of time, right?

   12. LRLenny Rachitsky29:32

       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.

   13. RSRyan Singer29:47

       This is a tricky one.

   14. LRLenny Rachitsky29:50

       Mm-hmm.

   15. RSRyan Singer29:51

       So you're right that it's implied, uh, but the thing is, in real life, if you make a commitment and you get alignment that we are gonna 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... And 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 managed to ship inside of six weeks." That's gonna kill everybody's morale. Everyone's gonna feel disappointed, we're gonna 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, so now we're, like, overtime, you know? None of that is good. And if we also go the other extreme and just say, um, well, like, it, we, like, shall we say in the book, you know, we had this principle at, at base camp, 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 gonna cancel it and rethink, you know? Almost no teams have the stomach for that.

   16. LRLenny Rachitsky31:16

       (laughs)

   17. RSRyan Singer31:16

       (laughs) But the, the version of that that's more stomach-able is, look, we can't just, uh, 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 gonna keep reinvesting in something that we don't understand, you 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, doing a different kind of work to 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?

   18. LRLenny Rachitsky32:02

       I love just how real this approach is, not this, like, theoretical, okay, cool, after six weeks you just de-scope and it's all, uh, that's cool.

   19. RSRyan Singer32:10

       Yeah, you just cut the scope, you know?

   20. LRLenny Rachitsky32:11

       Yeah.

   21. RSRyan Singer32:11

       No problem.

   22. LRLenny Rachitsky32:12

       Just ship what you got, ship what you got.

   23. RSRyan Singer32:13

       (laughs) I've seen some shape up adoptions that looked like that, by the way, and that's, it's, uh, you know, it's, it's, that's, that's not the way. Uh, we... The, the shaping step is crucial. And you know, what, what you mentioned with your landing page example, by the way, it's so seductive, because we can imagine, you know, oh, i- th- 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 is some functionality that we have to figure out how to make it exist, we 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 gonna turn," you know, that's, that's the place where we can say, "Ah, this is well shaped." You know? And, and that's a, that's a, it's a different kind of work. We, i- in, in shaping in real life, we call it, you know, we actually teach it as doing live shaping sessions. And, uh, this was how I did it for years, uh, 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, uh, the, kind of the, the s- 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?

   24. LRLenny Rachitsky34:03

       Mm-hmm.

   25. RSRyan Singer34:03

       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? You bring 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 white boarding 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.

   26. LRLenny Rachitsky34:30

       This is great. Let's g- let's go one level deeper on this shaping session. So a few tactical questions. How long are these sessions? It sounds like the people that join are the, a designer and then an engineer and, and a PM. So add anything else there. And when do they happen? Is this at the end of, uh, a cy- do you call it a cycle, by the way, or a sprint, this, this six-ish week period?

   27. RSRyan Singer34:51

       What I actually like is time box, actually. Because the thing is that, um, i- i- s- some teams need regular cycles because they have m- 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.

   28. LRLenny Rachitsky35:24

       Let me take a quick tangent, because if you're... That's so interesting that the time boxes can be very different lengths. Imagine at a larger company this gets complicated when other teams are trying to... There's dependencies and timelines, launch, go to market dates and all these things. What's, like, the largest company this sh- this approach has worked at? Like, like, what's the ideal company stage for shape up?

   29. RSRyan Singer35:47

       It can function in very large companies. Uh, we have, for example, uh, I have, uh, some friends at a, uh, at a, uh, they're a, uh, a, what is, what is it called? They're doing, uh, clinical trials, so they're in the pharmaceutical industry. And I mean, the company's, 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, uh, it's completely possible in that context if you have someone who's at a senior level on f- on the engineering side who is able to, uh, make the right architectural choices and also do some, some, some negotiating and kind of be the backstop to make sure that someone isn't gonna get pulled away onto something else, you know? If you can kind of carve out, oh, this system can be worked on independently of that system.This was actually what David at, at Basecamp has always been amazing at, is this dependency hell. It's actually not, it's not a, 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 untangles things. So 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 gonna protect this team from that other work for this number of weeks, you know, you can really get a lot done.

7. 37:23 – 38:56

   Flexible sprint planning

   1. RSRyan Singer37:23

   2. LRLenny Rachitsky37:23

      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. What's kinda like the adapter, um, and I wanna come back to the actual shaping process, but I, I can't help but ask this. Say the company's operating at like a quarterly cadence or a six-month cadence, and then there's like a team operating in a two-week, sometimes six-week, sometimes four-week cadence. Advice on how to, like what's the adapter that connects those two cadences?

   3. RSRyan Singer37:49

      So, uh, there's, there's kinda two different things. So like I've seen cases where they've decided on a, uh, like a, a four-week plus two-week or like, so, 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.

   4. LRLenny Rachitsky38:07

      Mm-hmm.

   5. RSRyan Singer38:07

      You know, I've seen that. Um, 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 CPO 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 gonna do this and that thing finished, and now we're doing this and it's gonna finish." And the next time you say, "We said we were gonna do that and it's finished." You know, without excuses and without, "Well, maybe another few more months" or, you know, "We're working at it." Like that, I mean, that's, that's what, that's what everyone wants to see is that movement, you know?

   6. LRLenny Rachitsky38:52

      Yeah. If you're doing great people will leave you alone. That makes sense.

   7. RSRyan Singer38:54

      For sure. For sure.

8. 38:56 – 46:57

   The output of a shaping session

   1. LRLenny Rachitsky38:56

      I, I love that. I love that point. Okay. Coming back to shaping. One, one maybe one way that would make it re- uh, really easy for people to understand. What's the output of the shaping session?

   2. RSRyan Singer39:05

      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, um, 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 Figma files or maybe, uh, 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. And what you see is that, um, when you, when you give that to a team as like, this is what we shaped, what happens is like, it, it blows up. So I mean, you probably, uh, know about what happens when the, the, the Figma file makes first contact with the engineering team. (laughs)

   3. LRLenny Rachitsky39:58

      (laughs)

   4. RSRyan Singer39:59

      There's a reality check that happens there, you know?

   5. LRLenny Rachitsky40:01

      Yeah.

   6. RSRyan Singer40:01

      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 kinda 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? What are the different cases of, 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, uh, if you're doing a home renovation, you know, you can have like the most like, uh, beautiful rendering of here's the new, here's the new bedroom and we're gonna 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 like have the perfect rendering and the perfect lamp and the perfect color, but if you haven't checked if there's electricity in that wall there or not, right? It's gonna drastically change the cost and the time and everything if you're gonna have to rip open those walls to feed some lines up to those lamps, right? So what we need to do in a, in a shaping session when it's going well is we come out with some kind of, uh, uh, 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-

   7. LRLenny Rachitsky41:40

      Mm-hmm.

   8. RSRyan Singer41:40

      ... 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. In Shaping In Real Life, we call this framing and, uh, in the book there's a chapter called Setting the Boundaries where we get into this and it's like, look, we, we, we, we're not gonna just build calendar, which is like Google Calendar, you know, where 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. So that's a good frame. Then what are we actually gonna 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 gonna have this, this, this, this, this, and this, and that's how we're gonna let people see the empty spaces," you know, that's a good indicator that it's clear enough that, that, 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?

   9. LRLenny Rachitsky43:01

      Mm-hmm.

   10. RSRyan Singer43:02

       So it's like there's gonna be two months side by side. But, um, they're just gonna 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, uh, iPhone calendar, I think, still has this, where it's just dots on the month view.

   11. LRLenny Rachitsky43:17

       Mm-hmm.

   12. RSRyan Singer43:17

       And then if you tap a day with a dot in it or without a dot in it, there's gonna be an agenda view that slides underneath, which is gonna 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. So what you can see here is it's not like... Like, what is a calendar, you know? It's not a calendar. It's a, it's a, it's a two-month dot grid with scrolling agenda view underneath, right? And, uh, and the ability to, to hit new when you're looking at an empty space to create something in 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 gonna be a real conversation and not looking at a whole bunch of, um, 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.

   13. LRLenny Rachitsky44:22

       That 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, uh, kind of like the user, the, the user experience with just, like, wire frames/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 doc, a spec, and not final design, and also not just, like, a user story. As a user, I need to be able to see (laughs) empty spaces.

   14. RSRyan Singer44:56

       Exactly. So 'cause that's the thing where it goes wrong, you know. If, if we're going to commit engineering time, you know, and it's like we believe there's some way to see empty spaces, but, you know, the way is a question mark, it's a really risky way to spend that time, you know?

   15. LRLenny Rachitsky45:10

       'Cause you're committing, right? It's like, "I'm gonna do this in three weeks."

   16. RSRyan Singer45:12

       Yeah, you, we're, we're committing.

   17. LRLenny Rachitsky45:13

       Yeah.

   18. RSRyan Singer45:13

       And that time is really valuable, right? That six weeks of engineering time, you know? And that time wasn't easy to get in the first place, right? 'Cause 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 'cause 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 and a scrolling agenda view and a button. There'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, and work on.

   19. LRLenny Rachitsky46:06

       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 scattered tools. No more misaligned teams. If you're like most product leaders, you're tired of constant context switching between tools. That's why Airtable built Product Central after decades of working with world-class product companies. Think 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 workflow to match exactly how your team works. No limitations, no compromises. Ready to see it in action? Head to airtable.com/lenny to book a demo. That's airtable.com/lenny.

9. 46:57 – 53:50

   Balancing detail and flexibility

   1. LRLenny Rachitsky46:58

      You mentioned, and I think a lot of PMs listening to this are gonna be like, "Uh, I'm scared of doing this," is if you get too detailed, uh, the engineers and designers on the team are just like, "What the hell, you're just telling me what to build? That sucks. I don't wanna, I don't want that kind of work." So what's, like... Is, is the solution to that the engineering lead was super involved and detailed and the design lead was super involved, and so you can trust that it's- that you're not just a code monkey building the thing they told you to build?

   2. RSRyan Singer47:26

      That's really interesting. I gotta tell you, the dominant failure case that I see in the real world is always, again and again, not enough detail.

   3. LRLenny Rachitsky47:36

      Mm-hmm.

   4. RSRyan Singer47:38

      And it's also the most common failure mode where engineers run back to the, to the product folks and say, "I'm not getting enough from you." It's- it's- it's- it's really like that. But I can understand why the, um, the hair stands up on the back of the neck a little bit.

   5. LRLenny Rachitsky47:57

      (laughs)

   6. RSRyan Singer47:57

      You know, thinking about it. Because, um, of course, if you, 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 gonna be like, "What do you... Like, like, who are you?" (laughs) "Who are you?" You know what I mean? But, but what's really interesting is it's not a universal thing. The amount of detail that the team is gonna 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. Right? So, like, we're gonna do this, and I would suggest approaching it like this, this, this, and this.... right? That junior person is, uh, when they don't know how to do it, they're not gonna ask, 'cause they don't wanna show that they don't know, and they're gonna hide the fact that they're lost, and it's gonna blow up later in the project. And, 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, let's give less deal- detail and see how they handle it," right? So you can really give people bigger shoes to grow into and, and, and help them to be successful. And then, of course, you can also do it the other way around where, uh, if, 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 gonna be able to understand and solve it, then of course you can leave things out, right? The, the, the thing that I often see is if there's someone on the build 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, you 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 are 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.

   7. LRLenny Rachitsky50:29

      Feels like the core of this is, uh, de-risk the biggest risks and, uh, address the biggest unknowns as much as possible. Like, there's probably this 80% of here are the risks, let's just, uh, understand them deeply before we commit to this appetite.

   8. RSRyan Singer50:42

      That is exactly right. Um, there are these, uh, uh, you know, we can call 'em 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 a 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, they figured out that they could actually pipe that data in from one of the partners that they had 'cause they were partnered with banks. And they're like, "Oh, we don't even need to be asking people this," right? "So we're gonna in- we're gonna fix conversion, we're gonna eliminate a step from our user experience, it's gonna 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 kinda 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? (laughs) So now we have decisions to make. Now, if you're in the middle of a project and it's already been resourced, right? And 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? Uh, 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 greenlight 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, sometimes 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?

   9. LRLenny Rachitsky52:38

      (laughs)

   10. RSRyan Singer52:38

       So it's like when you'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 gonna be bigger." No, 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? What 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 are talking about the important things. We're not failing right now. We are engaged

10. 53:50 – 1:01:32

    A deep dive into shaping sessions

    1. RSRyan Singer53:50

       in the hard questions that are gonna enable us to really ship something that's successful later.

    2. LRLenny Rachitsky53:54

       Well, let's go one level deeper, uh, on the shaping s- session because clearly that is so core to this working. And I know you have a whole book about, like, how to actually do this, so we're not gonna answer all the questions and there's a lot of detail and nuance, but l- a few questions. How long do these usually take? Is it, like... Sounds like a whole day kind of experience, and then sounds like you invite as few people as possible but not too few people. What's your guidance on who should join?

    3. RSRyan Singer54:18

       So we, um, we run, uh, in this, uh, Shaping In 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... (laughs) So, like, uh, 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? Like, right now. We're, we're not gonna go away.... and, and, and, and draw something and then, and then I'll 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-

    4. LRLenny Rachitsky55:01

       Yep.

    5. RSRyan Singer55:01

       ... imagine (laughs) -

    6. LRLenny Rachitsky55:02

       (laughs)

    7. RSRyan Singer55:03

       ... like, ha, imagine like, uh, we, we, we've narrowed down the calendar problem to 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?

    8. LRLenny Rachitsky55:23

       And that's how you, that's the input to the framing session, or sorry, the shaping session.

    9. RSRyan Singer55:27

       Exactly. 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 wanna draw an idea and then I want the technical person to find like, "Oh, this isn't gonna..." You know what I mean? "This isn't gonna work because of this reason." Or the product person is gonna be looking in and saying, "Mm, 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, uh, 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," okay? And that's idea A. Like, uh, then w- what's, what's a very different way of doing this? You know what I mean? Like, if we didn't wanna 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 kinda 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, a little bit of, uh, 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? What are some major missing things, you know? Like, okay, I've got the ca- I've got the calendar d- 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 abouts. 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 or we come back the next day, right? And what I would say is if, if the project that you're trying to do is doable with, let's say, your existing technology, right? You're not inventing a new algorithm. You're not inventing some new database or, you know what I mean? You're not doing, um, 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, if the, if the problem is clear and the time is now, like, you will be able to f- 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? Uh, if you have just the product and the designer there, uh, and, 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 and you 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.

    10. LRLenny Rachitsky59:17

        Uh, there's so much genius built into this approach and it, like, sits on top of human nature. Uh, one is just you, you need to actually spend, like, go into the deep edge cases and nuances and not-

    11. RSRyan Singer59:31

        Yes.

    12. LRLenny Rachitsky59:31

        ... just like, "Let me... Let... Yeah, it's fine. Let's go. What's the big-"

    13. RSRyan Singer59:33

        More concreteness.

    14. LRLenny Rachitsky59:34

        Very concrete. Very, like, in, in depth.

    15. RSRyan Singer59:37

        Yeah.

    16. LRLenny Rachitsky59:37

        And then the appetite, I... There's just, like, so many elements to this that just connect with the way humans work versus a theory of just, like, "Yeah, we'll estimate-"

    17. RSRyan Singer59:45

        Yeah.

    18. LRLenny Rachitsky59:45

        "... how long this will take. It'll be great."

    19. RSRyan Singer59:47

        (laughs)

    20. LRLenny Rachitsky59:47

        "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."

    21. RSRyan Singer59:52

        And we're solving a puzzle together, you know? 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 kinda has to do these things, but in this time and, you know? One other thing that I would mention is that, um, we can't be drawing Figma files if... By the way, I'm, I'm, I'm, I'm being very, uh, uh, mean to, to, to Figma, you know, so far in this conversation. There is a time, right, when, when it's the right time for the Figma file, right? What we wanna 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, and the, the, the exact fixture-

    22. LRLenny Rachitsky1:00:38

        Right, grout, grout color.

    23. RSRyan Singer1:00:38

        ... and stuff like that, right? Grout color. We don't wanna 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, on, on something so high fidelity, right?And so we need also some ways to collaborate, and 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 gonna 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. It's more this kind of breadboarding

11. 1:01:32 – 1:02:48

    Fat marker sketches

    1. RSRyan Singer1:01:32

       level.

    2. LRLenny Rachitsky1:01:33

       Fat marker session is, like, very evocative of w- what this whole session is about, is, like, very high level sketches. Uh, that's a great term.

    3. RSRyan Singer1:01:41

       The danger there that I often see is that, um, what we don't want is to say, "Oh, Figma isn't the right thing at this level, so instead we're gonna do fat marker sketches." And what you get is the equivalent of a blurry Figma. Do you know what I mean? Just less detail.

    4. LRLenny Rachitsky1:01:57

       Yeah.

    5. RSRyan Singer1:01:57

       What we need from a, from a fat marker sketch for it to be valuable to us as, 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 wire frame of, like, you know, dashboard goes here and there's gonna be four reports, and it's like, I still don't know what to build. Right? 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."

    6. LRLenny Rachitsky1:02:37

       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 wanna actually implement it, they can get the book and dive in or work with you, which we'll point

12. 1:02:48 – 1:13:20

    Getting started using Shape Up

    1. LRLenny Rachitsky1:02:48

       people to. Say someone's like, "This is awesome. I wanna 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 every week, so 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 something different."

    2. RSRyan Singer1:03:07

       Sometimes, uh, dev teams, uh, they like the idea of not having the Scrum ritual, so they wanna take in the six weeks, but, uh, 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 gonna go well. Right?

    3. LRLenny Rachitsky1:03:28

       So they think they're gonna not have to do stand-ups, but now it's, like, a day of, of hard thinking.

    4. RSRyan Singer1:03:33

       It all, it kind of turns into, um, even more meetings (laughs) -

    5. LRLenny Rachitsky1:03:38

       Yeah.

    6. RSRyan Singer1:03:38

       ... 'cause we don't know what to do. (laughs) And the more meetings is just that shaping session specifically, right? No. What I mean is that if we didn't, if we didn't-

    7. LRLenny Rachitsky1:03:45

       Oh, right. I see. You jumped it right.

    8. RSRyan Singer1:03:46

       If we only adopted the, if we only adopted the six-week cycle and said-

    9. LRLenny Rachitsky1:03:50

       Yeah, yeah.

    10. RSRyan Singer1:03:50

        ... uh, "We're gonna 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, um, you know what I mean, uh, knocking the champagne bottle on the boat because we're celebrating the launch, you know, or whatever, you know, again and again. Right?

    11. LRLenny Rachitsky1:04:13

        And that's a good actually time to maybe talk about, there's obviously the spring kickoff in Scrum. Uh-

    12. RSRyan Singer1:04:17

        Yeah.

    13. LRLenny Rachitsky1:04:18

        ... what's, like, the main difference for people? 'Cause they may be thinking, "Oh, that's just, like, a spring kickoff. What's-"

    14. RSRyan Singer1:04:22

        Oh, that's a good one.

    15. LRLenny Rachitsky1:04:23

        "... the big deal?"

    16. RSRyan Singer1:04:23

        That's a good one. So what you often see in a, in a Scrum team is that there's somebody who creates these, um, tickets of, like, these are the things that are gonna happen inside of the sprint, you know? And really in, in, in, in my opinion, too many cases, it's not the person who's doing the building who's creating those tickets.

    17. LRLenny Rachitsky1:04:45

        It's like a product owner.

    18. RSRyan Singer1:04:46

        So there's a big, big gap there. There's, uh ... Uh, we could talk a lot about that. Um, but there's, there's gaps in context. The person who's writing the ticket doesn't actually understand the work that's involved. Do 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, uh, is two things. So in Scrum you have, you have a, a person who's not the builders, um, making tickets and this is what in, you know, uh, in the, in the cruel picture is the paper shredder. In, in the Shape Up world you have a single idea that was shaped. This is the thing we shaped, right? With the two months in the agenda view and da-da-da. Go make your own tasks, 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? Uh, that's their expertise, right? So in the Shape Up world, the kickoff is, uh, here's the well-shaped idea and now this time box starts. And, um, at, in, at base camp it was, it was really, really loose because, I mean, they are just stocked with senior people. I mean, they have so many very senior engineers and all the designers are coding and they're very technical, really, really skilled people. And, uh, what I found is helpful when the team's 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 a 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. It's a really, really useful exercise to, uh, to kick things off and we have a lot of teams doing that now. You know? If you take six weeks, that's like, uh, 30 business days. You divide that by 9, it's, like, kinda like four days per box. You know? So you're gonna 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, aye, 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, and 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.

    19. LRLenny Rachitsky1:07:38

        Go, 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 aft, if the output, the team that's building it can come up with nine. And is it like more, like... Does it have to be nine? Is it like six, cool? Ten, cool?

    20. RSRyan Singer1:07:55

        Uh, what I found is, um, if, if it's, uh, 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? If you have 100 things, it's like, that doesn't tell me anything. But if it has to be nine or less, you know?

    21. LRLenny Rachitsky1:08:10

        Nine or less, okay. Very cool.

    22. RSRyan Singer1:08:12

        Uh, I, I actually think, I, I actually think, I'm, I'm s, 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, uh, 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 all s, hold in our heads? Can we kind of see the whole castle?

    23. LRLenny Rachitsky1:08:41

        So what I'm hearing is like if you're on a, say, Agile Scrum team today, if you wanna start trying this out, it's schedule a shaping session, assume it's six weeks to start, try to get ins, uh, come into it with a framing of like here's the problem we're trying to solve. Is that a good way of thinking about it, like the problem we're trying to solve?

    24. RSRyan Singer1:08:59

        Yeah, for sure the question is what problem are we 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, then the shaping is gonna be this ever expanding, never ending thing, and we're not gonna be able to get anywhere.

    25. LRLenny Rachitsky1:09:16

        Yeah. Okay. So you spend like three hours, maybe six hours, uh, prob, but like in the first session would you recommend like try to keep it to this many hours when you're first trying it out?

    26. RSRyan Singer1:09:26

        No, I wouldn't do that. You know, um...

    27. LRLenny Rachitsky1:09:28

        Okay.

    28. RSRyan Singer1:09:28

        I think, um, the, the, 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? A l, so much of the challenge is getting to the point of kind of aligning between product and engineering that we cannot keep, we cannot have projects that are dragging and dragging and dragging. We can't keep ending in a place where like w, 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, and, and compromises at the last minute that it's not the quality of, or it's, 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 exec level. Imagine, you know, you're the CPO, you're the CTO, and you are supposed to be answering to, uh, "How's that, how's that work going?" Right? And it's like, "Well, mm, actually, you know, we're working on it." I mean, ugh, I, I can, I c, I can just think of a couple times when I needed to go to Jason and, and, and, 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 are with top leadership in the room and you don't have a good answer for where you are on something is like, ogh, it's, 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, like 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, of like we don't wanna keep dragging, we don't wanna 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 wanna try something different. And in that case what I would say is what usually works best is, okay, we're gonna try a pilot project, and what we wanna 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 gonna 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. It's not so small that we're not gonna actually learn this new muscle, you know? Uh, and it's big enough that it's gonna feel like we really achieved something. Right? So maybe that's gonna be four weeks, maybe it's gonna be six, maybe it's three, I don't know. And then kind of getting to a place where we have, uh, uh, uh, we, 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 too is if we have an engineering team that's gonna become free to do this work for those X number of weeks, that's the upper limit on how long we can spend to shape. (laughs)

    29. LRLenny Rachitsky1:12:41

        (laughs)

    30. RSRyan Singer1:12:42

        Right? And that's another kind of like real life thing is sometimes we talk about like, you know, uh, you know, like if, if on the one hand there's this universe of kind of never ending documents back and forth to get fi, feedback and comments, you know, and then on the other hand there's like the team is gonna be available, we're trying to actually do this so actually we've got a week to shape 'cause engineering needs to kick off next week. Do 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 wanna, we wanna ship something now.
13. 1:13:20 – 1:18:25

    Signs it's time to try the Shape Up method

    1. LRLenny Rachitsky1:13:20

       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. Uh, 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 that you've seen." Anything you can share there to help them get over that hump?

    2. RSRyan Singer1:13:40

       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. I 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 got 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.

    3. LRLenny Rachitsky1:14:30

       That 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 should look into this seriously?

    4. RSRyan Singer1:14:43

       You know, there are pains all along the journey. (laughs) So, I mean, I think, um, the, the, the place where it's most obvious is at the end of the line when we thought we were gonna 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. So 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, and want us, they have this idea of this thing we need to build, right? Or the CEO had this idea in 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, there's a, 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, if we just say dashboard and we don't negotiate what that means, if we just say calendar and we don't negotiate, like, what that actually is, then uh, what do we experience? This kind of fuzzy, fuzzy thing where, you know, like it, 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've, if you've felt that before, that's already a, 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 calendar. So now we give it to product and we've either got a whole bunch of Figma files 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 wanna be cruel to the people who are putting their hearts into that work, 'cause the Figma file is beautiful, you know? It'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, you write this document and who, I mean, who actually, I'm sorry, like who actually reads it? You know what I mean?

Episode duration: 1:45:09