Shaping on the Go

Ryan Singer
. . . if you're working in kind of, kind of a more traditional kind of Scrum type environment, there's not really a right time to step back and question like, What is it that we are actually trying to accomplish? What is it that we want to make here? What are kind of options A, B and C for very different approaches for What a solution could be. That's just not at all a part of the process. There's no space and time for that, all of a sudden you're in, I'm not sure what you call it there. But in the States, they sometimes call them grooming sessions, where you take a whole bunch of things that people want to do. And you try and kind of squeeze them into the next two weeks or figure out what goes into the next few weeks. And that's a very different conversation than, you know, how do we actually integrate the skills and knowledge we have? And what are the different interaction approaches their back end approaches? Or maybe we use this library, maybe we write it ourselves. Like there's so many different choices and trade offs to be made. But there's kind of no, right time to do that in a standard scrum process.

Sebastian
Let's let's talk about that for a minute. Because I mean, after all, we also wanted to talk a bit about about Scrum. First of all, one thing, I find it like, super interesting that you say, in like kind of more traditional approach. And you mentioned Scrum. Just a fun fact, we had a comment on one of our like, below one of our videos today. And what he basically said is, he would be happy if his company would even be adopting Scrum. So we also have to face the fact that, that, at least at least in Germany, you can do probably a whole lot worse than then then Scrum, in the sense that there's a process at all.

Ryan Singer
But that's also excellent. It means that there's less to unlearn. There's more opportunities to even jump into something else, you know, so that's actually really cool.

Sebastian
True, true. Yeah. So what what I want to talk a bit about is what you call grooming or refinement. Because I find this like super interesting when you say like, there's no proper place to essentially challenge scope, turn it around, maybe also challenge it with designers and engineers. And but I'm wondering, do you think that's because Scrum is built the way it is? Or is it just because it kind of encourages that behavior, but it was kind of meant differently?

Ryan Singer
That's good question. I think there's a couple of aspects to this. So on the one side, we could talk about how the scrum process actually works, and kind of what it encourages, and so on. But there's a whole other piece to this, you know, there's very different kinds of work that have to happen in a product team, or in a software company. There's the work, that is, let's say, planned and strategic. There's the work where there's something that the company wants to do you as the software maker want to do that has a strategic meaning for you. And it's something that you are going to do as a project on your own schedule. That is very different from the what we could call the reactive work, something that is coming from a stakeholder from a customer from sales that has a lot of urgency attached to dit. And, and it's somehow not on our schedule to decide when that work happens, you know, and there can even be strategic work that we want to do, like maybe we want to do some kind of an integration with a partner. But because of interdependencies with the third party, we can't actually completely control the scheduling and the timing and say that this happens on our terms, according to our plan on our timeline, because you're going to have to wait for certain pieces to be done on the other side of that integration. So there's a whole class of work, you know, the reactive work, the work that has urgency attached to it, the support work, putting out urgent fires, integration work, where you are dependent on other people's timetables, where a ticket based system, which Scrum is a special case of right is a is a great way to work and probably the most appropriate way to work. And a lot of software companies, you know, when we look at this kind of from the product perspective, you know, when there are things that we want to do strategically, we forget about, you know, how much of the business and how much of everyone's time can be putting out fires and reacting to things, right. And I think we need to take this into account when we talk about process, there isn't a single process that will both serve the highly integrative creative trade off making project based kind of work of how do we want to design this feature. That's, that's a totally different animal than this little atomic unit of work came in. This thing has to happen for marketing, otherwise, they're going to be waiting for two weeks for no reason, you know, for two hours of work, right? So I think in the beginning, we can kind of separate these things and say there's the reactive work. There's the work that's on other people's schedules, and then there's the project planned work that's on our schedule. So you know, the The whole kind of Scrum system is very reasonable if you have a whole bunch of stream of little things coming in, and you have to do the best that you can, in a batch to do the most timely things as fast as possible, that's a really appropriate system. The problem is that when we start to extend that and try and use that for the really strategic work, where we want to target some kind of an opportunity, with the people we have, with the time that we have with the kind of what's going on in the market, you know, then what we see is that scrum simply was never designed to help us to really make trade offs. For example, between the interface design and the back end, or between different alternate approaches, this whole aspect of what we call kind of shaping the solution. It's, it's simply not there. Scrum assumes that there are already units of atomic work that are meaningful. And the thing is that, you know, like our project work, it doesn't come like an Ikea box, where there are a whole bunch of very carefully designed modular components that you can describe one by one, and they're all going to fit together in the design way, when we're doing a new feature, or some meaningful new development, something we've never done before. There are a whole bunch of unknowns there, we don't, we can't really forecast how it's all going to fit together. And what we're really going to need to do. So in that kind of a situation, kind of shredding it apart. You know, sometimes I joke and called the scrum process, a paper shredder for project work. Because it's like, you take something that made sense as a whole, and then you feed it into this machine. And then now you have, you know, 100 tickets, but they're not integrated. They're not into interdependent anymore, we're not making trade offs or looking at the relationships between the work anymore, we're kind of artificially treating it as if they are atomic units, and they're all magically going to fit together in the end. So when it comes to project work, you know, that's actually that's a place where scrum really doesn't help us very much,

