Ryan Singer: Debugging the Product Development Process

“We’re not shipping as fast as we used to.” “We’re starting to miss deadlines and have quality issues.” They’re familiar problems.

In the transition from Basecamp world to the wider world, Ryan discovered that the Shape Up methodology he describes in his book, required adaptation to work in a wider variety of real-world companies. While the principles still applied, the specific tactics needed to be customised to work in other companies that were in different stages of growth, maturity and business model. In the case of Autobooks, they struggled to follow the method to the letter, until they realised that they didn’t have to. There isn’t the one way to build great product. However, there are some consistently true principles and some parameters that you can think about that as you build that will help deliver projects that impact the business on time.

In this talk, Ryan Singer shares his perspective on debugging delivery problems to get at the true causes of delays and quality issues in delivering successful product development. You will realise you may not be giving your builders the right information they need to succeed in a limited time and what to do about it.

Slides

Find out more about BoS

Get details about our next conference, subscribe to our newsletter, and watch more of the great BoS Talks you hear so much about.

Transcript

Ryan Singer 
II heard about Business of Software, I heard it was great. It’s actually been amazing. And as Mark was just explaining, I got so inspired from listening to Matt’s talk that I was already frantically adding a couple slides to the beginning of the presentation, because I wanted to, there’s so many things that I wanted to link to.

And so let’s get into it here. So I’m coming from maybe a little bit of a different world than some of you here, I’m coming very much from the place in the middle of the org, where we are supposed to somehow be getting stuff done. And so you can think of me as a proxy for whoever is your person who you think is most responsible for that.

And when we get together here, as people who are founders and leaders of businesses and people at the kind of the top of the org, the conversation very easily becomes kind of OKRs, and strategy, and organisation, and structure. And this is kind of very high level thing. And then somewhere down below, there’s the actual causality of what is physically possible. There’s the empirical reality, the ground truth of what people are doing in the world where people are struggling, why they come and buy our thing.

And then between this kind of ground truth of cause and effect, and this kind of high level of OKRs, and goals and organisational stuff, there is this whole world in the middle of what I’ll call here, project formation – what do we do right, and a lot of our difficulties. We talk about how we translate strategy into execution, or how we kind of succeed in different ways. And a lot of it has to do with this disconnect between these different layers and how we actually form our projects and how we actually go after what it is that we’re actually going to do.

I want to give a little bit of language around some of the things that Matt talked about that were so exciting. Matt was talking about these kinds of different universes:

• The universe of optimization – where we kind of know what to do, and it’s a question of tuning it; vs
• The universe of discovery – where there’s a whole lot of unknowns, and it’s never been done before, and there’s a big wide open field, and we have to figure out kind of where the oil is to drill.

And a picture that you can use, that’s a very just dumb, simple picture to give some language for this is the picture of the hill.

So actually, any work that isn’t repetitive work, that we’ve done a million times before work that’s novel is like a hill – there’s an uphill phase, where this uphill phase is where we have to figure out all those unknowns where we have to do, they were kind of in the power law world that Matt talks about, all the things that we cannot predict that we cannot schedule that we don’t understand, where we’re figuring out what it is we’re going to do. So that’s the uphill side.

Then we reach a point where we’re kind of at the top of the hill, and we say like, Ah, now I think I know what to do right. And then from there, we can see down and it’s a question of gathering the resources, there’s still a lot of things that have to get solved. But it’s more like we know what we know where to go, it’s more of this kind of optimization zone. So this is actually happening all the time and work that we’re doing, we are kind of creating work. And then sometimes we are consciously going up this hill and solving all the unknowns in advance. And other times, well, we get into trouble.

So in theory, this should be some kind of a smooth thing of that happens over and over again. But in practice, a lot of the times our hills actually look like this. Like we think that we’ve solved it, we think we’re going downhill, and then all of a sudden, some complication comes up that we didn’t expect, right? And then we think, Okay, now we’re fine. And then we go down again, and then boom, another thing that we didn’t think was going to be a problem turns out to be a problem.

So our original time when we thought we were going to be doing delivery, gets extended longer and longer and longer because of all of these unknowns that are blowing up in our faces.

So this is just a little bit of intro into what we’re talking about when we talk about debugging the product development process. It’s not that we’re so far down into the weeds of what is the developer doing today, or what is the product designer doing today? But it’s a question of like, why did these things happen? Right? And what is it that we can actually do so that this connection from what’s we’re trying to achieve on the strategy layer, and what we know seems to be possible according to the ground truth, where we actually get a connection, and we actually make progress in acting on all the different things that have to happen to move the business forward.

Disconnects

So I’ll give you a couple concrete examples. And again, if people in this room are a little bit above seeing these things, then I will be the ambassador for your VP of Engineering or whatever here.

So what do we talk about when we talk about bugs in the product development process?

Example #1

So this is when conversations like this happen, maybe you’ve heard, you know, oh, that should be simple. And you know, a few little things we’re going to do here, little thing there. Even when you talk to the engineers, they’re like, oh, yeah, no problem. You know, we can do that. Yeah. And then you make the plan, and you agree to go do it, and the clock starts to tick.

And then after a week, two weeks, three weeks go by someone in the product side is saying, you know, like, Hey, why aren’t we done yet? Right? This thing was supposed to be simple. And the engineer is like, well, hard to explain.

Example #2

Or we have other situations where product to find some work, or like, let’s say, like, the designer creates the giant, beautiful, you know, painting of this is the interface, and this is the new thing. And look how beautiful and perfect it is. And marketing sees it. And leadership sees it. And everyone looks at the looks at the beautiful drawings. And they say, oh, it looks amazing. Let’s go build it, right? But then it goes to the engineer. And they’re like, actually, no, that’s not gonna work.

