Closing Keynote: Shipping What Matters || DL Summit 2024

So now it is a pleasure for me to welcome our keynote speaker for the end of the Digitale Leute Summit 2024. So Ryan Singer, please come on stage and a big applause for Ryan. And I have to say I'm a little bit of fanboy of your work, what you are doing. So since 2006, when I started my first startup, I worked with your product Basecamp. So Ryan was... 2006. 2006, yeah. So Ryan was I think employee number three at Basecamp, something like that, and you created that. And he's probably the prototype of a digitale loiter because he started in UI design and then did software development and then product management. And yeah, so I'm very looking forward to your talk. Thanks for being with us. Thank you. So the stage is yours. All right. Thanks a lot. Some people were asking me, what are you going to be talking about? And I said... I'm going to talk about why projects are moving too slowly and we're not able to ship. And there were a few nodding heads saying, oh, I heard things like that can happen in the world. So I hope it's relevant for you. I'm going to talk about some of the specific things that go wrong that can lead to feeling like we're moving slowly, that we are not making progress, that we're not shipping the things that we should be shipping. And I'm not going to give you a framework. I'm not going to give you a promise that you're going to go do shape up and everything's going to be great. Instead, I want to give you a specific tool that you can actually take and use on a real project that can help you. OK, so that's kind of the focus for today. When it comes to talking about shipping and moving faster and finishing things and making progress, I find it really useful to use this image of the time box. And this time box is... Okay, this is the time. Sometimes people call it delivery, but it's unclear what that really means. So, you know, there's a moment when we actually are supposed to be building something, right? Like that moment of like, okay, are we starting? Yes, right? And for a lot of teams here, maybe you're doing Scrum, and maybe it's not really, maybe you don't even have an official deadline of when a project is supposed to be finished. But there is some point, for sure, where people start to say, this is taking too long. Right. So either you maybe you have a real, maybe you have a fixed deadline, like six weeks in shape up. Maybe you really have after three weeks, this thing is supposed to be finished. Or maybe you don't have a clear deadline, but a moment comes where it's like. we're taking too long okay but i want you to be thinking about that building time okay your experience of that building time and what do we see happening in there you know it's not just like of course that we start the project and then oh everything wonderful no we're seeing a lot of problems happening inside of this time we're not just seeing that we're building everything we imagined in the way that we imagined right and what are we seeing we're seeing unexpected complexity right a bunch of scope appearing we didn't anticipate we're seeing that things are taking much longer than we thought and we're seeing also that uh that um uh that the quality isn't matching what we intended right the stuff that's coming out isn't what we hoped for right and the viewpoint that i want to take here of course Also, some pressure starts to appear, right? It's not only that we see it, but we also start to hear some voices coming through the ceiling, right, of why isn't this finished? So the viewpoint that I want to take here, the way that I've learned to work with this, is to focus on what happened before that time box started. And we call that the shaping work. The shaping work is that work, this is just a name for that work that we do that we say, yes, that's the thing we're going to go build, okay? And the viewpoint I want to take here is, ah, yes, and what form does this take? Most of the time, for a lot of companies today, that shaping work, it looks like maybe Figma files, right? This is what we're going to go build. Or if it's not Figma files, maybe it's a kind of a requirements document that says this is the vision, and this is the strategy, and these are the requirements. So whatever that is, this is the most common that we see today. The viewpoint we're going to take here is that these problems that are appearing in the time box, that they were actually there from the beginning, that these are like time bombs that were hiding in that work that we did in those conversations we had. So I want to point out some of these cause and effect relationships so you can start to see those things, because you will anyway recognize them. right so let's start off with the case of working with a figma file okay so the designer spends hours and hours and days creating the complete beautiful masterpiece right and we look at that and of course everyone looks at it and says beautiful beautiful right very convincing looks really good and then we take it into build and what happens what starts to blow up well it turns out we can't actually build that the way that it was drawn right the engineers start to say no to us right or it turns out that there were requirements that we didn't quite understand or that came up unexpectedly that that it turns out now we have to throw away all that work that went into that figma file right or it can happen that uh there's edge cases that aren't clear what about this case what do we do when this happens that wasn't clear from from the figma file And why are these things happening? Well, we can understand there are causes for these things. If you look at a Figma file, what are the time bombs there? We see that there's a lot of visual detail, but there isn't actually anything telling us how this is going to get built. There's like all the surface is there, but the actual wiring, the flow of data, the logic, we can't see those things, right? The engineers can't see the technical implications of what this means in terms of what we're going to do. It's like looking at a beautiful rendering of a house, but we don't see anything about all of the plumbing and the electrical and the load-bearing and all the permitting and things that have to happen, right? And, of course, it's hard to actually play out the different use cases and flows. Because we're just seeing a lot of boxes in a Figma file, but we're going to come back to that later. So it's understandable how these things are happening. If we look at the case of a product requirements document, something which is like what a lot of product managers are creating, here is our perfect explanation of why this is the most intelligent thing to do now with all of our strategy. right and uh we look at this and of course people say yeah it's going to be the feature is going to be powerful and it's going to be fast and it's going to be easy and these are all the business reasons why we're doing it now and this is all the customer stories that prove that it's real right and then what happens when the time box actually starts nobody knows what to do right we it's a great idea but what do we actually build right we don't know what we don't know what to build where do i put the button What happens when I click the button? And then if we look closer at that, then we see that this leads to a lot of discussions. Now we have to talk. Well, what does it really mean? What are we really going to do? Can we do this? Can we do that? So the project isn't moving. There's a lot of unproductive feeling discussions that are happening. And of course, then the scope is just getting bigger and bigger because, well, if we didn't have a clear picture in the first place, it's only going to get more complicated. And again, if we look at a product requirements document, if we look at the kind of product briefs that we're often making, we see the reasons for these things again, right? We see that the product brief describes high-level outcomes. You know, we talk a lot about how important it is to align on a goal, right? And it's true, but it's not enough to go build a thing. If we're going to build something, we need to know how it's going to work and how it connects and what actually we're going to go implement. And because we don't see the how, we can't actually evaluate the costs. We have no idea how much time it's really going to take, what kind of technical work is really going to be required because it's so fuzzy. The reason it's so easy also for the scope to expand is because if you're working on a document, then you can always add bullet points and say, and it's going to do this, and it's going to do that, and it's going to end, end, end, end. And the bullet points, they don't add any more time to the project. But there are actually a lot of realities hiding inside of that. So we get this impression that we can have it all when it's not really true. So what might we do differently? I mean, I would think that when you start to see these things, one would think, you know, like, hmm, hmm, you know, seems to be real. Maybe we should look for some other ways, right? So I want to give you at least something and not only destroy your peace of mind. So what would it look like to shape projects better so that they go well? What different work could we do at that stage? And in ShapeUp, we talk about doing shaping sessions. And shaping sessions are collaborative work sessions where we figure this out, where we answer this question. And there's kind of three things that we are looking for in this stage of the work for it to go well. And I'm going to show you a very concrete example here. The first thing is something that you've all heard probably all day today, which is that we should be collaborative. We should have a trio or something like that and product and engineering and design. And of course, it's true because engineering knows things that the designer doesn't know. And if they're collaborating, then we would like the idea to blow up sooner and have engineering say, no, that's not possible immediately instead of weeks later. But the thing is, saying that these people should collaborate, what does it mean? We should just put them in a room and say, Have lunch together. Talk together. What do we actually do? So we need more than that. Our shaping sessions need to be also concrete. Concrete means real stuff, work, not just the high-level goal, kind of like what David was just talking about. Not just the high-level goal, not just talking, but a specific idea. What if we connected this to that to this to that? Would it work or not? requirements document. So we have a concrete idea that we're looking at and not something fuzzy and high level. But at the same time, the work that we do in a shaping session needs to be lightweight. Lightweight meaning a Figma file is concrete. But if we talk about changing something, then the designer has to disappear for a day. Right they have to go away and work for four hours and then come back and look at the change So we need a way to make changes to look at an idea and try things out on the spot live together So this topic of how to run a shaping session is a very very broad topic There are a lot of tools and a lot of techniques that you can apply there But I'm going to give you one in particular and the reason this one is a good one to share here is because you don't need Anything to do it you don't need to be using any special process you don't need any special background knowledge like you can use what I show you today and And you can go try it. Okay, so this technique is called breadboarding and in order to show it to you. I'm going to show you a Play-by-play of a case study. We're just going to look at a real case study and then you can see what this kind of work looks like so I have some friends and They are a fintech in the US And what they do is they help small businesses to get paid faster. So they have these very nice tools that integrate with banks so that payments to small businesses show up directly in the bank really fast, which is what very small businesses want. And their main product until recently has been this web-based payment form. So the small business can just send a link to their customer. The customer can type in any amount, put in their credit card information, and make a payment like that. OK, so that's been the main product for a while, and it's been working very, very well. And now they're working on something new. So they're adding the support for this Tap to Pay feature that Apple now offers, right? So they have this new Tap to Pay app, and here's where the problem comes in. The way that Tap to Pay works is sometimes It just doesn't work. So sometimes you hold the card and nothing happens, or it turns out it's an old card and it's not contactless, whatever. Sometimes it fails. So when the Tap2Pay fails, the app falls back on the manual web payment form. Now, this web payment form is old. It's older than the Tap2Pay, and it doesn't have all of the features that the Tap2Pay app has. They put some new features here. slightly American examples. So just imagine that they make sense. It's a tipping and sales tax. So there's an option to add sales tax to the purchase. And there's also the option where you can hand the phone to the person who's paying, and they can choose a tip and then give it back. So these new features are there in the Tap to Pay app. And what happens is, in the case where the Tap to Pay doesn't work, when someone has added sales tax or chosen a tip, then actually all that data gets lost because the web payment form is old and it doesn't have those new features. So this is bad. So what they want to do is they want to build a native version of this manual form for typing in the credit card details when the tap-to-pay fails in such a way that it won't lose this data. So that's what they're trying to do. This is kind of the... the strategy piece. This is what we want to solve. This is what we are willing to invest time in now. This is the next important thing. We're going to bring a team together. Let's go work on this thing. So to do that, they have a shaping session. And in the shaping session, you have this familiar picture of the so-called trio. Of course, I want to point out that the reason that we have these three people here is to highlight the fact that we need the different sources of knowledge. In a perfect universe, we often hear at product management conferences that everyone should be involved. The engineers should be involved in user research, and the designers should also be doing the user research. And we, product managers who actually don't have time, are supposed to be doing more research. And the thing is that in reality, there's a certain amount of imbalance that's going to be there. There's going to be someone who knows a lot more about the customer and the business problem, and usually the engineers are going to be much less interested in sitting with the customer, honestly. So what we want to be able to do is not just require that everyone was there, but to really enable people to complete each other. you know and to and to give the missing information and to work together and be really good at the things that they know and that they are good at and then to be a team and solve the different things that we don't all know okay so it's about bringing those perspectives together because we have different knowledge because we bring different expertise into the situation and here you might have uh cases where some of these are actually one person right so if you have a designer who's also an engineer right or you have a product person who's also a designer right so you can also think of these as hats right as we often talk about them so anyway these perspectives are present here and we're having the shaping session and what do they do so they open up a white boarding tool like miro you know or your your favorite for just a tool where you can do sticky notes and arrows okay And the way that breadboarding works is we use these conventions of places, affordances, and flows. And what we're doing here is we're going to describe the system of how this thing works using these conventions. And we're going to do it from the user's perspective. So this is actually also experience design. But you're going to see that. So a place is somewhere that we can be. in the app. And so we're going to start here by just sketching out the current way that the system works so we can see the problems. And then we're going to look at fixes. So in the current version, when you open the iPhone app with tap to pay, you start on the home screen. So this is the place, the pink sticky, application home. Then under a place, we can show the affordances. And this is a user interface term. Some of you might know it. It means the things that we can act with, the things that we can use that appear there to do stuff. So what can we do on the home screen? Well, there's an amount field to type in the amount that we want to charge. There's the option to apply sales tax, as we saw. And then there's a next action. OK, we're just describing how the system works today. So these are the affordances on the home screen. This is this convention. Now, the third thing is we have flows. And a flow is just a connection line that shows how we use an affordance on the screen that takes us to a different place. OK, this is like fundamentals of interaction design. So I'm going to hit Next. And this takes me to the tip screen, right? So from the tip screen, I have options for different amounts of tips or no tip, right? And I can hand that to the customer, take it back. And they're going to choose one of these options. And this goes to the screen for previewing the charge. What do we see when we're previewing the charge? We see a kind of a breakdown of the amount, the original amount plus the sales tax plus the tip and the new total, right? And then we have the option to actually do the tap to pay. OK, so now let's zoom out a little bit so we can continue here. When they hit tap to pay, what happens? It takes them to Apple's built-in tap to pay flow. And here, the built-in tap to pay flow, it's not something that we can influence because it's just controlled by Apple. So we're not going to spell out what's happening there. We're just going to show what happens from moving on from there. If the tap to pay works, then we have a success condition, which we're just going to mark on the connection line for the flow. And the success condition takes us to a payment successful screen. By the way, notice, these are not like goals or desires or intentions. We're describing how the system works. These are all things that you can point at if you can see. So there is a payment success screen. And this has the option to send an email receipt. And it also has the option to send an SMS receipt. If it fails, then we see the failure screen. And we have an option to try again. And then under try again, if just the tap to pay just isn't working, this is where the manual payment option appears today. OK? So the manual payment link is what's loading a web view. And the web view is where this old web-based payment form as the fallback is loading. And what do we see on the web view? We see the amount field set to zero, not knowing anything about what happened before. We see the credit card fields to manually type in the credit card information. We have an email receipt option built into the web view. Maybe you notice it's duplicating the native option, right? And then we have terms and conditions and the option to pay. And if we hit pay and it works, then we have the manual state for the web state for the manual success. And if it fails, then we go back to the manual web screen, and there's going to be some errors there that we're not showing right now, OK? So this is the current state of the system. We've drawn it together. The three in the shaping session have drawn it together. And now we can see where's the problem. So the amount is not showing the tax and tips that were calculated when we fall back on the manual case. And we have an email address, email receipt option, but we don't have an SMS option. So we're missing a receipt feature here on the manual flow. So now we are up to speed. So we say, OK, let's do the new version of this. So now we can, in Miro, just select everything, copy and paste. And let's work on alternate design A. So in alternate version A, we're going to get rid of this manual web flow. And we're going to replace it with this new native option. So we're going to say, under try again, on the failure state of tap to pay, there's the manual payment button. That takes us to the new native screen for manually entering the card details. Here, instead of the amount set to zero, we see the same breakdown as on the preview state. So we have the breakdown of the charge amount, we have the credit card fields, we have terms and conditions, and we have a pay action. Now, if the pay succeeds, because we are in the native app, we can actually scoot over this payment successful, and we can reuse that. Right? So we're going to, if pay works, then we will go to the payment success screen that we already have. And if pay doesn't work, then we were going to fail and come back to the manual entry screen as we did before. OK? So we can say, did we get somewhere? Is this working? And we say, yes. Yes. Right? The problems are solved. We seem to be fine. Yeah? And this is, um. This is the moment where, you know, maybe everybody, we got to the first version, and everybody says, very good, good day, let's go have our kolsch or whatever, you know? But I want to point something out here. Notice that this is very different from this. You should feel how different that is, right? Here, we have the whole thing in our heads. We can see all of the moving parts. We can play through the use cases. We can reason about what happens when this happens, what happens when that happens. Do we have this or do we not have that? Where are the holes? But when we are here, we just see boxes. And then if we zoom in, we see a lot of detail about only one thing. And we don't even know what we're looking at anymore. When we are looking at this together, and we're in the room, and we've been talking about the use cases. and we've been asking ourselves, does it work? What happens here? What happens there? Because we all have it in our heads, this is where things can spark, where we can suddenly think of something or remember something, because we're looking at something that is so concrete and real. And here is where, in this case, the product manager goes, you know what? Now that I'm looking at this, I just remembered. There was another reason we wanted to do the manual payment form. I don't know if you've ever had something like that happen. But usually it happens on the third week or the sixth week or the 18th week. It doesn't happen on day zero. So right here in the session, the product manager goes, oh, yeah. There was another thing, too. Our data has been showing us that we actually have many customers who are navigating through our web app to get to this manual payment form because they need to take credit card money over the phone. Again, it's maybe US specific, but it's happening. So they need to take credit card details over the phone. And for these people, this doesn't help them. You know, they should be able to choose to enter credit card data manually and not only have it as a fallback when the tap to pay fails. Right? They wanted to give like a first class way to choose to do a manual payment. So we say, aha. So we have a problem here, actually. There's no manual way. There's no option to choose the manual flow. Right? It's only there when tap to pay fails. So now again, we can copy and paste. The group can start talking about, well, what would a version B look like to do that? Well, that seems actually pretty straightforward. Maybe under tap to pay here on the preview step, we could put a manual payment option. Yeah? So you could kind of set up the payment, and then you have a fork in the logic, and you either do tap to pay or you do the manual payment. If you choose manual, it also goes to the same manual flow. And we kind of play it out, and we're like, OK, it seems to work. It seems to work. Yeah, easy, right? So are we done? And the product manager, who is playing the role of the person who did all the research, right? Maybe nobody else was involved in any research, but the one person in the room was and here the product manager says you know we've talked to customers who are doing these these um payments by phone and they very rarely they they very rarely need to take tips the tip feature is really for when you are in person and you hand it over to the other person and then they they touch it and give it back to you but over the phone they usually don't need tips so if you have to go through the tip screen to get to the manual payment, that's a bad experience. You know, the tip isn't relevant for most cases. And on top of that, we have so many customers and so many kind of unexpected use cases where this manual payment would be good for them. We were hoping that it's something that we could clearly market on the screenshots in the App Store, right? That this app is not only tap to pay, but now it's a really quick way to quickly grab. make a credit card payment with the details so is there some way that this manual payment thing could be more up front so we say okay let's see maybe what can we do about that so now we already start an alternate version c i think we say okay get rid of the manual payment thing it's not under the under the preview step but we'll move it to the front right we move it to the front and then instead of next now we'll have a tap to pay action So you can configure the payment, and you can either tap to pay, and that sends you down to tip and preview and so on. Or you do the manual flow, and you skip the whole tip thing, and you're going directly to natively entering the credit card details. So fantastic. Did we do it? Again, feels like, are we ready to go now? Can I start? The engineer's like, can I start building now, please? But then we look at it, and the product manager says, well, actually, usually they don't want tips. But sometimes they do. So we have an issue. We still need to optionally take tips over here. But because we are live in the session, this isn't like everybody isn't like, oh my god, we're changing things. It's like, no problem. No problem. So how about in the native screen, so we could actually add a modified tip action underneath the amount breakdown. We don't have to change the rest of the flow. If you come in from manual and the tip is set to zero by default, then you have zero tip, but you can modify it. The modify action takes you to a modify tip screen, has the same affordances as what we already have on the native app, not complicated. And then when you modify the tip, it takes you back to the native screen, but it updates the amount breakdown so you can see that the tip was added. And then we can play this through and we can say, uh-huh, and does it still work for the fallback case? Yes, it still works in the fallback case. And then we come to a point where we say, I think we got it. Right? So this is what I wanted. This is what it looks like to be doing this very concrete work. together live and we're not just talking but we're really problem-solving together and we're using the knowledge that everybody has so what did we see here in the life shaping session using just using this particular technique we saw the collaboration right it wasn't just a slogan that we're supposed to collaborate we saw what it actually looked like it meant that different information was present and so it was possible for all this information to come up. And it all happened right there, right? So we didn't go down a long path of doing a lot of Figma or building a prototype and then finding out that something was missing, right? It all happened immediately. It was concrete. And because it was concrete, that's why the product manager could look at it and say, oh, what about this? Oh, now I remember that. To make this example short, I just talked about cases from the perspective of the product manager. This very often happens from the engineering side. Like, oh, Did you know that this has to go through a validation step and that this has to call a third-party API? And that API has legal things that we have to clear before we can use it. And this step actually has really difficult conditions in terms of load and performance. And this thing is legacy, and we can't touch that. All of those things also get surfaced here because we're looking at the real system. So that's what the concreteness gives us. It gives us it surfaces the real issues. It enables us to have the conversation of, is this actually going to work or not, and to be more real about what we're getting into. But not only that, of course, the third thing was that it was lightweight. So this meant that it felt good to make changes. When we found out that we were wrong or that we missed something or it wasn't going to work, instead of being a problem, it was like, ah, yeah, that's even better. Now we're getting warmer, right? When these ticking time bombs have been sitting there for a long time and they blow up late in the process, that's really painful. But when we tickle them to make them blow up on day zero, then it feels like a victory. It feels like, oh, amazing. We uncovered all the important stuff, or maybe not all of it, but a lot of it. And we were able to solve it, and we kept the energy high, and we kept moving. That's what the lightweight gives us. So this is something that you can take if you have screenshots, you know, or photos, you know, of this convention of how to do this. You can bring people into a room anytime you feel like, I'm not sure that we're actually talking about the same thing. I'm not sure we're actually clear about what we're doing. Let's draw this out. And it's a way to get into that concreteness, to collaborate together, but in a way that's still lightweight. So I hope that that's something that you can use. I want to briefly mention, if we try that, if we work like that, and if we use these kinds of techniques, what do we see that's different then in the time box when we go to start building? So what we will see is, first of all, everyone's way more clear about what we're actually doing. Secondly, the engineers are unblocked. Because they can already see the wiring that needs to happen, the data flow that needs to happen, the architectural decisions that have to happen to enable what we drew. And the designers are actually on solid ground to do that high fidelity work. If you carefully figure out the perfect kitchen tile and you put all the kitchen tiles in, but then you have to move the sink. That doesn't work, right? But if the sink is in the right place and the plumbing is done and all the rough work is agreed upon and then we put the perfect tile on, that's a good feeling, right? So the sequence matters. And being able to do that beautiful high fidelity work, which is valuable and is important, when we do it on the solid ground of this isn't going to all blow up and change, that works much better. And finally, we have this sense that the work is actually adding up. that we are coming closer, that what I did and what you did and what they did, that it's all adding to this is fitting into one picture and it's not like, oh, what about that? Oh, what about that? And moving backwards, right? But instead it's adding up and we're moving forwards. So that's what I wanted to share with you. I hope that you have some, also some questions starting to formulate, you know, like what about this and what about that? And who do I involve and how do I make the time? And do you know what I mean? So Please, I encourage those questions. These are some resources that you can use to dig deeper into all of this. There's a short video that gives you an overview of ShapeUp if you don't know anything about it. There's, of course, the book, and I mentioned the chapter on breadboarding, so you can see that. And we have the Shaping in Real Life course, which is where we teach kind of how to do this in companies that are very different than Basecamp. The book was written about a very specific company with some very special conditions, you know. And in the course, we teach techniques like this that you can use no matter how your company is organized. So all of that is on the website. I would also love to have a... Hello from you on LinkedIn or email or whatever and just hear your reactions or your thoughts or your questions You know for me This is a great chance to find out what is happening in everyone's world and what what if this connects and what if it doesn't and what kind of questions you have so please reach out And we have still four and a half minutes I I hoped for a little bit more but we have four and a half minutes So hopefully we can take some questions now too. Yeah, of course. Thank you very much Ryan. Yes, big applause for Ryan. Thank you And yes, we have some time left, so if you have questions, please come here to the microphone and ask them. Also objections, complaints. Jonas, you want to ask? There is the mic. So thanks, Ryan, for the talk. That was really great. Thanks. It's kind of interesting because you show a very old methodology, you know, screen flow diagrams or something simple, which is known in computer science, but I really like the way you pointed out that... It's the collaborative aspect of it and the light-weight-ness. And the fact that it's from the user perspective is a key thing. That's what enables us to collaborate. Usually these flowcharts are done from an infrastructure perspective and then all the non-engineers don't know how to participate. So how do UX designers take it? Because they have to learn something new. They don't know this methodology. I feel, maybe I'm wrong, as a computer guy, this is kind of familiar and I like it, but how do UX people usually take it? I've never had difficulty with a designer not understanding this. I mean, if they don't understand this immediately, they're in the wrong business. For sure. It doesn't mean that they have to be comfortable with it or they should know it already. But when they see it, I mean, what we're talking about here is just where do you move? Where is the button? What shows up on the screen? And then where do you go next? You know, this is the substance of interaction design. This is it. Places, affordances and flows. That's what interaction design is. The rest is tiles, you know, the kitchen tile. And the beauty is important and we need that, but it's not the architecture, it's not the walls, it's not the electricity, it's not the heating and cooling and everything like that. Yeah, we see very good results. And the other thing is that designers hate having all of their work blown up, spending hours making something perfect, and then everyone's saying, never mind, we're doing something different, right? And here they can have that solid ground and they can iterate from there. So it's... It's a win actually it's a big win What would you recommend if you want to try this shape up methodology in the team? So what would be the first start just do such a session? Or how would you recommend if you want to have a light white start and just to try it out? How would you do it? So what I would be doing is I would be looking to see if I recognize these problems You know that the work that we are doing isn't moving forward and just adding and becoming better and better and better, but it's changing and then becoming a problem for us. I would be looking for those problems and I would be talking to people around me to say, do you also see this problem? Do you think that we should continue like that? And then what I would do is I wouldn't jump into any methodology. I would look for individual tools that I can use like this one that I know where to put them in and try them. and start to get some better results. And then if you come to a point where maybe you think you have to make some structural change, maybe, but the idea of changing process or something should be the last idea. So it's just a light white start into this methodology. There's no process that works for everybody. I don't even like thinking of it as a methodology. I think of it as a toolbox. Okay. Ryan, thank you very much. for coming over to Cologne. I'm sorry we didn't manage with very much time for questions but I'll be hanging around and I think that they're even inviting us to stay and enjoy. Sorry, sorry, just a second. I didn't saw you. Please go ahead. We have a minute. My question is have you ever felt the need to add another level of abstraction in order to deal with the size, the amount of affordances or places to be because otherwise it would just be... too much we have tricks for that so if you have a screen that has a million things all on one screen there are some tricks for that i have a video even i could send you with some examples of that yeah thanks a lot yeah cheers thank you so ryan thank you very much for the keynote great to have you with us so a big applause for ryan singer thank you all thanks and feel welcome to ask questions or catch me over there if you'd like to talk a bit

Closing Keynote by Ryan Singer, Founder of Felt Presence. Former Head of Strategy at Basecamp and Author of Shape Up.

Product teams are struggling to ship. Everyone is getting tired of sprints, backlogs, and agile rituals. Big projects aren’t getting across the finish line, and the pressure to deliver is only increasing. What can we do differently? How do we get to a moment of victory where we ship something we are proud of?

In this keynote, Ryan will share some techniques from the Shape Up method that you can apply within your current team and existing process. You will get new clarity about what is holding your projects back and concrete ideas for what to do about it.
_ _ _ _ _ _ _ _ 
Join us at Digitale Leute Summit 2025 in Cologne.
https://www.digitale-leute.de/summit/25/

Follow us on LinkedIn: https://www.linkedin.com/company/digi...
Follow us on Instagram: https://www.instagram.com/digitaleleute