Sebastian
then it's actually super interesting, because, I mean, that's where scrum really claims it has its value, right? I mean, it's about basically delivering value. And what what you describe, or what you describe now is that you feel that it's really good for this kind of maintenance and reactive work,

Ryan Singer
which is still valuable. I would I mean, I would still call it value. But I would say it's different than kind of that kind of product led those product led strategic efforts. But here's the other thing, too, is remember the origin story of Scrum, right? Scrum came out of the agile movement. And let's say the small a agile. Yeah. And the the agile movement was created by programmers. It wasn't created by designers. It wasn't created by like product people. It wasn't about the integration of all of those different things. It was about the fact that programmers were constantly getting clients telling them no, that's not what I wanted. No, that's not what I wanted, actually do this instead. So they were changing requirements all the time and coming to the programmers. So if you're in that environment, and you don't get to control the scope, and you don't get to control the requirements, you are actually doing reactive work all the time. You know, and it's only in the last, what, 10 years that this whole kind of notion of product started to really gel and become something known, something that really exists in the industry. And now that this kind of product function exists, we are no longer in that universe, where there are engineers or programmers somewhere who just get people asking them to do things all the time. But we, for example, in teams who are working in a shape up inspired model, we're bringing programmers and product people and designers together in collaborative workshop sessions to actually figure out what it is that we even want to build before we make the time commitment.

Sebastian
That's, that's super interesting. Because what I would, I would so be being the devil's advocate, here for a minute, I would argue that you could also do that in a refinement session, but we have already talked about that. It's mostly not happening in refinement sessions properly. So the question is, is that because we use Scrum in the wrong way? Or is it because the framework so I know that I'm repeating the question, but I find this like super interesting now that we are talking about it is that is that the kind of Scrum because also of the origin story, you you describe, kind of encourages this, this behavior of basically, I want to say, Taylorizing development work.

Ryan Singer
So I don't want to overdo it in the response here because I've seen some interesting cases. You know, I same companies who were fairly large, who had an engineering team in place, and that engineering team was doing Scrum. And those teams understood that they needed to somehow make more progress on meaningful strategic work. For example, we did a project with auto books based out of Detroit. And they did an amazing job without changing the way that engineering works, just by bringing one very senior engineer into the product team. And much more deliberately, and let's say more technically shaping the work that they were going to do before it ever went into this, what you call the refinement session of Scrum. And what they were able to do in that case was, basically, they knew that they had to feed their work into this machine, you know, so they could treat that machine as a noise factor and say, This isn't something that we control, but we can give it a better input, you know, so what they ended up doing was they did more, let's say, upfront technical work to really understand how the bones connect, and that there's a clear kind of viable approach and the architecture of this thing. And by doing that, they were able to basically feed in what then kind of became standard tickets and stuff like that. But it was much more deeply considered. And it was considered in an integrated way with input from business and product and designers in the shaping sessions. So it is actually possible to, to treat these as separate thing. So you know, that we can do very integrative shaping, and then feed that into a scrum process. Now, of course, we're not going to get exactly the same results as if we had an autonomous team who wasn't slicing things into tickets in the first place. But but that is, you know, that is possible. The other thing that I've noticed is that Scrum, actually, we could call it basically a delivery process. And it presumes even in the word refinement, it presumes that there's already some input coming in of what the work is, yeah. And what I've noticed is that, whether you're a scrum team or not, actually, it kind of in a way doesn't even matter what methodology you use. Once us, a cycle starts or whatever unit of time, like some shape up teams have three weeks cycles, some have six weeks cycles, sometimes it's a variable time box. And in Scrum, you have a two week cycle most of the time, but whatever that time box is, when that time starts, it's like the gun going off at the beginning of a foot race, you know, and it's just kind of like, you can't influence anything. You know, it's like, okay, the cycle starts, and then everyone has all over the place, you know, and it's in Slack. And there's just, it's just the work is starting. And so I had a lot of actually, you know, we there was a lot we were doing, for example, at base camp. And there were things in the shape up book, about how to work inside of the cycle and inside the delivery phase. And one thing that I've learned is that in a lot of, from working with a wider variety of teams, it usually helps to actually begin by saying the delivery play, the delivery time box, is the place where we have the least influence over the outcome regularly. And that it's, it's mostly about how we make trade offs and how we actually shape what it is that we think that we're gonna, we're going to actually go do in that time. And the more clarity we have, the more boundaries we have, the more we really understand what it is that we are accomplishing in this two weeks, or six weeks, or whatever it is. That's actually where the big gains come from.