And now we have to throw a whole bunch of work away, we wasted a bunch of time, like, of course, it also sucks, like on an interpersonal level, right? Because it’s like, I put my heart and soul into that thing. And now it’s getting thrown away again, right? Or there’s the opposite that can happen where the product says, Oh, we have a great idea. We’ve done all this research. And we’re going to have new fast reports. And everyone says fast reports good, powerful, fast, easy reports. That’s exactly what the customer said they wanted. And then the engineers are like, Well, I have no idea what that means. I don’t know what to build. Right? What is a fast, easy report? Like I have no idea what that is, what do I do tomorrow? No clue.

So these are a lot of the kind of disconnects that happen. Even when we do really get together and make an integrated plan. You know, where we know what’s technically possible, we have a clear concept of how the interaction is going to be it aligns with the business goal, it matches what we’ve understood about the customer struggle, even if we pull all that stuff together.

And a lot of companies today, what happens with it, when it’s time to go into delivery, it gets turned into a bunch of tickets. And this is like taking a carefully worked out project and feeding it through a paper shredder. Because now what used to be a whole thing with interdependencies and trade offs. And this is here because of that, and this will compensate for that. And then this will all work together as a whole. All of a sudden, now individual people have little slices of work. And you know, IKEA puts a lot of time and energy into planning what goes into those boxes so that they actually fit together in the end, right? And we are not IKEA.

When we, for every project think that we can split it apart into modular tasks, and it’s all in the 11th hour are going to magically fit together into the end result, what we end up seeing a lot is individual contributors who don’t have the context around what it is that this little piece of work is supposed to be about how it fits into the bigger picture, and certainly not how to make trade offs about it.

And then of course, this leads to situations where we say, well, when are we done? Right? When do we get to move on to the next thing? What is it that everybody is so busy with? And we look at a board of tickets, and we see a million things that are not finished. And honestly where we have a lot of questions, you know, is this even really valuable? Right? This stuff that I’m seeing here? Why aren’t we working on the big important stuff that we know is strategically important.

I worked with a company recently, and they weren’t having any of these problems. They were in the situation that a lot of younger teams are in when you have fewer people. And the problems are a little bit you know, it’s kind of like there’s more low hanging fruit you could say. And they had a nice rhythm of here’s how we identify an opportunity, here’s how we shape it into a viable project, and then here our engineers understand what it is that we were talking about. And they execute and this was kind of running. But then just as a natural consequence of the success of the business, as they started to grow, more and more work is coming in from more sides. There are more customers raising issues. The technical complexity is getting higher of the things that they had to solve.

They were integrating with more partners and all of a sudden there came a point where basically this conveyor belt had shut down, it wasn’t possible to even kind of feed work anymore, kind of into the engine or into the machine, so to speak, because it was just totally clogged with old work that wasn’t done unfinished work problems coming up stuff like that. I don’t know if anyone’s seen anything like this before.

You’re, you’re you’re so well behaved and concentrated, I couldn’t understand if you relate it or not, right? So actually, these things, this is not just like, necessary, these things have a cause. All these problems, they have causes. And if we decide that we don’t want to work this way, and live this way, then we can do things about them. So that’s why I’m talking about debugging.

So when we see things like hidden complexity coming up too late, right? When we see a whole bunch of work, and we’re saying, where does this add up to? And why is this dragging on so long? When we see pile ups, and we say, well, how come we’re so busy with stuff that isn’t the important thing, right?

And from the standpoint of those of you who are kind of earlier, in the growth of the company, there come moments where everything was fine, when we were a few people, everything was natural, everything was organic, and then all of a sudden, it’s like, as a founder, I can’t be involved anymore. I can’t be there for every decision anymore. How do I put some kind of a process into place so that these things run well, but I’m not the one who’s constantly chasing after every piece of work and fixing it right? Or we start to grow and the things that used to happen automatically, all of a sudden, we’re questioning like, why is it that we can’t seem to get things out the door, the way that we used to? Why can’t we seem to ship meaningful things quickly, like we did in the early days? Yeah, so these different issues come up.

37 Signals and Basecamp

I’ve been working on this kind of stuff for about 20 years. For the first 17 of those I was at 37 Signals, the makers of Basecamp. And since then, I’ve been working independently to help teams with a lot of the stuff that I learned. And the origins of what I tell you, a lot of that kind of comes from my early experience at 37 Signals. And this was an amazing time, it was such a cool opportunity to try and solve these problems because we had insanely tight constraints in the early days.

So in 2003, when I first joined, we were building Basecamp, this software as a service product. And we had one programmer, and David, the CTO. And he had a strict limit of 10 hours a week. And we had to figure out how to use those 10 hours really, really well. So our tolerance for rework was just like really, really low. And then even when the product started to take off, and things started to go well. David and Jason, the founders, they were doing something which was unpopular at the time, I think it’s becoming more popular today.

In the last couple of months, they were focused on words like profit and cost. And so they actually very consciously kept the size of the company down instead of immediately hiring lots of people as soon as there was money to do it. So they kind of artificially kept these constraints in place where there was always this feeling like we didn’t quite have as many people as we might like to have. And it was always a question of how to get things done with that and out of this kind of very constrained situation.

We did a lot of trial and error, and we were able to come up with a lot of practices that worked for us. For example, instead of having these long running projects, we would ask ourselves, we’d play this kind of game. Is there some version of this thing that we want to do that we could do in six weeks? Or in three weeks or one week? So we’re taking time as a design parameter. What is it? What does it look like? If we had to do it in one week? What’s the terrible hacky version of this actually look like? What trade offs would we make?

