#65 - Ryan Singer // Creator of the Shape Up Method

Hello friends, this is the Alphalist podcast. I am your host Tobi. The goal of the Alphalist podcast is to empower CTOs with the info and insight they need to make the best decisions for their company. We do this by hosting top thought leaders and picking their brains for insights into technical leadership and tech trends. If you believe in the power of accumulated knowledge to accelerate growth, make sure to subscribe to this podcast. Plus, if you're an experienced CTO, you will love the discussion happening in our Slack space where over 600 CTOs are sharing insights or visit one of our events. Just go to alphalist.com to apply. Welcome to the Alphalist podcast. I am your host, Tobi. And today I have a special guest. He's right now traveling the world as a digital nomad. He used to work as a head of strategy for a company we all know called Basecamp. um very popular um productivity tool um and right now he's building i think his own company uh with third presence llc uh helping companies to shape up is that a good introduction ryan yeah sure that's fine so um maybe you can tell tell us a bit more what you actually do uh with with shape up right now and what your plans are Well, actually, it's been really interesting because when I kind of formalized, you know, what became ShapeUp, the, you know, kind of formalizing what we were doing at Basecamp and then turning that into some kind of a structure, it was completely describing, you know, exactly the way that we worked there at Basecamp. So it was like, you know, what we had figured out in that exact circumstance inside of one company. And I was blown away by the interest. when the book came out and how it's continued to, I mean, I keep hearing from people who are trying to apply it, who are applying it. And just every, like every couple of days, I get a new message from somebody on LinkedIn or something like that, where it's saying, oh, you know, we're trying to adopt it. We're doing our pilot project, which is very surprising and amazing. But the thing that really stood out to me is that, you know, companies are in a lot of different environments in a lot of different situations and as much as i wanted to just say oh you know work six weeks at a time with a two-week cool down and now we've solved it it turns out that real life is more complicated than that and uh so a lot of my work has actually been kind of taking that very interwoven system you know where the book had an exact answer for how to do the whole process end to end and figuring out what are the kind of individual Lego blocks of the product development process that teams can adopt so that they can actually kind of figure out what are the kind of incremental steps of progress that they can take, but also what are the steps they take that add up gradually to defining a new process that is actually going to work for them so that they can get back on track to actually delivering meaningful work again, you know, getting stuff done that is that actually matters to the business, which in the environment today is more important than ever. Everyone is under more pressure than before to actually deliver meaningful projects and not just to kind of spin wheels two weeks after two weeks after two weeks on never-ending projects. That absolutely makes sense to, I don't know, work on... on outcome rather than output uh but before we we deep uh deep dive on the on the process maybe you can tell us a bit more about yourself like uh i mean i guess you're you're in the scene for a while uh you're right now traveling the world like what what what are you doing like what is your how did you get there what what is your your nerd journey your personal your personal path uh to to where you are you know i started off uh as a typical sort of like a lot of us from my generation, we're like kids playing with an Apple IIe, like a green screen with basic on it and just getting really excited about that and thinking that this is amazing. Then when I was a teenager, the internet, the web was new, it was the late 90s. It was the Netscape 2 era and the emergence of web standards and CSS was new and stuff like that. I was actually always interested in trying to program, but I couldn't really figure out how. Programming at that time was way less approachable than it is today. If you wanted to program in those days, mostly would be something like C or Java or something like that at best. And I was really hard, but I could get into web design. And I was kind of really interested in user interface design. And I wanted to plug pieces together and kind of have that magical payoff moment of what it's like to write a couple lines of code and see something happen without doing kind of real programming. I hadn't gotten to that point yet. Doing web development with HTML and CSS and stuff like that was a great place to start. I actually got started though, the place that I really learned about interface design was using the generation of no code tools that were around at that time. It was in the days of Microsoft Access and FileMaker and you could define a database table. and connect that to kind of a drag and drop interface, you know, where you could have form fields and buttons and stuff like that. And that was actually a fantastic way to learn about product design and learn about interface design because you could kind of close the loop. You could see what it's like to put some affordances together to connect them into a series of actions and connect it to an actual, you know, back end, even though that back end was just. was just basically like a spreadsheet, you know, like some database tables that were connected. But that was a really great way to start. And at that time, the focus in the early web days, you know, was on kind of, there was a lot of flash going on. There was a lot of, you know, like little perfectly puzzled together interfaces in a tiny box in the middle of the screen, if you remember those days. And I got really interested in the kind of usability movement and the work of Jacob Nielsen, Edward Tufte, stuff like that. And that's actually how I got connected with 37signals back in 2003, I think it was, because they were kind of early on that same wavelength of really thinking about clarity and functionality and not just making, you know, cool animations on the web and making things that were flashy, but really making things that were functional. And then we happened to be very well timed. We started working on Basecamp very shortly after I joined. And that was very, very beginning of Web 2.0, was the very beginning of Software as a Service. I think before us, basically Salesforce was probably the big one who was first that I know of. But we really were in a, it was an amazing time actually, because we got to define a lot of the patterns that became standard in the industry for a number of years. And, you know, that feeling of kind of that Wild West feeling of inventing a whole bunch of stuff and doing things that hadn't been done before, you know, I love that. And so I started off doing that on the interface design side and the web design side. And gradually I felt that that loop to getting the things that I was picturing that I, you know, I could put the button on the screen and I could picture what should happen when you click on it. But because I wasn't doing the backend coding yet, I couldn't kind of close the loop fully on the web. And it was also fortunate because, you know, David, one of the co-founders at 37signals created Rails right around that time. And Rails made programming way more approachable than anything I had ever seen. I mean, it was you could create a real full piece of software a working app uh you could do the whole thing but in a way that felt totally approachable you know and uh and so that was when i started to get into actual real programming and i kind of became someone who sort of straddled both roles of the interface design and the programming side and i kind of became the person who could speak both languages and who was kind of the bridge between those two sides of the company And after some years went by and I felt pretty comfortable kind of being in that kind of bridge role, I started to look for new challenges. And the new challenge that I saw was now that I know how to build things, how do I answer the question of what we should build next? And especially that became a really big question for us after seven or eight years of Basecamp's growth. There came a point where, you know, all of the very... The clear use cases that we had in mind when we first shipped V1, they didn't explain all of the different industries that we saw using it, all the different customers, the great variety of ways that people were using the product. And so it kind of led to a questioning period of like, well, what do we actually focus on? And, you know, what should we build next? And what would be an improvement versus? what would be something that might improve it for some people but make it worse for other people now that we have so many different people on the platform so that's how i started getting interested in questions of strategy and trying to understand not just the supply side of how things are built in software but also the demand side of what people are trying to do and how to make decisions to steer the product towards solving the right things for people and so that's kind of a i don't know kind of a kind of an overview of the arc yeah yeah yeah that's that's a great overview and and and How do you figure out these days of what to build best? I mean, there's product discovery, there are other ideas on how to figure out what to build. Is it the crazy genius that just produces or shoots out ideas day on and on? How do you get to a meaningful outcome? First of all, you know, I think that there's different answers to that depending on who you are, you know. When I look back at, you know, at the history of Basecamp, for example, there was no day when I saw Jason go open up his book of methods and say, I'm going to use method number 27 today to figure out what to go build. I mean, he, I mean, what do you say? Like, people use the word, I think, vision or, you know. he was able to see an opportunity. He just saw it, you know, and of course that happens a lot, especially with, especially when at the very, very beginning of things that turn out to be successful from what I've seen, there is somebody who just sees it. And I don't think there's any explanation to that necessarily. The place where I got into answering that question was later when there was something that seemed to be working. You know, people were buying it, people were using it, but now, like, but we felt like we were in the dark. It felt like we didn't know how to explain what it is that people were actually trying to do. And what I found is that if I get into that situation where... people are it's it's not starting from zero it's not just trying to invent something you know uh but there's something that people are buying there's an existing behavior there's something that's working but we don't actually understand it uh in that case um i learned a method from a great mentor and friend of mine uh bob mesta which is actually based in It's based in criminal interrogation, but it's a very friendly interrogation. Basically, you talk to people who have actually purchased something, who have gone through the decision-making process of deciding to buy and use something, and you treat it almost like a crime. Like, where were you the night of the fifth? You're trying to figure out... What was the motive? What were the circumstances? What was it that actually led them to do that? And if you look at the story, the chain of cause and effect leading up to the decision to purchase, that is a very, very different thing than saying, you know, what do you like about the product? What do you not like? What do you use and what do you not use? Kind of what are your feature requests? it's more about like what was happening to you, what was going on in your life that actually made you say, I need to go find something to solve this problem. And this is something that you can learn about it in, for example, Clayton Christensen's book, Competing Against Luck, which is largely based on a lot of work that Bob did. There's also a really great intro to this kind of thinking. He recently wrote a book called Demand Side Sales 101. And even though it's it's focused on sales, actually it's the exact same methods and way of thinking that we use to answer questions about product direction. And the thing is that if we understand the struggling moment that somebody is in, the circumstance that they're in where what they're doing isn't working anymore, and we can see the trade-offs that they made and the process they went through of choosing the new way, then we can actually build a model. which is like kind of like a google map you know of of the destination they ended up at that's the the product they bought and the the origin point of their route and if we can understand point a and point b then we can actually see the cause and effect of like where they're trying to go and what it is how they actually define progress and then that becomes a framework that we can use to ask ourselves okay is the product doing all the things it should do or not to get that job done if we insert a feature idea into that route from getting from A to B. Does that feature idea actually contribute to people's success when they're trying to make that change or not? That's kind of the basic perspective. Okay. And how does that then connect to the idea of ShapeUp? Is that then the outcome of that? So yeah, basically ShapeUp is about the supply side. So ShapeUp is about how to actually get something done. How do we go from something that we think is a good idea to do? You know, we have some people, we have some time, we have some resources, and we have an idea that we think is worth going after. How do we actually turn that idea into a project? And then how do we define that project and put constraints around that and actually make that project happen? so that it gets built and shipped. And it's funny, you know, it sounds so simple and it sounds so trivial, but when you look at what's happening out there in the industry today, there's an amazing amount of struggle with that. There's a ton of struggle with that. And if you look at the processes that people are using to do their product development, it's really easy to see why. There's a lot of kind of either we see kind of undershaping where there's just kind of a bullet point list of, what the project is supposed to do. It's going to be easy. It's going to be fast. There's going to be a new, faster way to do XYZ in the product. And nobody really knows what that means. And then you give it to a team and you give them a two-week time box or a six-week time box or whatever it is. And they have to do, quote unquote, discovery, which basically means like discovery is a really big, foggy, fuzzy word that means figure out what you're actually supposed to do. And doing that under a ticking stopwatch, like that's not a good recipe for success you know and then we also see the opposite we see kind of over shaping where the the product is completely designed in high fidelity you know figma drawings or something like that but then we usually have like all the wrong kind of detail and what we see happening is when that all of those high fidelity drawings actually go to the team that's supposed to build them and implement them they honestly have to end up throwing a lot of that work out they don't build a hundred percent of what's drawn there they they they actually end up having to kind of reverse engineer that high fidelity drawing to figure out what the real intent was what is actually what's kind of the circuitry that they're actually supposed to be building what are the interactions and flows that are really kind of hidden there behind all of that glossy design and and and then they can actually start to figure out you know what are the core pieces of the architecture what are the things they're going to have to build And so that's just concerning the shaping. And then when we get into the actual kind of, you know, management of the work, there was a big pendulum swing from the 90s. You know, the 90s were kind of the high point of upfront design to a ridiculous extreme. That was where you would have six months of requirement definition. I mean, giant books of detailed specifications. And of course, this didn't work. But then the pendulum swung completely the other way to let's do no planning, right? I mean, basically, the engineers threw their hands up and they said, we can never get requirements that actually seem to be true. So let's just kind of chip away at things, you know, two weeks at a time, or even continuously, you know, the way that some teams kind of work in more of a Kanban oriented process. You get into a situation where like today, because of that, there isn't some really rigorous thinking in most companies about what it is that we're trying to go do and do we actually understand what it is that we're trying to build and how the hip bone connects to the leg bone in terms of the core pieces of this thing. And the process is basically just kind of shuffling tickets around on a board, you know, hoping that after enough cycles, it's all going to come together. So, so ShapeUp is, is the core idea of ShapeUp is actually about first bringing back a little bit of upfront design, enough upfront design where there's clarity around what it is that we're actually trying to build and how the concept hangs together in terms of the core interactions and the flows and all of that. Then how to use the principle of fixed time variable scope to have a fixed amount of time. that we're going to spend doing this a strategic amount of time. We talk about appetite versus estimate and then making trade-offs within that to actually get something shipped and finished where we can say this is done and then move on to the next thing instead of continuing to just kind of throw time at it incrementally. So that's kind of broadly what ShapeUp is about and that's all on the supply side. The demand side is what is the thing that we should shape? What is the thing that we should actually form a project around? And then the kind of bridge between those two is, you know, the earliest stage of kind of framing a project. And, you know, we can talk about any of those things, but that's what I'm seeing out there today is that, you know, a lot of people are coming to me asking about ShapeUp because they're noticing that just throwing two weeks after two weeks at something. or doing a bunch of high fidelity drawings and then throwing it over to engineers, or the product manager kind of describing in a few bullet points what it's supposed to do and then hoping the team is going to do discovery to figure it out. These things just aren't working. And when you have a lot of runway and you have a lot of time, then you don't feel the pain of that. But when you start to see the wall coming, then you say, aha, okay. we're going to have to figure out how to actually make our process more effective so that the things that we're shipping actually move the needle or get us closer to our goals. And isn't like a good starting point and one of your core ideas also that you have a bit more time than two weeks? I guess that's like obviously not all, but maybe like a good realization that in modern software companies, it will be very hard to produce something meaningful in two weeks of time, right? You know, it's funny. In the book, this idea of a six-week timebox is kind of holy because exactly like you said, that's what we learned at Basecamp was that if we wanted to build, you know, like a meaningfully useful new feature, of course, you're not going to get a big chunk of new functionality done in two weeks. You do need a bigger timebox like six weeks. But what I've learned... by working with other teams is that, you know, that's one circumstance actually, where what you're trying to do is build a chunky new feature. And there are so many different circumstances teams are in where sometimes what they need to do, the thing that's really going to move the needle, isn't the six-week new feature. It's the two-week change that they haven't been able to get done in three months. And if all you need is the two-week change, to really fix a critical point in a funnel or to make an integration or to get even a small piece of functionality that's going to make a big difference to a growing company. I recently did some work with AutoBooks in Detroit, and the first project that we took on when we decided that we were going to kind of... They were actually very early in ShapeUp, and then they had grown and grown, and there were just a lot of challenges as they were growing and then they naturally kind of drifted back to kind of more of a ticket-based agile situation and they wanted to get back into shape up and the first project that we did was literally like a two-week project but for them it had a massive impact on some metrics that were important to them at that time and it got them back in to this this place where they could target something, shape it, carve out time to do it, and then ship it, and then actually be done and say, oh, wow, we accomplished the thing that we wanted to do. And in that case, they also hit some really important numbers doing that. And they had cheers at the all hands meeting over the success of this project. So what I've learned is that the actual length of the time box is not the holy thing. It's actually the ability to set the time box to shape something within that period of time that is meaningful, that's going to make you the progress you need to make, and then to actually complete it, get it done, and then move on to the next thing. That's what's important. Some teams are going to feel, especially if they have a very open horizon in terms of cost. or if they don't have a lot of external pressures, they're going to feel great kind of one six weeks after another, you know, kind of like an ocean liner, long legs, long journeys, and making big changes six weeks at a time. Other teams are going to say two weeks here, three weeks there, another two weeks, then maybe four weeks. They're going to be kind of zigzagging along. But what's important is that they can get back into that situation where their hands are on the wheel and they're actually... building and shipping the stuff that they want to be doing. Isn't also the biggest mistake of today's planning and how you, like in many, many software teams at least, how you ship the real problem that you, like most teams, like especially technical teams, struggle with really defining a good outcome, right? It's more about output and what you're able to ship and how your roadmap looks like, instead of really thinking about how they introduce this to their clients. Isn't that also a big part of the problem? Well, that's not easy to do, right? That is kind of the ultimate challenge, I think, of every product organization, every product team, is to identify something that matters to customers. and then to figure out how do we translate that into something that we can build. I mean, that is the bridge from demand to supply. That's that kind of flow from an idea fully on the product extreme, then shaping that into something that has a technical aspect to it, where we can say this is an architecture that is going to accomplish that and then actually building it. I mean, that's the challenge is stringing all those things together. Absolutely. But I see it like it's also a question of team maturity in a way. If you think more in features that you deliver than in actual goals that you achieve or in actual users that are really using and adopting your feature, right? And in many organizations, you ship and ship and ship and ship with... without ever thinking about onboarding and ever think about how many users will ever use it and really doing the, let's say, business development that is needed to really make people use it, especially in B2B SaaS. You've been working in B2B SaaS, right? Yeah, of course. I'm not sure. If I completely agree with that diagnosis, because of course I see what you're talking about that in effect, a lot of teams aren't putting, if you look at kind of the, what do you say? Like if you did a time slice of like what they were talking about and focusing on, you know, hour by hour, there would be much more focus on just kind of the ticket treadmill and trying to build stuff as opposed to really clearly defining the outcomes. But I don't. I don't know if that's for a lack of intent or for a lack of trying to do it. What I see in a lot of teams is actually that there's, because there isn't a well understood and defined process for what it looks like to actually do the shaping, because of this over shaping and under shaping that I talked about, actually people don't have a clear sense of what it is that they're supposed to be doing once they're under the clock to actually build. So what you see is that like a lot of work is getting thrown away. There's a lot of questioning and debate and like we said, like kind of quote unquote discovery in the build phase. And then even when stuff gets built, then you get to the 11th hour and it doesn't fit together the way that we thought or it doesn't hang together. It doesn't do exactly the right thing. And because basically there's so much struggle inside, also building stuff has gotten harder and harder, you know. we're not in 2005 anymore and uh the time and effort it takes takes to execute has gone up so what i see happening is actually that the intention to focus on outcomes is there but because the process is lacking and because the the the clarity around kind of how to shape isn't really there it means that there's just a lot of rework and a lot of struggle in the build phase and then of course on top of that there's all kinds of other things come begging for attention you know there's systems on fire there's things that customers are asking about there's bugs to fix there's just like a lot going on so it takes it takes some a real moment of slowing down and becoming and really trying to become more intentional about what is it that we're going to build next and and trying to actually put that focus into the shaping phase to get clearer about what it is that we're building. And if we don't do that, then we're just going to find that we are kind of so busy with all the things that we're with all the unanswered questions that we have and all the complications that are coming up that it's hard to spend time on those things. Concrete example, maybe, and how to apply your ideas. Let's say I'm a bootstrapper. I now have, let's say, can fund myself for two years. I'm a developer, maybe have, I don't know, two team members that help me. And I used to use, or I'm familiar with Scrum processes, with Kanban maybe. I know what I want to build, like briefly at least. Where does the idea of ShapeUp come into play and how do I... What would be the Lego building blocks that you would recommend me implementing in my team concretely? Yeah, so the first thing that I would do is see if there's a problem. Of course, I'm not telling the world that they should go do ShapeUp. What I'm doing is I'm offering this to people who are saying that they're having delivery problems with the process they're using. So if you feel like what you're seeing is lack of clarity in the delivery phase. If you're inside that time box when you kind of told yourself that you would be building, but you find that you are going in circles, trying to answer questions, and you're not sure how to make trade-offs, or you end up throwing away things that you build over and over again, you know, those are all signs. or things that you didn't expect to be complications keep coming up and significantly delaying the project. Those are all signs that there was a problem earlier in the shaping phase. So if you start to see, okay, there's a lot of problems coming up in the delivery. I talk in Shape about this metaphor of the hill, that all work is like a hill. There's kind of this uphill phase of figuring out what it is that we're doing. and then there's the downhill phase of doing it and it's true for complicated engineering work and it's also true if you're just trying to figure out you know what to cook for dinner right you have to figure out kind of you know what's in the fridge like what's in the pantry you know do i go to the grocery store do we order or not kind of figuring out what you're going to do and then and then there's execution and uh uh this delivery phase you know in theory should be more downhill than uphill It should be mostly a question of doing something that we know we can do and feeling like we're getting closer and closer to getting it done. And if we're having too much uphill work, too much problem solving and figuring out, it means that we didn't do that earlier. So then the first thing to kind of start to diagnose that would be to actually just ask yourself, what was the input to the delivery phase? You know, when we kicked off this time box and said for these three weeks, we were supposed to be building something and we were supposed to be shipping at the end of that, what did we have as an input? Was it a Figma file? You know, was it a bullet list of kind of functional outcomes? Like, what do we actually have there? And how many unknowns were actually buried inside of that? as ticking time bombs that were going to explode during the time box. It's easy to just write a bullet point and say, we're going to create a feature so that we can easily see the history of all student performance in our learning platform. But what does it mean? Or a bullet point says, we're going to have a better reporting for the customer support team. What does better reporting mean? Then if you do the other extreme and you've got that Figma file, then very often it turns out that It can't be exactly built the way that it's drawn, but the intent underneath it wasn't really clearly thought out. So that would be the first thing is kind of looking for under shaping and over shaping in that input material. Then once you've seen that actually there were a lot of unanswered questions there, then the next thing to do is to think about is to kind of go about that shaping process differently. If I could give one just very simple recommendation to try, again, it might be surprising, but a lot of teams, what we could call shaping, regardless of whether they do what's described in shape-up or not, it very rarely happens with a technical person involved. You either see that kind of undershaped bullet point list coming from a non-technical person, like a product manager. or maybe a founder kind of at a high level saying what this should do. Or you get the kind of design sprint outcome, you know, which is a lot of drawings, but not a lot of substance in terms of what the actual skeleton of the architecture is. Like, what are we actually going to build here? So the simplest thing to do is just to bring a technical person. together with whoever it is that understands the intent of what this project is supposed to be about and put them together in a room for a shaping session. That can be a technical person and the product person who has the so-called requirements. It can be a technical person and a designer and that person who represents the the product, like the customer case or the business opportunity or whatever it is, the exact mix is going to depend on your people. You might have designers who are also totally technical. You might have, you know, it's, but it's a question just bringing those roles together into, into a session. And then inside of that shaping session, the, the work is to actually figure out kind of the circuit of the interactions. You know, what is, Is there a button that you click that does something? When you click it, what does it do? Can you just describe roughly in terms of the back end, what happens when you click that button? Where do you go next? So that's using, not doing high fidelity design in that room, of course, you're not going to be making a Figma file together and not just making bullet points about the outcomes that you want, but actually getting in there and figuring out what is the flow, what are the interactions? In the book Shape Up, I sort of illustrate this using a technique called breadboarding, where it's not about wireframing, that there's going to be a sidebar and then there's going to be a button on the upper left of the sidebar. It's the topology. This is a CTO podcast, so your technical people understand very well that the way things are wired is different than the way that they are arranged into an interface. you can have a light switch you can have like a little toggle switch that's attached to a battery and a light bulb and those can be kind of wired into a chassis where they have a very specific you know visual arrangement but you can also just have long wires and they can all be laying on the table as a mess but they're still connected right and the shaping session should be about those connections that wiring you know what what are the affordances on the interaction side and what are the the APIs or the basic patterns on the software side of how we would actually connect this together on the back end so that when you flip the switch, something happens and a message comes back and then we can show the user the result. That's a way of just thinking about what to do in a shaping session together. Come in with a well-defined problem with an opportunity. have a sense of we're trying to come up with something we can do in two weeks or six weeks, like have a constraint to shape against, to shape into, and get on the whiteboard together, right? And come up with an actual design that isn't just a visual design and it's not just a wish list, but it's an actual architecture of like how this thing is going to work. And when you really, you know, work on an architecture together and the technical people are involved, then you know what you're talking about and you're not going to have as many surprises when you get into the build phase. Thanks a lot. That's a good starting point. And any recommendations in the build phase? Or how does ShapeUp treat that? You know, it's funny. I have a lot of ideas about how to do the build phase because I went through it. I mean, I went through that loop many times. I love actually being inside the build phase and managing that process. The book actually, there's a whole section in Shape Up about kind of defining orthogonal scopes and there's all kinds of stuff you can get into there. But what I've learned is it seems that in, I mean, basically every company that I talk to, and I mean like every company that I talk to. I find it very hard to find teams that are actually interested in somehow formalizing what they do in the build phase. It's like there's a time box. The best that I've been able to get to is helping teams to actually have that time box and have the right people fully available inside of that time box. If you can say like for these three weeks or these four weeks or these six weeks. these two programmers and this designer or whoever it is, they're only responsible for working on this project and we're going to protect their time and attention and we're going to give them the right inputs or maybe they were even involved in generating those inputs during the shaping so they know actually what it is that they're going after and what they're going to do. If you can create that little bubble. where they're only doing that work for that period of time, that is like the fundamental change. The way that a lot of people work today is actually off of tickets. And tickets are basically like a paper shredder. It's like you took an idea that made sense as a whole, that had a lot of interdependence in it. And then you shredded it apart into separate work assignments under the assumption that if everyone did their piece, it's all going to magically assemble into the end. But, you know, I'm pretty sure that when Ikea creates their furniture assembly, you know, designs that a lot of work goes into creating something that you can modularly assemble. That's that's actually going to come together in the end. You know, I don't think it works the first time. And, you know, very often teams, they treat. custom one-off software development projects as if they were modular assemblies. Modular assembly requires you have to deliberately construct every interface. That's the definition of modular is that you have a predefined, very well, what do we say? You have a boundary within extremely clearly defined edge. right? That is robust to all the different ways that you would try to connect something to it. So what happens is the work goes through the paper shredder. Everybody picks up their individual shreds. And then there's an assumption that all the shreds are going to kind of come back together again in the end and they don't. So at a minimum, if you can keep the work whole by giving the shaped work to the team. and then giving the team the uninterrupted time to kind of stay in that context together whether that's two weeks or three weeks or six weeks that it's all about those constraints around it and kind of protecting that bubble when it comes to like inside of that build process i've learned that it's it honestly that it's most realistic and in in in 99 of teams to just think of it like a starting gun goes off You know, there's a moment of kickoff where that clock starts to tick, that three-week clock or whatever it is, and that's just a starting gun, and you don't have any control after that point. I think that's the reality of what's happening in most companies today. There may come a time where after when the right conditions are there that... some interest starts to form around how do we actually kind of strategically pick off which piece of work in which sequence. But I actually think from what I saw, even at Basecamp, you know, that art of choosing what to work on today versus tomorrow or this morning versus this afternoon inside of a build phase, that's actually kind of the black art of really great software development that gets passed on from kind of senior to junior. by working together. That's not so much the thing that comes from your so-called product development process. So if I understand you correctly, then it's also much about how to get designers, product people and engineers work together for a longer period of time and really make them ship something together instead of like one defining a ticket for the other and somehow playing ticket ping pong on the way, right? Yeah, and of course, everybody will tell you that the product people and the engineers and the business people, they should all be working together. You know, like everybody says that. The hard part... is figuring out what does that actually mean in terms of like, what do we do today? What do we do tomorrow? What do we do next week? When do we come together? And what do we do when we're together? And when do we split apart again? So I think it's really helpful to kind of look at that in terms of those two different phases. There's a shaping phase where technical people, design people, product people, or business people, they need to come together. They come together in really intense short sessions, two to three hour shaping sessions, where some project that was framed, there's a clear opportunity, there's an understanding of what it is that we're trying to go after, what it is we're trying to go do. And then inside of that two, three hour session, coming up with like, is there a specific concept that we think that we can pursue inside of a time box? That's one kind of work. And then putting people together inside of that time box as a delivery team, you know, that's a different kind of construction, right? Figuring out who needs to be together, who needs to collaborate together for this period of X weeks in order to execute that. So those are two kind of very different collaboration. situations you know those are two different things that that require uh some intention to actually design those and make those happen as as this is what we're doing today um and after that shaping phase um like the team disassembles or stays assembled or like how does it work so this depends very much on on the team there are small teams where everybody does everything, right? You know, if there's three of you, then chances are the three of you are going to be shaping together and building together because that's all you have, right? And if you've got a team of 20 people or 50 people, then of course you're going to have people who have different types of expertise. And maybe the person who is the CSS genius who can make any complicated layout work across every single device and also do it beautifully, that person might not be the person who has the same interest and skill set as doing the breadboarding and the rough sketching of the flow of the interactions and the shaping. Or maybe they are the same person. So there's a lot of different skills at play. Also, of course, on the technical side, there are amazing engineers who want to be kind of given very, very clear boundaries of a problem. And then they treat that as a puzzle and they go and they solve that. And sometimes those engineers hate the ambiguity of a shaping session. It's like their worst nightmare because they're saying, give me the problem. And a lot of the work is actually... agreeing on what the problem is or temporarily kind of entertaining different definitions of the problem versus there are other technical people who say, ah, I love it. I love it when we get to redefine the problem because here's where we really get the most leverage over it. Right. So I would say it starts with a step back, looking at how the shaping and the delivery phase is depending on the project and also because of the nature of those phases. they call for different skills and different interests. So who is participating in those is going to depend on who you have and what kind of work they like to do and actually where they feel happy and where they really feel like they are making progress, where they're really contributing. Understood. So I generally understand it as like the solution for the challenge that or the problem that like many companies apply agile. in the way that they try to apply it at a certain piece of the cake right um like only delivery um and then they try to do it in design as well and that leads to like a lot of like mini waterfalls right like in the essence it's it's kind of a waterfall process again and then there's design afterwards there's someone working on the product side and then maybe some engineer producing in an agile way some problem that has been written into a ticket and that he just has to or she just has to finish off before it is handed over to someone else and that is what you essentially like through shaping sessions and through like different durations in delivery cycles you really try to solve, right? An important thing here, yeah, that's true, but actually the key thing is, you know, the conversation today in the industry very often kind of sounds like waterfall versus agile. And waterfall is bad and agile is good. And like I said, I think a lot of it has to do with the history of the inputs that engineers get. And if you have like a giant over-architected upfront design full of specifications and none of them turn out to work when you actually go implement them, of course, that's bad, right? That's a bad waterfall. And when you have a big Figma file. full of things that look beautiful, but they don't actually work in terms of the implementation, then of course that also doesn't work. But that doesn't mean that design is bad. It doesn't mean that figuring certain things up front is bad. It's all a question of actually sequencing the work. There are, if you think about it, just like building a house, you There are a sequence of decisions that need to get made, and you don't decide exactly where the couch goes, you know, at the same moment when you are figuring out where to lay the foundation and where the load-bearing walls are going to be, right? And what's happening today is that we're so used to kind of the wrong details getting solved too early in the form of Figma files and things like that. that we think that we kind of shouldn't have any upfront design because it's just going to be a problem. But when we actually work together to come up with a buildable plan that doesn't specify every detail, that leaves latitude, that leaves the creative freedom, but we do understand, you know, there's going to be a bathroom and there's going to be a kitchen and the bathroom is going to be here and the kitchen is going to be there. And, you know, the like that we can we understand the overall budget because we we have an architecture here uh that is really really enabling and and really helpful so i would really try and kind of like uh shift the conversation more from you know is it waterfall or is it agile to we need inputs and and what are the inputs that we are creating at each stage and are they the inputs that give us on the one side, the direction that we need, do they have the specificity, do they have the technical detail that we need so we know what to go build next? And on the other hand, do they leave out the things that shouldn't be decided yet? That question of finding the right level of abstraction, the right level of latitude, that's really where the art is and it's also where the big results come. So shaping is very much about figuring out how to make that input more useful thank you um if i could ask you for three common mistakes in the agar software world in delivery um that that you see a lot um and you you would like or listen to avoid in the future what would be those three three things i i would say for sure the first the first one is uh um I would actually boil it down as simply as the three that we mentioned, you know, undershaping, thinking that the team is going to figure it out in discovery when discovery is too late. So I would not put a team under the time box and say, you've got three weeks to build something and you have to figure out what it is that you're building inside that three weeks. That's just, that's... That's not setting people up for success. The other side is overshaping, saying build exactly this high fidelity drawing that no technical person has actually vetted yet. Unless we've really, really torn apart what exactly that high fidelity drawing means in terms of implementation, it's going to be really hard to be successful inside of a time box doing that. Usually, that high fidelity drawing is just a raw input. Those are two really, really big ones. Then I would say probably when it comes to common agile practices, the third one would be the paper shredder. Thinking that we can define a ticket and then work on a ticket basis when actually most of the hard work is the integrations between the things that we write in the tickets. It's how all the pieces fit together. And do you still work with tickets or how would you do it instead? So this kind of comes back to my point about the firing gun going off. How the teams track the work that they do inside of the time box, I find is best left up to them. Because even if I try to influence that, it seems not to work. I think you see this in every ticket based process as well. I actually think that there's always a black market of real work. There's this supposedly official market of like, this is the work, you know, what's written in the tickets. But the tickets very rarely correspond to what somebody is spending their time on. Pick a random point of time during the week and go talk to somebody about what they're doing and try and trace that back to a ticket. Which ticket are you working on? Yeah, I mean, you know, I started reading this ticket last week, but I'm five yak shaves down from that now. You know what I mean? That correspondence between tickets and work isn't real. In Shape Up, I talk about the difference between imagined tasks and discovered tasks, you know? So the work that we imagine we have to do up front rarely corresponds to what we're actually spending our time doing. This comes back to thinking again about, well, what is the input that we're giving people when the cycle kicks off that says this is the work that you're, you know, sort of in theory going to be doing. Really, the function of tickets seems to be actually just as a starting point of like, here is the thing that you're supposed to go do. If we're not using tickets in that way as the sort of definition of the work, you know, then we can use a much better options. We can do something like what ShapeUp calls a pitch, which is a description, a guided tour of the project. Lately, I've actually been calling it a package because I find that the term pitch is very misleading because it sounds like a sales pitch. But if you're starting a project, it's not a pitch. It's what you're really doing. It's much later than a pitch. We talked more today about shaping and then packaging the work that was shaped. But the format that really works well there is to take, you know, the outcome of a shaping session is usually a bunch of scribbles on a whiteboard and a bunch of notes that somebody took from things that were said that seemed to be important. Or maybe, you know, there's a bunch of stickies on your Miro or whatever it is. It's not something that is comprehensible and that's going to survive lapses of time. But if you take all of that that was figured out in the shaping session, and then you put it into one document, which is like a guided tour of what we figured out we're going to do. We're going to have a button on this screen, and when you click it, it's going to run this process, and then the outcome is going to show up on this other screen, and we've already spiked the API that we're going to use to do it, and blah, blah, blah. this is how it's going to work and these are all the moving parts and and here's how it all fits together and this is what it all does when it's working and you know if you have a single document that walks through all the work that was shaped that's the that's all the input that you need for kickoff and you can take that into the time box into that two weeks into that three weeks whatever it is that six weeks and then along the way the team is going to uncover the they're going to encounter that real work by getting their hands dirty that discovered work and they can use whatever process they want to capture that you know um i've i have like you know my own like personal way that i like to do that but but um what i'm finding is that like you know the only thing that really matters you know is that uh i would say more experienced teams that have a bit more maturity they know that um whenever you set out to do something in code you bump into something that you realize you're going to need to remember later or do later, right? And the people who are more experienced, they know to capture those things and then come back to them versus the junior people kind of just try to hold it all in their head or get the easiest thing done first and then all those things later kind of come back and bite them. So there should be some kind of a mechanism for capturing. capturing work along the way as you realize what it is that you need to do. And there are things that you can do, you know, like Basecamp, like, has a lot of, as a company, I should say 37 Signals now, I mean, they have quite a bit of maturity around this. That's why ShapeUp had this whole section about hilt charts and scopes and stuff like that inside the delivery phase. But basically, all of that, all of that is just a method of capturing, discovering work. and maintaining an overview of kind of what's outstanding based on all the things that we discovered along the way. But in summary, I would just say there is going to be that black market of the real work and just somehow capture it so that if somebody says, you know, what are all the things that are outstanding that actually need to happen, that someone can produce a list and we can see, you know, if the things that we're bumping into are like little things that we have to remember or if there's actually like a you know really a a significant amount of unexpected scope that's accumulating or whatever there's there's there's a variety of ways to do that but i wouldn't be too prescriptive there thanks a lot very helpful um as a closing question um i still have a little surprise for you so your former colleague david david hanemar henson whom i also also had in the podcast a few times um he gave me this little device here And he told me that this was like a big part of your Basecamp success. And he said that like you somehow can enter a date and it makes you travel in time. And we can now like I enter, let's say, the first of January in 2004. into it and we can travel back in time and see you in the very early days at base camp and seeing how you work, how you kind of discover rails and what you do there together and all the great times and also like maybe some crazy times. And you now have the chance to whisper something into young Ryan's ears. What would it be? Oh my God. Would I have been able to make young Ryan listen to anything? That's the thing I'm skeptical of. You know, I once got a, when I graduated high school, I got a letter from a teacher who was a great influence on me. He really took a special interest in me and gave me some amazing guidance that really helped me get started in my kind of intellectual life. and he wrote me this full-page letter full of kind of life advice, just really, really practical, good life advice. And I remember reading it and feeling touched that he took such an interest and feeling like it was such a great kindness that he wrote that letter. And I did nothing. I didn't do anything that was in it until until I think 15 years later when I started to bump into all those things in my own and then I finally accepted the reality of what he was saying, you know, from firsthand experience. And probably in the end, I've tried to do all the things that he said, but I wasn't willing, I don't think, until I actually, you know, pushed my nose into the wall a few times myself. So I think advising young people is a difficult business. So you weren't acting on advice then? Yeah. One thing that took me, I think, more than 10 years to start to see was just how important it is to not only focus on the functional dimension of the work. I think a lot of us who are very technically minded, we like to kind of... turn whatever we're dealing with into a very objective problem, you know, that has constraints and it has causal factors and like it works like this and it doesn't work like that. And this is the truth and this is what will work and not work. And it took me a long time to actually start to realize that there's also a lot of human beings around. And just because I have a really, really precise answer for why something is logical or why something kind of should be done. it doesn't mean that that's all I need to be focused on. And it took me a lot of experiences to start to realize that, yeah, that there's a bunch of human beings that I'm working with and that they also have a whole kind of context around their point of view and that I should actually spend a lot more time kind of trying to understand their perspective and where they're coming from. And then... If what I think I understand can be helpful to them, then giving it to them in a way that's helpful to them, but not just kind of thinking that I have the absolute truth on something. I think I could have made a lot of deeper relationships earlier in my career if I had kind of focused more on the human side of things. And I'm very glad that I... that I managed to bump into the wall enough times that I started to learn about that. I also had some good mentors along the way. But if I could have done that earlier, it would have been nice. Thanks a lot, Brian, for being my guest. It was really entertaining. And I hope everyone now is really motivated to learn more about ShapeUp and read your book. And I think you also mentioned that you soon are launching a course. about ShapeUp and how to use it in practice? Yeah, I have a couple new things actually that can help people who are interested in ShapeUp. So there's the book. There's also a 20-minute overview video. It gives you all of the key ideas from the book in just one short 20-minute sitting, and that's on YouTube, and it's called Shaping in a Nutshell. You can also find it on my website, feltpresence.com. So that's just a really good summary that can get you an intro to all this. And then the new video course is called Shaping in Real Life. And it's an intensive course that actually goes through all the things that I've been learning by working with a much greater variety of real world companies who are adopting ShapeUp. So it's going beyond kind of the six week, two week template, you know, that you should have a designer on every team and stuff like that. If your setup at your team doesn't exactly match the conditions at Basecamp. you can still use all these different practices but it's a question of kind of understanding how to do them in more targeted ways how to run a shaping session how to do spiking how to frame projects how did you hand off differently you know like all these different kind of different ingredients that we talked about so that's all covered in this new course and actually i just announced that a couple days ago and uh you can also find that at feltpresence.com it's called shaping in real life thanks ryan I'm going to look it up and have a great day. I hope to see you again soon. All right. Thanks a lot, Toby. I really enjoyed it. Bye-bye. Thank you for listening to the Alphalist podcast. If you liked this episode, share it with friends. I'm sure they love it too. Make sure to subscribe so you can hear deep insights into technical leadership and technology trends as they become available. Also, please tell us if there is a topic you would like to hear more about or a technical leader whose brain you would like us to pick. Alphalist is all about helping CTOs getting access to the insights they need to make the best decisions for their company. Please send us suggestions to cto at alphalist.com. Send me a message on LinkedIn or Twitter. After all, the more knowledge we bring to CTOs, the more growth we see in tech. Or as we say on Alphalist, accumulated knowledge to accelerate growth. See you in the next episode.

Find out how to ship meaningful products 👍 on time ⌛ with proper product shaping in this CTO podcast with Ryan Singer, the creator of the Shape Up Method 💪. The Shape Up Method aims to better define and prioritise 🤔 projects before they are sent to be built and shipped. 

Listen to find out: 
- How to timebox effectively 📅  (SPOILER: Its not 2 or 6  weeks)
- Why tickets don’t work 🎫
- What is the ideal team composition 🎨 for each phase of the project. 
 + Why he doesn’t give specific instructions for the build phase 🏗️ (because everyone does their own thing anyway 🙃)

Listen here: https://alphalist.com/podcast/65-ryan-singer-creator-of-the-shape-up-method