Sebastian
I gotta say, one of the things I really love about shape up is the way how explicitly it kind of integrates engineering into into discovery. And then what you what you call shaping, I really enjoy that because this is also one of the things that we are both Thomas and me are very vocal about that discovery is basically completely missing in in Scrum and that, yes, doesn't really help to be honest. So I mean, I know that it can be done around it, but it just doesn't help that there's no mentioning of it. In it and it makes perfect sense. You you remind managers of the of the back story of Scrum just a minute ago. So let's let's talk a bit about about shaping and, and how it can can help you already touched on that in terms of, but maybe you can just just take five minutes and explain the kind of gist of it. How it works because I'm sure some of the people who have joined already know what it is. If you haven't, you definitely should check out Brian's book. And definitely also check out his introduction into shaping. We can just put that in In the chat and a little bit later, but maybe you can just give us an introduction into what it what it actually is, and how it can help you opposed to Scrum.

Ryan Singer
Yeah. So shaping is is, is basically what happens between when an idea is raised, or we think we should build this feature, we think we should build a calendar, we think we should build, you know, the event database. So the notification system, there's this idea that comes up, and then somehow that idea gets turned into work, you know, that has to be done. And maybe it turns into tickets in one environment, or it turns into a brief and another environment or a package of shaped work in a shape up environment, whatever it is, some thing has to happen, some process has to happen there. And what you very often see what happens naturally, is someone says, you know, we should add it, you know, we should add an events layer to our intranet system. So, and let's add, let's have a kind of an inner and an outer level of communication for people who want to know about the event versus people who are participating in the event. And someone starts as soon as the you know, the customer, or the the product person, whoever, whoever it is that has the idea, even says the idea. They are like covered in in solutions, you know, I mean, like everyone is jumping all over them saying, Oh, we will do this. And we'll do that. And we'll do this. And we'll do that, right. And naturally, what happens is, we kind of wrestled with this conversation until we feel that we have some clarity about what to do. And we kind of land on the first thing that everyone thinks we should do. And now it's somehow like, well, that's what we agreed on. So now we have to build but we all agreed on. And so the scope gets fixed very early, and a kind of chaotic, urgent discussion of everyone's just impulsive ideas, right? And then, and then we end up talking a lot about struggles with estimation, right? This is a famously difficult topic estimation. And the whole concept of estimation is that we already know what to do. And all of our problems are about how long it's going to take. And what we do with the idea of shaping is that an idea comes in, where we are going to add this layer to our event system, right? Where we have inner outer levels of communication for people interested versus the participants. And now when we say, Okay, are you really going to invest time in that? Yeah. And let's say we have a good business case for spending time on that, then we say, Okay, we are not going to just throw some work at people, we are going to try and understand how much time do we strategically want to spend on that we call that the appetite and shape up? What's our appetite? Is this? Is this something that we just need to somehow resolve in some way, in the next two weeks? In which case, there might be a lot of, you know, clever hacks or temporary solutions? Or is this something that is, let's say, competitively meaningful for us or differentiating for us. And we would actually be very happy spending six weeks or even maybe more than one cycle, eventually building this thing out. So then we have a sense of the amount of time that we're willing to spend, we might also have other constraints, like who's available to program right now, very often the person who we might want to be building this is totally up to their neck and some other things somewhere else, or other people are going to be interrupting them for their time. So not only how long do we want to spend, but what is our capacity, who's available, who on the front end, in the back end, could we pull into a project in the near term, then knowing that we can start to play with different ideas of what the solution might look like. And this is before we've actually committed to building something. And this is like, I like to use the example of home renovation, because it's something very familiar to a lot of people, you might have the very clear idea in your mind that you want to change the you know, renovate the bathroom, and it's in a house, which is 100 years old. And you could have the perfect idea in your mind of why it's worth doing it. Now, the plumber is available to you know, all the workers are available, you have budget for it, but you don't actually know what's behind the walls. And until you've actually opened up the walls and checked out what's going on, because old pipes, you don't know if it's going to be a 10,000 year old project or a 30,000 euro project or whatever, because you don't really know the what's involved in doing it. Right. And of course, if it's something routine that we've done 100 times before Then we are in a different regime. And this is not the type of work we're talking about. But if we're building something that we haven't built exactly before, there are going to be all of these unknowns. And all all of these kinds of trade offs waiting for us, once we encounter those unknowns, you know, once you realize that, oh, that this is more complicated than we thought, now we have to figure out well, how much of the original project Do we still want to do? Right? Or is there a different way to do it? Or can we rethink what the problem is? So normally, what happens is, teams kind of think they know what they won't draw a bunch of specifications or requirements. So maybe a lot of figma drawings today is something what you would see. And all those figma drawings kind of represent our imagination of what the new bathrooms should be right or the new kitchen. And then it's an only in the last moment, when we think we're starting the project, that it goes to the technical people, and they say No way. This, our component system doesn't actually work that way. And actually, we have a library that does this already. And this isn't compatible with this. And the whole concept is, there's a lot of rework happening, you know, so, and a lot of teams are actually just used to this rework, as a part of normal life. And actually, this rework, you know, when you're committed to going down a path, some figma drawings were made, we're supposed to be building this, somebody promised the customer, it's already on the roadmap, all of that, right? Now, there's a bunch of unexpected complexity coming up. And where did those go, they become tickets. So we're also kind of drowning in our own unfinished work, and the additional unplanned scope from the things that we tried to, to plan earlier. Right. So this is difficult. So the whole notion of shaping is that we carve out a work step. It's not a meeting, it's not coding, you know, it's actually a work step, where when we have a raw idea of we think we need this new thing in the event system, or we think we need this new functionality in the calendar, then we get a more senior technical person, someone who understands how the things were built, we have someone who understands the business case, or why this is important. And we have someone who understands the interaction design the experience side of this. And it could be that you have the unicorn person who has all of those in one, it could be that you have two of those in one, you know, there's different possibilities. But those skills are somehow present. And those people come together in a room synchronously for very intense, maybe two or three hours. And by pushing and pulling and getting into the concrete details, the idea is to come out with a more clear kind of rough sketch of not only the interactions, but also the architecture, of here's something that we have pushed and pulled on. And we have more confidence that this is something that is going to move forward, that is going to, we're going to, you know, put it into a time box, and it's just going to start happening, it's not going to blow up with a whole bunch of complications, it's not going to come back to us with a whole bunch of unanswered questions. But we have actually shaped the work so that people know what to do. And it's going to fit into the time and capacity that we have to actually deliver.