We would put technical people and design people together in the very earliest stages of the project formation, when we first started to shape something, so that this surprise wouldn’t come later that what we thought was going to be feasible actually isn’t feasible. But that we were coming up within our interaction concept and a technical concept that was viable, all like from the very, very first day when we had a conversation about something. We weren’t making high fidelity drawings, we weren’t making pixel perfect specifications, because there was no time for that, if we put a lot of energy into a high fidelity drawing and we knew from experience that if we did that, the thing that we could actually build wouldn’t match the perfect drawing, which took all that time and energy. And in the end also, even if it did match, it might not be the thing that we actually wanted once we could click on it.

So we said instead of doing these perfect, perfect kind of masterplan specifications with every tiny detail, we would just do kind of one pagers with very rough sketches, but kind of clear definition around the outcome and kind of the bones of the idea of how this thing was going to work, and we gave teams a lot of autonomy.

So this was we, there wasn’t the time, like I said, to kind of chase after people and say, Where is this piece of work, and where’s that piece of work. So instead of giving people the whole work, not paper shredding it into tickets, but giving them the whole work and saying, here’s a whole piece of work that makes sense, here is a whole box of time, please put the work into the time and come up with something that is a good thing, right, and we’re gonna leave you alone to do that. And there’s a lot of talk about, you know, like empowerment and stuff like that, which kind of sounds nice and is nice.

But also, from the leadership standpoint, it’s such a nice feeling, to have a period of time when you plan what to do, and you make decisions about what’s next. And then thanks to the autonomy, you actually give that work away. And then you can say, I don’t have to tell anybody what to work on. For the next, I’ve got six weeks, or whatever it is, and everyone is working on something productive and meaningful. And I can focus on other things, I don’t have to be deciding what’s next all the time. So this was kind of this, this autonomy. And so these are things that we figured out. And we were doing these things very organically. But then, of course, we also started to grow, however, there came a point where we couldn’t avoid it. And there were more and more people in the company. And these things that were happening kind of organically, and then had been learned through trial and error from a small group of people. All of a sudden, we had to figure out how to formalise this how to pass this on. So it became something that everyone in the company could do and follow.

Shape Up

And so in order to do that, I actually wrote this book called Shape Up in 2019. Is anybody familiar with Shape Up? Wow, actually, quite a few. Okay, that’s surprising.

So I wrote this book in 2019, this time box, we formalised it into six week period for delivery and then a two week period for cool down.

This idea of kind of asking, what is the six week version of this like setting in a real hard time limit, from a strategic standpoint? That this is the amount of time that we want to spend on this, which is totally different from having a solution and saying, what’s the estimate? Right?

Instead of saying, here’s the solution, how long does it take, we say, what’s the amount of time that we set for ourselves as a constraint, and then we’re going to design and prototype possibilities that fit inside of those hard walls. So as this notion of appetite got formalised there, this idea that then if we have, we’re only going to spend one week or we’re going to spend six weeks on something, the idea that we then have to make trade offs and find alternate ways to do things so that it actually fits into that time this we called shaping.

And then we formalised a lot of the different tricks and tools, you know, like rough sketches, and fat marker sketches, and breadboards, and stuff like that, for how to communicate, the way that a piece of work fits together at a level that is higher than make it fast and easy. But but lower than, you know, here’s the pixel perfect figma design. So this all came together in 2019 and we put the book out.

It doesn’t apply to all

What we discovered was that a lot of bootstrapped software as a service companies, bootstrapped software as a service companies said, wow, and they said, Thank you, and they started to use it. And we saw the adoption right away being from companies who were structurally like us. So they were bootstrapped. The people in the company were mainly senior, they had kind of seen a lot of these problems before, and they recognise what the book was talking about. And they had also a lot of designers on every team, because a big part of what we do, big part of what’s described in the book is the integration of design and engineering had many steps along the way. And they were able to take it on.

But a lot of companies, they heard about it, and they said, You are crazy, this is not possible in the real world. And that’s because they were coming from a different environment. So there were a lot of companies who weren’t bootstrapped and they had external pressures, they had external deadlines. And when there were goals and targets that were being set, you know, not just from an internal strategy point of view, but because you have to hit a certain number at a certain time. In that environment, the idea that you would have six weeks and then two weeks, and then you’d have to wait eight weeks before you can try to do the next thing. This was much too long for people in that situation.

Also, teams who had bigger gaps between senior and junior, they would be saying, saying, basically, how can I give them that autonomy? How can I just make some rough sketches and make a one pager and give them responsibility for all of that time? I don’t understand how I can trust him to deliver on that. And if you look at most software companies, it’s much more common that you see kind of this 1 to 10 ratio.

When it comes to designers versus engineers, so folks in that situation were asking themselves, Well, how are we actually going to get to the level of UX quality that we know we need to get to? If we only have one designer? And then somehow they’re just making these rough sketches all the time? Like, this doesn’t make any sense, right? So what you would think is that, in theory, all of these people with all of these objections would just ignore shape up and they would go do something else.

But I started getting so many emails, I started getting so many messages from folks saying, we’re trying to use it, and we hacked it like this. And we’re trying to use pieces of it. And it doesn’t really work for us, but we’re still trying. And I’m thinking to myself, like, what are you doing?

Like, like, Why? Why are they why are they like fighting to adapt it so much? What is going on here. And as I started to work with more and more teams to try and help them through this process, I understood actually that the alternatives aren’t so great.

Alternatives