Sebastian
So what you're basically saying is that you kind of have have this work block that is way more like that happens way earlier than a refinement would be because in a refinement usually like the product manager would sit down with the designer and like do these, like super glossy figma thingies. I've already showed it to the stakeholder to the clients or whatever. And then it basically hits engineering and they're like, yeah, that's, that's super sweet, but we can't really deliver on that. So what you're saying is that you are you're basically getting before that even happens, you get like the right people in a room for an intensive session in order to figure out what, like what the product manager was thinking about, actually makes sense and can be delivered and talk about like the basically what you call like, what the appetite is. So what, like how much you want to deliver of it. They're getting Yes,

Ryan Singer
yes. And, you know, if we think about the example of the bathroom renovation, it means that we are not agreeing on the perfect color for the tile. Right. If you want to have a perfect rendering of the final bathroom, that's a very different output. Then if you want to have a, let's say, clear and precise, schematic drawing of the way or the wall has to be opened, where the pipe has to be moved. You know what I mean? Like these kinds of things. And so the result can be precise. But it's not hours and hours and hours of a designer's time, also falling in love with the concept, right? So we differentiate between, you know, figuring out what are the architectural decisions that are necessary for the project to be successful? Versus what are all of those kinds of details that can get worked out later, once we're committed to the project? And it's not going to blow up?

Sebastian
So, coming from an engineering background myself, I would say, Wow, that's, that's absolutely fantastic. Right. So I mean, I'm a strong advocate for basically getting getting technical people into these processes and into discovery very early. But how about like the design perspective? Because I can imagine that, because like, one thing that a lot of people told me in the past was, we have to think about what what is possible without knowing, like the technical constraints at first, so that we can actually think kind of outside this, this technical box. And I was wondering, because I could imagine that you have been confronted with this, this argument before. And I was wondering how you are usually responding to that.

Ryan Singer
You know, all of this fits together very well. So if we there's, there's a micro version of this, which is kind of the everyday projects. And there's the macro version of this, which is kind of the big visionary, reinvention and stuff like that, you know, but let's just start on the micro level. It's very healthy, inside of a shaping session, that someone who is, let's say, looking at the problem more from the perspective of the user experience, says, but maybe there's a way I get that there's maybe not a way today, but But could there perhaps be a way where we could do this totally different interaction? Right? And because the clock hasn't started to tick yet. Right? It's, it's a, it's a very different conversation, when we're talking about hypothetical work, right? The designer could have a totally visionary idea, or a novel idea or something very creative. Something that hasn't been done before, technically. And the technical person might say, that seems hard, or we've never done that before. That doesn't mean that the technical person wins. And we never do anything hard. And we never do anything new. Another term, which actually didn't make it into the book, but which has become very important, since I put the book out, is spiking. spiking is where we are in a shaping session. And we're talking about maybe we could do this, maybe we could do that. And then unknown comes up, we say, Oh, I don't really know how hard that would be, I don't really know if that's technically feasible or not. And we say, let's do a spike, how about you play around with it and see what might be technically possible by exploring a little, and spend an afternoon on that, and then we'll come back for another shaping session in two days, right. So there's actually way more possibilities for that push and pull, and for kind of digging into that kind of r&d work when you're not on the clock. And, and the thing is, then, if you do that exploratory work, before, before, before you commit to the projects, then when you're actually kind of on the clock, and you're inside of that time box and the delivery phase, someone has done the due diligence to understand that there is actually some kind of a way to do this, you know, so that's a very, that's a very productive way where you basically get to have it all, because you're creating different moments in the process. For more exploratory work versus work that we're more confident that we can actually execute. When it comes to the kind of very big picture visionary stuff, there's a difference between, we have a team that is going to become free in two weeks, and we have to give them work to we have something that we think is really important strategically for the company. And we would like in six months from now, to be able to start actually giving teams something to start building. So then we could take a six month period, where we strategically decide to go into deeper kind of extended, spiking on different kinds of r&d to discover what's actually possible and to really push the boundaries. So this is the false. This is a false contradiction, but it's a real contradiction. If you're inside of a scrum type system, where all of the work happens on the clock under the time pressure inside of Sprint cycles, right? You need to carve out that separate space where we say we're not in a delivery cycle right now, but we're shaping an inside of the shaping time. That's where we can actually entertain things that are not possible because we're in a different space. We've carved out time for this kind of work.

Sebastian
Well, I have so many questions, so many more questions. But there's also like a couple of questions in the chat already. So let me just put it out there. If you have any more questions, put them in the chat, so that we can go over it. I gotta say, this has been like, really insightful so far. And I hate to regret regret to say that shaping or like, in general, shape up, it's not not part of the curriculum of the product masterclass yet. But after the conversation today, Hey, we should make it part of it as an alternative methods to not only like delivery, but also like a full fledged delivery discovery process. So, yeah, in any case,

Ryan Singer
we actually have a we have a course called shaping in real life that my wife and I created together. And in the beginning parts of this course, we actually talk about how, you know, shaping might be a term that kind of comes from the stuff that I wrote, you know, but but actually, everybody is shaping in some form, right? There is some way that the team is kind of working out what to do before actually making that commitment inside of the time box, right. And so one of the things that's been really fun for us is to step back and see how can we just put different skills into place or you know, different practices to help with that shaping that anyway has to happen in some form.

Sebastian
That makes that makes a lot of sense. So I put the link into the chat, if you want to, you want to check it out. Feel free? So let me go through the question. And of course, one more thing, if you want to get updates on our LinkedIn lives, we're doing this quite regularly. So just basically, like our page product masterclass. And if you are looking for either upping the product game or advancing your product career, definitely also check out the product master class. And we have very regularly have people like Brian, with us falling in lies to share their knowledge. And again, thank you so much for that. So Jung had a question. So he said, I know at base camp, you do have the setups of a designer front end and the back end engineer as kind of a dual working six week cycle on a scope of work? How critical is it for shape up to have very small teams working on a scope? So

Ryan Singer
I would say that it is a so I think there's two pieces to this one is the question of small teams. And the other is the fact that the designer is always there. I should I think speak to the designer part first. Most companies that I've encountered do not have enough designers to pair a designer with the programmers on every single project that's going throughout the duration of the project. Usually you have something that's more to the other extreme, like one designer for 10 programmers. So this is definitely a place where shape up as it was practiced a base camp is simply not going to work for a lot of teams. So we actually have a lot of interesting ways of dealing with this. There's a lot of workarounds from doing certain pieces of design upfront in the spiking to actually identifying which aspects of the design are more like choosing the tile in the bathroom, which things are more like the the the paint and the beauty and the layer on top as opposed to where does the wiring go? And where did the pipes go in this kind of a thing. And in that case, actually, there's a layer of interior design that can very, very meaningfully happen on a almost on a kind of a ticket basis. After a cycle of work has been fully built out. There's some really interesting things that we're actually seeing with that. But that's another topic about this small teams. I don't think that this actually is a shape of a specific in any way. I think that you'll find that if you try to give four or five people a technical task, that it's it's it just makes it more complicated. for software development, most things are better scoped down to something that two or three people can execute together. And even Yeah, I really not more than that, you know, if you have more people than that, usually it means that there are kind of extended part So the stack that you're trying to deal with, you know, you're not going to have four people all working on the same part of the same back end piece of code simultaneously. It's just not possible, right. And if you can untangle those into separate streams of work, because they're actually not in the same part of the code, then it's going to be more productive to have a tiny team working on this piece of work with these clear boundaries, and a different tiny team working on this piece of work over here with those clear boundaries, as opposed to trying to put a bigger team together. I think that's, I think that's probably quite universal, and not really shape up specific.