So one big alternative that you might go for is something like Scrum or a ticket based system for managing work. And here, we can actually point out that there’s two very, very different kinds of work. There’s reactive work, where there’s a small thing that has urgency attached to it, that comes from some stakeholder, right? This thing is on fire, this server is about to is like the load is too high, and something has to happen, right? Or marketing needs this thing and we’re not going to tell them to wait six weeks just to do this little thing that marketing needs right to unblock them. So the reactive work, actually, ticket based flows are excellent for that. Because of this, the nature of the beast, right? So you have the limited resources and a lot of things that need to happen and you pick what is the highest priority, and then you allocate like that it actually is a very good fit.

But when it comes to project work, there’s no time or space in a ticket based system like Scrum, to actually think there’s no moment in the process for like, this is the part where we think it’s just like, No, the work comes from somewhere it gets sliced into tickets, and then we divvy them up and we decide which ones happen two weeks at a time.

And even if we do get a clear concept, even if we managed to somehow carve that time to think, then well, as we saw before it goes through the paper shredder, and then we lose all of the interconnectedness and the trade offs and the meaning of the whole thing, right? So for this reason, Scrum doesn’t work. And I think a lot of people are starting to recognise this, this is becoming fairly obvious today, actually.

The other thing that we sometimes see is that companies realise that just some kind of ticket process doesn’t help them to think it just shuffles the work through. So then they think, well, maybe we need to bring in more design, more UX, more of this kind of thing, more research. And so they go for what’s on the market when it comes to kind of UX research. And what they often end up doing is adopting some kind of a fairly heavyweight kind of lengthy kind of UX process. And when they do that, now, of course, there, there are times where doing some kind of a deep dive into research is meaningful, right?

There can be certain phases, where there are certain things that need to be understood. And we have to take a long period of research in order to solve that. But when it comes to the way that we actually turn strategy into action, on a daily basis, on a weekly basis, on a quarterly basis, the way that we actually operate, this doesn’t work very well. And that’s because the UX designers and the UX researchers are very, very rarely engineers themselves, or working in a process that integrates with engineering, there’s usually a pretty big disconnect, actually, between this UX research world in the world of actually building and making things.

And after long periods of time, and a lot of documentation, a lot of statements like as a user, I’m trying to do this thing. All this, all this work goes to the engineers, and I’m sorry, but they they say, this just isn’t adding value. You know, and of course, no one wants to hear it. Someone spent a lot of money, a lot of time was spent, you know, but the engineers are saying I still don’t know what to build. Right? This isn’t helping me. So there’s a kind of need there that has been pushing people saying, Hey, how can we somehow adopt this and what they’re needing is, how to carve out this time and space to actually figure out what’s next? How do we actually put that thinking time into the way that we work? And how do we do it in a way that actually connects design and engineering?

So it’s not just that we have somebody thinking over there, and then cooking up some big plan and then we give it and it doesn’t actually translate into reality.

And how do we work in such a way that our work is building on each other and we’re getting warmer and we’re getting close? Closer right to something that we can actually go execute.

Adapt, not Adopt

So I’ve been doing kind of a process of evolution to help teams do this over the last year and a half. And the number one thing that I start off by doing is sort of the big thing I’ve learned is to I have to train people away from this idea that there is like the one true way, you know, and also, the book a little bit has this feeling like, here’s the way you should do it. And actually, this is the first thing is to there’s no one true way, I’ve been breaking it into separate pieces. And these separate practices are things that can be adapted and tuned, one by one. And then they can all be kind of recombined into a process that’s custom fit. That’s custom tuned for the needs of the org. So that’s kind of what I’ve been doing.

And what I want to give you in the few minutes that I have here, I want to make sure I leave some time for questions, I want to give just give you a few of the sort of top things that I’ve learned that we’re doing differently so that this these kinds of principles and practices can work in other environments other than small bootstrapped startups.

• Shaping more rigorously.

So a lot of people who kind of hear about shaping, they put some product people or some designers kind of into that, and they think, okay, they’re gonna go shape what to do, and we’re gonna give it to the engineers and we see the things that we the same problems we talked about before. We see a lot of under shaping, we see a lot of over shaping of like too much of the wrong detail early on. And we see also that there’s a funny kind of combination of this under shaping and over shaping where they’re kind of the same thing.

Example #1

So, you know, you might, I’m actually going to give you an example from, like working on a house like renovating a house, because it’s very relatable, you know, we could have this kind of beautiful image of what the new living room is supposed to look like. And this very carefully selected lamp like this is the perfect lamp, and we looked at all lamps, and this is the right one, right? And here’s the 3D rendering of the lamp, right. And on the one side, this is kind of over shaped, you could say maybe, because we’re specifying all of the detail upfront before building anything. But at the same time, it’s also under shaped, because what the contractor needs to know, in order to put that lamp into place is not where to go by the lamp or what colour it should be. They need to know is there electricity in that wall or not.

And these are the kinds of conversations that we actually need to be having that we need to have inside of project formation, where we’re saying, it’s not just a question of what we want, but like, what’s the current wiring? Right? What is possible.

Example #2

And it’s the other example we often think of is like, if you want to have the plumber come in and redo the bathroom, and you have 100 year old house, an experienced plumber is not going to give you a quote without opening up the wall and looking behind it first, right?

So when we talk about shaping more rigorously, it’s about bringing the technical in to the planning to actually figure out what’s something that we can do within the time and budget that we have.

And how do we actually do this? Well, we do this by inviting a technical person into the shaping process, so into when we’re figuring out what the project is going to be. And before we start delivery, and what I found works very, very well for this is, I don’t know, if you’re kind of hip to the new way, you’re supposed to be doing things. But everybody says that we should only work asynchronously. Now have you heard that? It’s like a lot of people are saying that meetings are bad, and we should only work asynchronously. And this is the new modern way.