Sebastian
super interesting. He had like, basically one part of the question that I left out, but I think you already scratch on that. He asked, what is breaking first, when you scale to product team, whether it's product manager UX, multiple engineers have platforms?

Ryan Singer
Yeah, so I mean, a lot of things. I mean, honestly, if you if you take the book as the one true way, many, many things will break for a lot of different companies, because the base camp had some very specific attributes, you know, base camp was bootstrapped, and had a high ratio of senior versus Junior technical people, there were a lot of designers relative to the number of programmers, there were a lot of things there, you know. So there's going to be a lot of things in the book that don't directly map. That's actually why we ended up making this course the shaping the real life course. And a lot of the work that I've been doing over the last year and a half, two years, has actually been about taking all of those things, which are kind of the one true way in the book, and turning them into separate practices that you can kind of adjust and tune one by one to make them fit. For example, if you have an existing organization, or you talk about kind of scaling up to a size where you have multiple product managers, one thing that you can do is you can look at those people that have that title, product manager, and you can, roughly speaking, I put them into two kind of categories, there's going to be one category, which is in some companies is going to be more responsible for communication and ritual. And there's going to be another category which is more responsible for deeply understanding the business problem and the customer needs and so on. In the case, where you have a product manager, who is mainly tracking, communication, and ritual, and so on, their ability to contribute will actually diminish in an organization that becomes more and more following shape up style way of working, because there's less of a need for that. But when it comes to the product manager who deeply understands who's kind of responsible for understanding what matters, what the customer is trying to do, where it's what's going on with the business, how different priorities are competing, that person is super valuable in a shaping session. And we also talk about work step before shaping called framing, where we actually are making the business case to spend time on something, right? How do we even make the decision that we should shape Project X instead of project y. So there's a lot that they can do there. And I talked about the shaping sessions with the technical person, the product person, and the designer, and here the product person can be very useful. Wow, this is

Sebastian
like, I think this is the topic in itself. So I could probably spend a lot of time talking about it. Because especially like the there's always I think in in Europe, especially we have this argument about like very, like, long standing argument about like product owners and product managers, and especially in the US, you predominantly call them product managers what they are in Germany's in Germany, we have a lot of people who actually have the title product owner and they are like, fairly often what you describe that kind of communication Central's, like I call them, like requirements, translators, because that's what what happens a lot. And I mean, if you use product, people like that, you only get like, 1/3 of the value out of them. So yeah. Yeah, I just did that because it kind of struck a nerve with me. Yeah.

Ryan Singer
Yeah. I mean, that that role, which is more communication and kind of ritual based is is is of course useful when you have a lot of chaos. You know, and when you have a lot of disconnects, right? When you have requirements coming from these people over there and they're not actually involved in the session, when you design what to go do and the technical people weren't involved in that conversation. There become all of these difficulties that that arise out of those disconnects those gaps. And then of course, when you have a lot of difficulties then you need help to manage all It was. And it makes sense that you would have a lot of communication work to be done, you know, and a lot of coordination and communication. But the more that you start to integrate the person who thinks they have a requirement and the person who knows what's viable to build, and so on, in shaping sessions and framing sessions and spiking sessions, you will discover that the communication outside of those sessions is much much, it's honestly a lot simpler. And it's a lot more straightforward. So so then you have this shift from the Yeah, from the person who was kind of hurting all the cats to product is more about actually having the domain knowledge and the business understanding.

Sebastian
I have another one for you. This is a little bit more controversial than the last one, I would think so shantala. It's not asking but stating sounds like dual track agile discovery plus delivery.