Well, I found that actually synchronous shaping sessions, very, very intense two to three hour sessions, with some of our most expensive people together in a room is the best way to kind of get through this, this uphill phase where there’s a lot of unknown, where there’s kind of this this world that Matt was talking about where it’s not a question of optimising, it’s a question of asking those really hard questions and figuring out what do we not know that’s going to kill the project, right?

So putting these three skills, product design and engineering together into a room, whatever combination of people you have, who have those hats amongst themselves, right? And having a very intense two to three hours to see if they can come up with a viable approach. And we bring that technical person into the room. And then we can have very different conversations on day zero of a project.

So here, maybe the designer says, Well, we had this idea, we’re going to fix this conversion problem by skipping a step in the onboarding process. We have the data, we’re pretty sure we can skip this step. And the technical person says, You know what, I think there might be something funny about the code in the onboarding, I seem to recall, it’s a little bit more complicated than that. And they quickly open up the code just right on the spot is is a working session, not just a brainstorming session, but a work session.

They open the code, look at the code and they say, yeah, there’s actually three different states of how people might be getting here. We can’t just skip this step, because it’s going to break the experience for partners here and people in this segment, right? Now, this is the kind of thing that might come up in week three of a project or week five of a project. And here, it’s coming up on day zero. And it’s before the clock is actually ticking, when there is still time to say, ah, we need to rethink our concept, or we need to make a different trade off. Or let’s look at the other parts of the flow to see what other possibilities we have because we’re still in shaping, we’re not yet in delivery, right. So this is the kind of thing that we can do when we bring a technical and design people together to shape more rigorously up front.

• A lot of teams who think that they’re adopting shaping, but actually the work that they’re doing is a different kind of work in shaping.

This happens very often when someone who is a founder, someone who is a head of growth, someone who is maybe a head of product, reads the book and starts writing pitches, and what they create are things that look like this. It’s a pitch for some project and it seems to be describing what we’re going to do. But when you look at the content of that, what you see are all the reasons why we should do this. It’s like all of the background reasons, here’s all the data that supports it, here’s why it’s a good idea, here’s our understanding of the problem, here’s the outcome that the customer wants. So it’s all this stuff around what why we’re doing this, but it’s not actually telling us what to build still. And this is valuable. Of course, it’s smart to actually do the work to justify spending the time on this instead of that. And we need to somehow make a pitch that we’re going to do this instead of other things.

But it’s not shaping, it’s not telling us what to build, it’s not giving the engineers the answers they need, it’s not ensuring that we’re going to spend our very scarce time productively, because we still don’t know what we’re committing to.

Framing vs Shaping

So what I found really helpful is to distinguish between two very different kinds of work with different with teams that I’m working with. There’s framing, and this is just a word that we started using, it’s been very helpful for the contrast, framing is making the case to do this.

Matt put it really well in his talk earlier. He was saying that when he does discovery that first he talked to customers, and then he played in the data, and then he used the data to support why we should go do this, right. So it’s like strengthening the case, building the case, and also getting a crispier definition of problem and outcome and opportunity in this kind of a thing.

And then shaping here you can see, it’s actually what to do. There’s some architecture there, there’s some interface there, there’s some bullet points about this is going to connect to that. And this is what the user flow is going to be, this is how we’re going to build it. So framing versus shaping, this confusion the fact that a lot of people have difficulty with this is largely my fault.

I use this word, pitch, in the book. And pitch was actually a terrible word for this because pitch sounds like you’re making a sales pitch or you’re trying to convince somebody of something. And if you’ve done a whole bunch of this rigorous work to try and work together to bring technical people in design and product together to come up with something that’s going to achieve the outcome. I mean, it’s not a pitch, you already made a big time investment in that right? You’re somehow past the pitch, right?

So what we just we discovered, actually, that now we’re using very different language for this. So instead of talking about a pitch, which is quite unclear, we say that when we’re framing when we’re defining the out the opportunity when we’re figuring out the problem, and then we’re building the case to spend time at the output of this as a frame. So we say has this been framed? Do we have a frame for this that I can bring into the shaping session, right.

And when we talk about shaping now instead of saying that we shape a pitch, we say that actually we package the shaped work, so it’s ready for delivery. When you’re in a shaping session, there can just be a whole bunch of stuff scribbled all over the wall. And for the people who were there, they’re like, ah, that’s our beautiful Eureka. That’s the moment when we got it right there when that last sticky note went there. That was when we really had the solution.

But there’s a kind of a translation into something that’s going to survive time and be passed on to different people. And we now call that packaging or the package. So those are kind of some updates. This concept of framing in the language of framing around that kind of work also helps us solve a couple other bugs that come up.

One thing that very often happens is that someone raises a problem someone describes an opportunity, someone in leadership has a brilliant idea in the shower that morning. And then as soon as the discussion starts, everyone is jumping all over with solution ideas.

And if we have framing as a piece of work as a work step that we understand in our organisation, then we can actually say to people, wait a minute is this is worth our time and focus right now, have we done that step on this, right? Or are we already diving into something when there’s a whole bunch of other unfinished work lying around? Like, what time do we actually want strategically to spend on this thing?

And when we’re in the middle of trying to shape something when we’re coming up with different solutions, and we find that nobody can agree on what is actually good enough, or what really solves it, then in cases like that, we can, again, ask ourselves, well, wait a minute, did we actually define the problems? When we framed this? Did we define the context and the outcome? Because if we did, we would have a kind of test condition or test case, we could put whatever we shaped in and say, does that solve it or not? Right. And if we’re struggling to do that, it probably means our problem definition is lacking.

Concerning Bedding

The last thing I’ll tell you about is concerning bedding, and the book talks about this notion of a bedding table. And the idea was basically that people could come up with let’s say, there’s some kind of an overall target. And then people could try to shape different possibilities of what to do next. And then this would be some kind of a portfolio of options that would go to leadership. And then before the next six weeks cycle starts, or whatever, there would be kind of this moment of choosing which shaped pitches to bet on. This was how it was taught in the book. And this is also how we did it at Basecamp. And what I discovered is that this was really only possible because we had such a luxury of time.

At Basecamp, we thought we didn’t have any kind of targets that we had to hit, we had a lot of designers, we had just we just simply had a lot of time. So we could explore parallel directions, knowing that we wouldn’t actually execute on all of them. But for many, many companies, this is simply not the case. It doesn’t make sense to pitch three things, throw two away, and only do one of them. So what I found works much better instead of that.

The other thing, too, is that people who try to follow it by the book, what they end up doing is just kind of writing a bunch of pitches as a formality or chronically under shaping because there’s supposed to be things to bet on at the betting table, and there was no time to actually do that rigorous work of figuring out. What is this actually mean? What are we actually going to go do? So instead, what’s been working better, is to actually frame an opportunity. So a little work step to say, what does this actually mean for us? How big is it? Is it more important than other things? How much time strategically, what’s the appetite? How much time do we think it deserves?

And then once we’ve, once we have alignment, that this is something important to do next from the start, then we can go on from there and kind of shape things one at a time. And rather than shaping, and then having a betting table at the end, we already have the alignment, then we use that alignment to shape inside of the constraints that we have. And then we can think of the next steps as less of a bet and more like a green light, you know, we managed to get it we managed to shape it. Now we can, we can move on to the further steps and actually execute.

So those are kind of the top three things I wanted to tell you that I’ve at least learned since first during the book.

And since working with a greater variety of companies, there’s a bunch of other stuff I don’t have time to tell you about. But I’ll just mention briefly.

One thing is we found that for sure, this idea of a six week cycle and a two week cooldown is not holy, that we’re seeing that the key thing is to consciously design a time box, strategically use time as a resource that we say haha, for this, we’re willing to spend three weeks for that we’re willing to spend six weeks for this, if you can hack it in a week, we’ll do it. Right. And that this is the key point.

And we can do this totally ad hoc, we could shape one thing, you know, and say we’re going to do this for three weeks, shape it, do it and then say what’s next, and then do a one week project or do a six week project or we can have lengths of different cycles at different cadences. There’s a lot of possibilities there.

The other big thing I learned is that the latitude is not actually fixed and universal for all companies and projects. Latitude means the amount of specificity when we define work, you know, one extreme is like come up with something that hits us OKR by next quarter, right? The other extreme is build exactly these 15 tickets as they are defined, right? Or do this exact code implementation write the query this way. And in between, there’s a whole spectrum of how much we actually define upfront. And the book kind of suggests that a rough that marker sketches kind of somehow like the magic middle zone, but it’s not true. The latitude how much detail people need, how much creative freedom they need, is totally a function of their experience, the problem that they’re solving the time that they have, who they get to work with, right? There’s a lot of constraints around that. So now we actually take make that as a per project question and then set the latitude appropriately when we’re shaping.

And the last thing is that when you’re in the situation where there’s only one designer out of 10 engineers or something like that, the model in the book of putting a pairing basically, a designer with every build team, isn’t feasible. And we’re finding that there’s actually a lot of ways to either pull into designers in a very targeted way, for a short time during shaping. And also, this is quite interesting.

If anyone wants to talk later about it, I’d be happy to tell you more, we found ways to actually treat design as an interior design step where we make all the architectural decisions up front, but then we leave freedom for paint colour and finishing and stuff like that. And we have excellent results with that we have very, very short periods of time, where it’s just like when you finish a house, like the construction goes on forever. And then somehow in the last two days, it’s like, oh, wow, everything got finished. Right. And we actually have that experience now with software teams, where it’s like a lot of architecture and a lot of engineering. And then in the last few days, it’s like, oh, wow, like it all came to life. And it looks amazing. And even this kind of interior design work, or this kind of finishing work, it can even be done on a ticket basis, outside of the cycle process. So that’s something we can talk about outside the session, if anyone is interested. So that’s just kind of a little bit of what’s happening in the, in the world of this middle zone, yeah, of project formation and trying to turn strategy into action. And you can visit my website called presents. For more, I’ve got a video, which is kind of a 20 minute introduction to this shape up stuff. So for those who don’t want to read the book, but want to kind of get some kind of a quick starting point, you can see that video there. And also, there’s a course now shaping in real life, which is kind of the deeper, intensive way to get into all the stuff that I started to talk about today about how to tune and customise this. So this works at companies of different scales. And we have actually a new cohort of that starting in May. So you can talk to me about that as well. So thank you very much.

Q&A

Mark Littlewood 
Hands up, who’s got questions. Okely dokely.

Audience Member 
Thank you very much for this presentation. This was really interesting. Hi, I implemented shape up in my last company in 2020. So actually, quite recently, after the book, and we ended up with three shaping lines running in parallel, but overlapping so that one shaving cycle would start every two weeks so that we could have the two cooldown weeks actually, to solve bugs. But the thing is, because sometimes the entire team would rush too much like, Oh, everybody always overestimates how much work they can do in how much time. So this whole, okay, we can build this in six weeks, in Europe, where people actually take vacation does not always represent Please continue to do that. It’s a good.

So that was kind of the biggest, that was one big challenge that we had. And I don’t know if you’d like to have recommendations on how to solve that other than just throwing more people that are more time at the problem.