Ryan Singer
So I think that's a very natural response when you hear this because if you look at it from far away, they very much look the same. The difference is that if you go into what is usually called discovery, I would say that it's hard to actually pin down, you know, what happens? On on what happens on the two and three hour, the two or three hours you have on the afternoon on Monday? And then what happens again, on Thursday? And then like, how does that become a project, I would say that there's not a lot of, in the experience that I've seen, at least, the discovery tends to be a very big umbrella, this word discovery, it's a big umbrella for a whole bunch of different UX practices and research things. And, you know, and and usually, and I won't say never, but in most cases, it technical people are not involved in that process. And if a if I'm really honest, I would say it's also because they don't have the patience. Because very often this, this was called discovery can be so kind of open ended, that it's, it's not targeted enough. And the developers actually don't see really clear possibilities to contribute in those conversations. You know, for example, if in some discovery work, there's a lot of user research, and there's a lot of talk about stories and journeys and personas and stuff like that, it can be that there's not a lot of cause and effect in the conversation. And in cases like that, there's a kind of missing step of, okay, we've learned a lot of really interesting things, you know, and and, and there might be a lot of really good seedlings of projects here. But now still, how do we turn this into something that we can go do and finish in four weeks? Right? That is very often kind of missing in those processes. And so I would say, you could actually have a dual track agile kind of process. And you could have a lot of that discovery stuff in place. And then still, it's a question of how do we take all the things that we learned, and bring them into a conversation, which is more focused about kind of what to tactically do and a smaller unit of

Sebastian
time. So So what you're saying is that the real, valuable conversation that you got to have is about like, not not necessarily about the scope, but how much time you want to spend on the problem, and then let the team figure out the scope themselves.

Ryan Singer
It's all valuable, it's all valuable. So very early, wide ranging discovery is valuable. You know, figuring out like, like, the exact time and capacity and who's available to work on what is valuable. It's just that like, we have to come to a point where it all starts to close in and we're actually making the trade offs. It's like if you've ever had to buy something that you don't know how to buy, like if you if you're buying a car for the first time in many years, or you have to buy like, you know, you're buying like, like a video like a like a DSLR that can take video and you've never bought one like this before. It first you think you're just gonna go to the store and buy it. And then you kit you start comparing and you're like, oh, like, how do I choose? You know, so there's this whole this is really hard process of actually narrowing in on what are we actually doing? What are we actually committing to, you know, so the things that I'm mainly kind of trying to help with when it comes to this sort of shaping sessions and getting clarity around what it is that we're doing. It's all about like, just that work step that somehow has to happen.

Sebastian
I have another one. Now coming from shaping to the framing space for the cause, asking is the framing space more related to jobs to be done and uncovering demand?

Ryan Singer
Well, that's that's a very astute question. To answer it, I would step back very briefly and say that there are kind of two sides of the product development universe. There's the demand side and the supply side. And the demand side is where we try to understand people's lives. And the supply side is where we try to understand what we can build. And as product people, we somehow have to link these two together, right? If we if we know what to build, and we say, oh, let's make this button that does this thing. Well, we might be able to ship that. But if we don't understand how that would fit into somebody's life, and what they're doing today, and why they would do something different from what they do today, then, you know, we may find that after we ship it, it isn't used the way that we intended, or people don't value it the way that we thought that they would, right. So these are, these are totally different kinds of work, right? On the one hand, everything that we build on the supply side is, in a way, kind of under our control, right? Because we get to decide what to do. And what people value and what people are trying to do in their lives on the demand side, is a purely empirical question of like, what is happening out there, we don't get to influence that. So these are two different worlds, when it comes to framing, framing is actually the place where these two meet. So on the on the demand side, there's a question of what is going on in the world where someone is struggling with what they already have, and we might be able to do something that would be better for them. Right? So there has to be some struggle, something where people aren't satisfied already. And that creates some opportunity, then there's also the question of, you know, how much will they value it? This is also coming from understanding their context, to understand how how meaningful it is or how important it is, then it's a question of given our understanding of why people want this and what they're trying to do, how much time are we willing to allocate to this? What's the case that we would make internally to dedicating our supply side resources to building something? So you see, there's kind of a link there. So I would say that to the demand side half of that framing work, then for sure, I would go to the job to be done kind of world to answer that work. And that's absolutely kind of how I think about doing it for sure.

Sebastian
Great, I think I have a last one that I just saw. So Nick is saying a couple of things, but he's also asking some things, so bear with me, it's gonna take a minute. So Shape Up is clearly the result of years of practicing adjusting and tuning the methodology. And the handbook does a really good job conveying all the ins and outs to start adopting it into your, into your own organization. But undoubtedly, as we all do, you gain new insights and learnings over the years. So I'm curious to know what sections you would add or adjust besides spiking, based on the learnings you had from the moment the handbook was originally published until now, and he's adding something else can we expect the second edition of the handbook anytime in the future?

Ryan Singer
Uh huh. So I mean, there are quite a few things. The the, the core principles are all very much intact. But when it comes to how to actually put it into place, so that it works on a company by company basis, here, there can be a lot of differences. So for example, the book says six weeks cycle with two week cooldown. And what we've seen is that that is a very good fit for companies who are self funded, and who aren't under kind of strong external pressures that get to set their own course. If that's not you, then it can totally work to actually set time boxes on an ad hoc basis, like we're going to do, we're going to shape a three week project, then we're going to do a one week project, then we're going to do a four week project, you know, this. So the length of the time box is actually not something holy at all. But the book might make it seem that way. Having a designer on every project will enable more possibilities. And there's a lot of fantastic things that come out from working that way. But it's not a requirement to do shaping. Shaping is actually about knowing who is going to be available, and then coming up with work that is going to be meaningful for them given those constraints. So if there isn't going to be a designer, we still have to shape work that the technical people can go do that. It's going to be a really efficient, meaningful use of their time. So this actually doesn't depend on whether or not we have designers inside the cycles or not. Let's see, there's quite a few other things, the another big one would be the betting table, the betting table assumes that you have the luxury of shaping a variety of different things. And then you're going to kind of look at all of them and then take one for the next cycle. And in many companies that is not realistic, and it's not a good use of time either. In those cases, it makes more sense to be very, very targeted, and say, here's a potential project. Here's something that customers are telling us about. Let's see if we can frame that. Then when it's framed, and we say, Aha, we've made a good business case that this is worth pursuing. Basically, we could make the bet at that time and say, we're going to invest time into shaping this. And assuming we can shape it, we're going to give it a green light and go do it. So instead of a betting table at the end, where you have a kind of portfolio of different pieces of shaped work, it can make sense in a lot of companies to be very kind of one by one, you know, this thing seems important. Let's see if we can frame it. Yes, we managed let's see if we can shape it. Uh huh. It looks good. Okay, let's go deliver it. The last thing maybe in connection to that is this word pitch has caused so much confusion. Because you know, pitch sounds like you're trying to convince somebody you're trying to sell something. And the thing is, if you've, when you've understood that shaping actually is more technical than the book might have made it sound, I think a close reading would would still get that through. But if you really do the work of making the technical trade offs in shaping, you're not just making a sales pitch in the end, this is something you put a lot of time into, right. So what we've understood is that it makes more sense to talk about the shaping the work. And then packaging, what we've shaped, taking all of those scribbles and you know, everything that's on the whiteboard, or on the mural board, and then kind of formalizing that into a document that is going to survive time or survive the changing of hands. And we see that the package, and then the kind of the spirit of a pitch of like, I'm going to try and make the case that we shouldn't go do this, this applies much more to framing. And there we actually now call the output of framing a frame. So you know, we we we kind of can eliminate this confusion by taking that word out. That would be one thing that if I could go back and just, you know, on the on the on the original text, it would be helpful to change that language.

Sebastian
Got it? Yeah, I can see. I can see why this, this might have been a problem for some people. Yeah. So that I know, there's like so many more more questions out in the chat, but it is six already, NEC in Germany. And that means we have reached our time box for this event. Brian, thanks again, so much for joining us. This was again, like a super insightful discussion. And I'm pretty sure that a lot of people who joined today took a thing or two that they can take home. And think about whether they are adopting a shaping for themselves and their companies now. You are the guests. So you have the last words. Is there anything? I would just like to offer that. Yeah, thank

Ryan Singer
you. No, I would just say thanks a lot, because I actually really enjoyed it. And also very interesting questions. And yeah, I really enjoyed it a lot. For next steps. If anyone is interested in more, they can check out the website felt presents.com. If you're totally new to shape up, there's actually a 20 minute kind of overview video there called shaping in a nutshell, that will give you kind of the core principles and some of the key ideas. And as I mentioned before, now we have the online course as well shaping in real life. And that's where we get into all of this new stuff of shaping sessions and spiking and framing and packaging, and really look at kind of how to do it and how to tune all of these different steps and practices so that it can be something that's customized for your organization, as opposed to doing it purely by the book. So you can sign up for the waitlist there. And we'll have probably another cohort coming in May we're planning or we'll do another group going through the course then.

Sebastian
Perfect. So definitely, highly recommended. I saw a lot of hearts and clubs in the chat. So I can see that people enjoyed it. And

Ryan Singer
maybe one of the things is you have you have quite a few in Central Europe in the audience. And I'll also be speaking a bit in Europe in May. So I'll be in Paris on May 24. And in Madrid on May 26, I believe, and those are both for live product columns. And so it'd be great to have people show up and to be able to meet him person and and say

Sebastian
hello. Perfect. So if you want to meet Ryan in person, come to Paris, come to Madrid. And yes, again, thank you so much Ryan. Thanks for joining us tonight. And, yeah, hopefully talk to you very soon again.

Ryan Singer
All right. Take care.