Ryan Singer 
And the other one is getting the people together. Basically, based on functions, we have the developers, we have the designers, and we have the product manager. Very often what happened with new people is because they didn’t know the the the where we were operating in, they didn’t understand the business to the level that they would have to need to understand the problem that we’re solving for customers to actually come up with good ideas. So the engineer knows what can be done, but they don’t really understand how this will actually work in the real world. So we ended up building an entire how does the support industry work course for engineers so that they would understand the ecosystem? So it basically took over not just product, but the entire company to create like to implement this, which is a good thing, by the way. So the question is, how can we the time and resource fit and how do you make sure that like the entire company can take part in this.

So first to the to the thing about timing with the bugs and the cooldown and so on. This was something missing from the book but needs to be said again and again and again, reactive work, where we don’t control the timing, and project work, where we strategically plan the timing are completely different universes. They call for different processes, different people, different skills, different management Don’t try to use shape up for reactive work at all, just completely dedicate separate capacity to it, use a different process embrace a Kanban.. It’s it’s not shape up versus Kanban. It’s a question of like, when we’re doing project based work, how can we succeed when we’re doing reactive work? How can we succeed, they’re totally different animals, keep them apart. And you’ll find that you can manage them much better if you treat them separately, for sure. And then about kind of training the whole company and so on. I mean, it’s amazing that you managed to think of many companies probably, if they tried to do something like that. It’s a tall order, what I advise people to do is simply, in the shaping sessions, pull these three skills together, somebody, we could call a product person who really understands the business and the customer need. Somebody who understands from an interaction standpoint, like what the experience needs to be in order to solve the problem, and somebody who understands technically what’s viable to actually implement. And if you have those three skills in the shaping, you can bake it into the work at that early phase. And then it can survive by packaging, and then passing it on to the delivery team, or consulting with them, or whatever this is kind of the cheap way to do it, is to have those intensive two and three hour sessions, where we integrate our most senior people from those different areas. And they do the trade offs and problem solving. And then that little nugget that they figured out can get passed on.

Audience Member 
Craig, the latitude thing was super interesting, because the one take out when I read the book, was it felt a little bit feature focused, if that makes sense. Yeah, totally. So I guess, what’s your observation in terms of how many companies are actually using it in context with OKRs? For example, which I suppose my leading question is, how many of them has been outcome led rather than output? LED?

Ryan Singer 
I don’t think I understood the question, sorry. Well, it will if you’re, if if you’re, if your bet is a feature, and you’re saying we’re going to build a new registration process, I guess, how many companies are truly other bets on Okay, well, how many, how many companies are placing bets? An outcome rather than a specific thing that you’re going to build, you know, this is a much, much bigger phenomenon than shape up specific, the transition from being supply side focus to demand side focused, are we just talking about, we’re going to build a button and when we build the button, then we won. Or we’re going to build the button because customers need this and that and this, and it relates to our strategy because of this, and this, and this, and this is what we’re going to see as a result of that, therefore, we’re going to build the button, right? This is a this goes beyond shape up.

This is actually I think, much more in Bob’s area for the next talk. And I see these two as being completely close together, where you have to have the demand side of like, what is it that’s valuable? And what are the things that we’re going after? And then the supply side of like, what can we actually build inside of the time that we strategically want to spend. And then the place where they meet is what I’ve described today as the framing step. Because in in a tight frame, you can basically summarise a frame is two things, one paragraph of context, one paragraph of outcome, and you attach a time and you attach capacity to that. And then the shaping is somehow inside those boundaries. So some teams like for example, auto books in Detroit does an incredible job of pulling all this stuff together. And we have some really stellar companies who are doing it all. But I would say across the board, this becoming more outcome focused and not just output focused is a general maturity curve that we’re all climbing. I was thinking is where that where the two worlds meet, and you start swinging bridge towards the kind of Marty Kagan world.

Audience Member 
Thanks, I thought that was great. So I completely agree, obviously, with weed being kind of not dogmatic about how you implement this stuff, right? And different products will have different cadence and companies will have different cadence around particularly around that kind of six weeks or two weeks or three weeks thing. I’m really interested in how you’re saying some companies are doing it on almost like a per, per project per project basis. Is there a risk there that the the time changes to fit the project and you miss out on that timebox benefit of really paring the feature or whatever it is down to its core value in order to make sure you ship some version? Like do you ever get it where it kind of goes longer than like do you do like eight weeks and then end up missing out on that that constraint that helps you get to that key value of whatever is you’re trying to ship? Does that make sense? Yeah, I mean, ultimately, it’s a question of whether the the leadership and the team has decided that we we first

Ryan Singer 
Set time constraints and then we shape into that, or are we in estimation land.

And there has to be a decision that we don’t work that way that we use the time as a constraint. Of course, there’s going to be cases where it’s a week longer than we thought, or, you know, or if it was a one week thing, and it’s one day longer, like, there’s going to be that, but it should feel like the normal distribution, it shouldn’t feel like the power law, you know what I mean?

Audience Member 
So yeah, I’ve got a Ryan, I may be being thick. And you may just answer this with the outputs versus outcomes question. But this, I see how this addresses, the things take too long and we’re shipping garbage. But in my past experience, usually the reason product teams fail is they end up shipping, something people don’t want. Is that where is that caught in this process? Is that barrier, the point of the framing session?

Ryan Singer 
Very good. Yes. So what shape up is about is about getting the creating the time and the muscle and the constraints to actually release the stuff that the way that you intend to. Because for most companies, the intention of what we’re going to do and the reality of the mess everywhere in terms of execution, or just totally disconnected you know, so first we get the muscle control.

And then when we can operate the, you know what I mean? Now, now we can talk about like where to, you know, as a, you have to learn how to drive the car before you can really look at the road, right? So shape up strictly is about the supply side, then the, the place where it meets with the demand side, is in framing. So framing is where we say, we have this, we identify this struggling moment, we have we believe that a meaningful number of customers are experiencing this struggle, here’s how it ties to our strategy. And this is why we want to spend some period of time on it, right? And then when it goes into shaping, that’s actually the transition from mixture of supply demand to being I’m going to overstate it and say it’s more pure supply. You know, you will always get into trade offs, where you have to refer back to the demand to make sure that you’re actually hitting the outcome. But by and large, it’s more of a supply side question at that point.

Audience Member 
All right. Other bike stuff. Yeah. Thank you. So you mentioned that one reason why people wouldn’t adopted in the beginning is like the seniority of the of the team. Yeah. And then in the end, you mentioned the latitude, which resonated with me a lot, because I feel like that’s a way to, to kind of deal with that. And that’s why I asked like, would you recommend shaping with people, engineers, designers already in mind, or do you like, is that a separate server? How would that play together?

Ryan Singer 
Excellent question. Yeah, you’re really connected the dots on that one. So on the first order, when we need to get something accomplished, you know, in the next x weeks, then we have to work with who we have. Right? So to that extent, then we’re shaping very much to the person. And I think that’s a wonderful way of looking at it that like I know who I’m going to be giving this work to, therefore, this tricky thing, I will spell out in more detail than if I was giving it to this person. Totally. And also the latitude can be patchy, you can give a rough sketch for this thing, because you know that the interface designer who’s doing it is going to do a fine job with it. But because this query thing, this aspect of the query is very performance tricky. And this person doesn’t have experience with that this part of the query, we’re going to spell out at a lower latitude in the you know, so it can be patchy like that. That’s all on the first order of like, I’ve got to give this work to somebody, I’m going to fit the constraints of those people on the on the higher orders of like, how do we get better at this over time? How do we grow the capability so our junior people become more senior?

Here’s something where we can use a kind of process that I didn’t talk about today, but we teach in the course, it’s a kind of handoff exercise, where when we give people the work, we don’t immediately assign them to build it. But first, we actually give them a chance to kind of come back to us with an architectural picture of this is what I think I’m going to do. And we can actually have a feedback moment there between senior engineering and more junior to kind of have a lot of teachable moments about approach. And in that way, there’s a lot of learning happening there. And we’re also kind of cutting a lot of like, we’re cutting a lot of tails of things that would be like long complications that we can avoid.

Audience Member
Interesting. I think it also ties into Jason also posted recently that like the ideal size is usually two people and even two he said now, yeah, and that’s where this also comes in, like, Okay, but how do I do it with two people and this now makes a lot, lot more sense. Like having this word again, like you do so often, like having this word latitude is really helpful.

Ryan Singer 
Yeah, yeah. And then we have the latitude. Now we know what to dial right, so then when we’re packaging, we set the latitude of what we shaped in the package for that person.

Audience Member 

Sorry, hello, thank you for the presentation. It did resonate with me, because I’m kind of operating this space, having sort of come from software development into leading teams. And I very much resonated with this need to bridge the gap between the high level objectives and the down to earth. Get going with, yeah, down in the weeds sometime in the details, if you and

Audience Member 
I did find it intriguing that you thought that scrum doesn’t work. And there were some elements of reactive work versus new feature work or project work, as you call it. Very often you find yourself in situations where the knowledge about that product or the Yeah, the knowledge of what goes inside leaves in one team? Yes. So you have basically you have to reuse the same people in in both maintaining a product that was already I understand given out. And so I found very often useful to continue using Scrum. And there are some concepts in scrum that actually tie very well with what what you shared here, the spikes the the sort of investigation work that helps or the the even the Three Amigos in the refinement process with the product owner basically getting different perspectives from QA works for you as technical owner. This is only this is for people who say it’s not working for them, then we have to do something different. Yeah. Fair enough. Okay. Yeah. So yeah. I was just wondering if, if, if there is any specific reason for which scrum you think is not suitable at all, or it cannot be?

Ryan Singer 
Well, the reason that I mentioned is that there’s no formal time and Scrum, there’s no step in Scrum, to think about what we’re going to do next. And design alternate approaches and integrate the design and engineering and everything like that. There isn’t a clear moment for that. Now, I’m not saying that that doesn’t mean that people can’t do that in a scrum process. I’m just saying, when you take it out of the box, there’s no staff that says, here’s where you shape.

Audience Member 
Right. Okay. Yeah, I always encourage the product owners that I’ve worked with to engage the Three Amigos ahead of refinement sessions with the team because it does help to bring that in. Someone who speaks their language, you know, to be an advocate

Ryan Singer 
There are a lot of savvy, there are a lot of savvy scrum practitioners who have figured out how to hack their way around the default limitations and they’re doing things that are similar to what I’m talking about here. I think you see that in every framework, you know what I mean that there’s nothing holy about the balance of the framework.

Audience Member 
Thank you.

Ryan Singer

Founder, Felt Presence

In 2003, joined the team of three at 37signals that created Basecamp and deeply influenced the early SaaS industry. Over 17 years, he designed features used by millions and invented processes design, develop and ship software. Ryan’s superpower lies in the zone between demand and supply side where he helps people figure out what potential customers are struggling to do, map that to technical expertise, then shape a product concept that teams can implement.

In 2019, Ryan wrote a book about managing software development: Shape Up: Stop Running in Circles and Ship Work that Matters. He founded Felt Presence in 2022 to help product teams stop running in circles and regain the thrill of building.

More from Ryan.

Next Events