Y - Oslo START SHIPPING WITH SHAPE UP, Ryan Singer

He asked me to tell him a fun fact and I already regret it, you know. But really happy to be here. It's fantastic to be part of the conference here and good morning. I'm going to be talking about, well, you know, in theory the topic should be shape up. But actually I don't want to talk to you about some process that anyway maybe you can't change your process from where you're working right now. I want to talk about something that a lot of us experience which is difficulties with shipping. Yeah, it is not always so easy as you have probably noticed to actually finish things, to feel good as projects are running, to feel like we're getting closer and that everything is clicking together. There may be some difficulties there. And I want to talk about kind of what are some symptoms and what are the causes of those different problems when we're having difficulties with shipping. Then I want to give you a technique that you can use, something that everybody here could take home or take back to the team and actually use to start to make some progress and start shipping better. So when we talk about shipping, it helps to think in terms of what I call the time box. This time box is when building is supposed to start. There's some moment where the builders, the coders, the engineers are actually supposed to be making something. So we can think of that as the beginning of the time box. And some of you are in situations where there really are actually clear deadlines. A lot of us are in situations where, well, the project just keeps kind of going and going and going. But then one day people start saying. It's too late. It's too long. We have to do something else. We have to finish. Right. So however that is, there is some kind of a moment where we could say this needs to be over. We need to be doing something else. There's some kind of a deadline. That's our time box that we're talking about. And if we look at what happens inside of that time when we should be building, we see usually a lot of difficulties. A lot of problems are emerging. What do we see? We see. unexpected complexity, right? Things that turn out to be more complicated than we thought originally. We see the project dragging on and on much longer than we thought. And of course, we see that also the quality that's coming out doesn't match the intent we had going in. It doesn't match the expectations for what we thought it was going to be or what we hoped it was going to be. Right. And of course, we start to notice these things. maybe even early on in the project and they start to get worse and worse. And eventually we start to hear some voices from the ceiling or the nearby rooms were saying, why aren't we done yet? And we need to be going on to the next thing. So there's even more pressure coming on top of it all. Yeah. The way that I've learned to understand this and work with it and start improving it is to focus on the phase of work that came before the time box started. So before we were actually supposed to start building. There was some kind of work that happened that we could call shaping, which is that work that we did that we said yes to where we said, yes, this is the thing we want to go build. This is the thing that we're willing to invest time and resources into. This is the thing that we're actually going to spend the engineering time to go do. Okay. And for probably a lot of us here for a lot of companies today, that shaping work looks like something like like a PRD, like a requirements document and probably a figma file. Yeah. So there's kind of this requirements document and the figma are some combination of these. And the attitude that I want to take in order to start identifying problems and finding solutions here is to actually say that the things that are blowing up that are going wrong inside the time box when we're building, they actually have their causes earlier in the process. So they actually have their causes in the beginning of the process. They were like ticking time bombs there in the requirements document and in the Figma file that led to those things happening. So I want to dig into taking a closer look at those. And let's start with the example of when we are starting off this building work by defining it with a Figma file. So we have some designers here, right? You're familiar with this tool and you know that when you work on a figma file, it's detailed work that you put your heart and soul into, right? Every little detail is right. It's not the rough sketch. It's the precision work. So a lot of hours go into making that figma file, right? And of course, when we show that to people and say, this is our, this is our design, the people say it looks beautiful. Fantastic. Of course we should do it, right? Because it looks so nice. But then when we get into that time box and we start building. different kind of difficulties appear. And what difficulties do we see in this case? Very often we see the engineer saying, actually, we can't build it the way that it was drawn. Right? Yeah, it looks great, but we can't actually do it like that. Yeah. You know, or actually, now that we're working on it, we understood the requirements are different than we thought, or what we want it to really do should be more like this, right? Or questions start to come up about use cases and edge cases and different kinds of flows that weren't clearly shown in the figma file. So again, we are in a situation where we did all this work, but somehow the building isn't able to just move forward based on that. Right. And in all these cases, what does it mean? It means a lot of rework. It means that. throwing away work or not using the work that we put hours and hours and a lot of heart and care. All that art that we made isn't actually getting turned into something that's being built. So and I don't know how it is in Norway, but in a lot of companies that I work with, the designers are far outnumbered by engineers. You know, there's at least ten times as many engineers as designers. So if something needs to change, there's not a lot of time. right? It's like there's never enough time to go back and do the figma over or to get things as right as we would like to later on in the process. So why are these things happening? Well, if we take a look at the figma file, it's quite understandable. You know, the figma has a lot of detail, a lot of beautiful detail, but it's not the kind of detail that the builders need in order to know what to do. Also, we see that when the engineers look at the figma file, of course, they see the surface and all the beautiful design that's there but they cannot see the wiring and all the logic and implementation detail that is implied by what's on the surface right it's like you would need an x-ray machine to look underneath and understand what all of this actually means in terms of the code implementation And when it comes to playing through different use cases and scenarios, it's not easy when you're looking at a Figma file to kind of see, does it cover all of those things? Does it do what it needs to do? What about when this data isn't there? Or what about in this case or this specific customer segment? So it's understandable that these blowups are happening later when a lot of these kind of limitations are built into the medium, right? In the beginning. Now, let's take a look at the PRD at the requirements document. So let's say that we have a document that spells out the business case and all the different outcomes that the customer is going to have. And we start with that as our as our shaping work. Again, we can look at that and say, yeah, sounds great. You know, it's going to be powerful. It's going to be fast. It's going to be easy. There's all these great reasons for why we should do it now. Here's all the proof that the customer wants it. Right. All the things we see in those documents. But again, things happen, right? So things start to blow up. And what do we see in this case? The first thing we see is that when we start work based off of a requirements document, and in theory, we should start building something, instead, there's a lot of head scratching. We don't know how to start building because we don't actually know what to do, right? We have a lot of business requirements, but what do we actually make? Right? So then, of course, instead of building, we're having a lot of long discussions and debates and questions. And what does it mean? And what should we do? And maybe we have to ask again and this kind of a thing. And while we're having all these discussions and debates and meetings, instead of building something, the scope is getting bigger and bigger and bigger and bigger. Right? Because it's very difficult to narrow down and make trade offs when we're in that situation. Then if we try to look for why is this happening? What are the causes? We can look back at that requirements document and we can see it only described the high level outcomes. Now that's valuable, right? There is a step in our work where we need to be able to say this is what we want to go do. This is what we want to invest in next. But it's not enough for building because it doesn't say how we're going to reach those outcomes. Right. And we can't see the cost of what this really means in terms of scope because there's no specific solution proposed. Just the outcomes that the solution should create. And in a requirements document, it's easy to just add another bullet point. You can say, and it will do this, and it will do that, and it will have this, right? And the bullet points, they don't cost anything, right? But when it comes time to make a design and code and the system that actually does all of that as one thing, then we have to make trade-offs and integrate. And it's not possible to actually have it all in the constraints that we have. So what would a different way? Look like what would a different kind of shaping look like if we could do it better the way that we approach shaping in Shape up and in that kind of style of working is we talk about having live shaping sessions and Inside of a shaping session. There's a few things that are very important that make that session successful So the first thing is the shaping sessions collaborative and what that means is that actually all the knowledge we need from different perspectives is there on the spot in the room at the same time if we're doing some design and then we have to give that design forward to an engineer then we do all the work and then only after we find out that oh that's actually not possible right and then we're moving backwards but if we're there on the spot in the same moment we can reveal those things The sessions are concrete and what this means is we avoid the faults of the PRD of the requirements document where we are actually looking at specific solution ideas together and because of that we can see the issues we can see where it fails where it blows up where it doesn't work But at the same time unlike the figma file our work in a shaping session is lightweight It means that we can throw things away that we can quickly scratch it out and try a new idea It doesn't work to bring people together, talk about what we should do, and then say, okay, I'm going to go away for four hours and make a Figma file, and then we'll talk again, right? We need something more lightweight that we can use. Now, when it comes to techniques that you can use in a shaping session, there are many. There's actually a lot we can do. There's many ways that we can work inside of a shaping session. But I want to give you one technique today that you can use. This one technique in particular is useful for today because you don't need to change anything about your process. You don't need to be in some kind of a shape-up process to use it. You can plug it into whatever you already do. And the other thing about this technique is you don't have to know anything else. You can just know what I show you now, and it's literally enough to go run one of these little sessions with a team and clarify a lot of the things that are going on in the project. This technique is called breadboarding. And in order to walk through it, I want to give you a case study. OK, and then we'll just go through a demonstration of what this looks like using the case study. So in this case study, we have a FinTech in the US and they help small businesses to get paid faster. OK, and their main feature of their product is a web payment form. where small businesses can send a link to this payment form to their customer, and then the customer can just pay any amount that they specify and type in their credit card details, and then the money goes directly into the small businesses bank account. Okay, so that's what they do, and this payment form has been working really great for them. That's the main thing they've been doing for a while, but now they have something new they're working on. They're building out a native iPhone app that is using the new tap-to-pay functionality on the phone. And this new Tap to Pay app is for paying in person, right? So here's the problem. When the Tap to Pay fails on the new app, there are different cases. You know, sometimes you hold the card in the wrong way or the card isn't contactless or whatever. There can be reasons why it doesn't work. They fall back on the original web payment form. That's how the app works. And this web payment form, it's older than the new app. So it doesn't have all the new features that the new app has. Okay. So in the new tap to pay app, there are things like the option to apply sales tax or you can hand the phone to the person who's paying and have them provide a tip. I know these are US specific features, but you can just imagine that they make sense, you know? So they the customer can can choose the tip and then hand the phone back. And the problem is if the payment fails. And now the old web payment form shows all of that tax and tip data is lost. It just shows a amount field with zero because it doesn't know about those new features, right? So this isn't okay. This is a problem. They also know there's going to be a lot more features coming in the native app and they want to be able to support them well. So the idea is they want to stop using the old web based payment form for the case where they need to manually enter the card. Instead of that, they're going to have a native screen for manually entering the card details. This is what they want to do. Sounds straightforward enough. How do they actually start figuring out what they're going to build and what they're going to do? They have a shaping session. In the shaping session, three perspectives are present. The product manager is there, the engineer is there, and the designer is there. Now, these, as you probably are familiar with, these are hats. and not people. They're perspectives that need to be present. Sometimes you might have two of them in the same person, right? But what's important is that these different perspectives and the knowledge from these different areas, it's all right there in the room. And the tool they're using is a whiteboard. So there's a whiteboard like Miro, you know, where they can just put stickies. And what they're going to do here is they're going to start off by breadboarding the current version. so they can see where the things go wrong, where the problems happen, and then start to understand what they might change. Here's how breadboarding works. We have a lot of designers here. When you're designing, one of the special characteristics of a designer is you can empathize with the user and look from their perspective. Breadboarding is the same thing. We're going to be describing how the system works completely from the user perspective. To do that, we have these three conventions or this format of these three things, places, affordances, and flows. For example, in this case, we're going to start mapping out how the current version works, and we're going to make a pink sticky for a place. The place is somewhere that you can go in the interface as a user. We're starting here with the home screen of the Tap to Pay app. From the application home, Then on places there are affordances. Maybe some of you know it's a user interface term affordance. It means something you can act on, something that you can do basically. And we're going to put those underneath. So on the application home, what can we do there? Well, there's an amount field to type in the amount we want to pay. There is this new feature to optionally apply sales tax. And then there's a next action. And then we come, so now we have the places, the affordances, and the third thing is the flows. Flows are like connection lines, always from an affordance to a place. It's I can do something here that takes me somewhere else, right? So from the next button, I can get to the tip screen. I can choose 10, 15, 20% or no tip. And then choosing one of those options, that's going to take me to the preview charge screen. On the preview charge screen, I can see a breakdown of the amount. Here's the original amount plus the tax plus the tip and the new total. Under the amount breakdown then, I have the option to use the tap to pay to start this tap to pay process. Let me just make a little bit more space and zoom out here. When we hit the tap to pay button, this is going to start Apple's built-in tap to pay feature. And we're not going to spell that out because actually we can't control it. It's just a little thing that has to be the way Apple made it, right? And then the tap to pay flow, it can succeed or fail. If it works, we're going to see a payment successful screen. Actually, we already do. This is describing the current version. We see a payment successful screen with the option to send an email receipt or an SMS receipt. And if it fails, then we see a message that it failed and there's an option to try again. If we try again and it still isn't working, then we need to do this manual entry that we talked about. So that's where the affordance for doing a manual payment appears. And then when we want to do a manual payment, this is where this WebView loads. This is where the old web-based payment form loads in a WebView inside the native app. So from the manual Webflow, as we talked about before, what is there? Well, there's an amount field that knows nothing about what happened before, just zero. There are the manual entry credit card fields. There's the email address option that appears on the web form. And then there's terms and conditions and the button to pay. And if we pay, then we see a success state if it works. And if it fails, we go back to the beginning of the web flow with some error messages shown, something like that, right? So with this map, we can see, we can point directly to where the problems are today. At the amount field step, we're not showing the tax and tips that this data that was collected. And at the email address step on the Webflow, there's no SMS option, right? So what are we going to do? Now we can use the same technique. We can just kind of copy and paste this whole thing. And now we can start making changes together. So here's alternate version A. In alternate version A, we're going to get rid of, we're going to delete this manual Webflow. And instead, when you hit manual payment on the failure screen, we're going to show you the native manual screen. This is the new thing we're going to do, right? And what is the native manual screen have? It has the same amount breakdown that we showed on the preview charge before. Exact same. But underneath that, we have native credit card fields to manually enter that information. And then we have terms and conditions and the option to pay. Because this is native now, when it comes to the success state, we can reuse the native success state we already have from tap to pay. So we can just scoot that over. And now we can wire up that if we hit pay on native manual, it goes to the same payment success as before. And now we get the SMS receipt option that we already built. Fantastic. So here we can say we have some success. Is it working? Yes. Did we solve the problems that we talked about? We can play it through and say it seems to be working. I want you to notice something about this. This feels very different from this. You notice the difference? Here, I can see the whole flow. I have the whole story in my mind. I'm thinking about how the user moves. I can see all the different things that are possible. What's there, what's not there. Here, when I'm zoomed out on a Figma file, I just see boxes, and I don't know what I'm looking at. And when I zoom in, then I see a lot of detail, but only about one place. And here, we're looking at the whole thing, and we see all the parts and how they're connected. And when we have this in our heads and we're sitting together in a live session, things can spark up that wouldn't have come up otherwise. In this case, some people in the session might have felt like, perfect, we're done. But at this moment, the product manager actually said, oh, now that I look at this, I remember there was another reason we wanted to do the manual entry form. Have you ever had that moment, you know, three weeks into a project and it's like, oh, I forgot, by the way, it's all different than we thought, you know? And so here the product manager says, actually, there's another use case we forgot about that we were thinking of. There's a case we're seeing where people use the manual entry form, our web based form, to take payments over the phone. And we're seeing way more of these than we expected. It turns out a lot of people are going into the web app. They're clicking around and finding this web payment form, and then they're using it to take the credit card details over the phone. And what we would like to do is not only offer that as a fallback when Tap2Pay fails, we would like it to be there so that people could choose manual payment, right? Not only when it fails, but they could choose to do that because it would be much more convenient to open an app and choose the manual payment than to go through all the steps in the on the desktop version of the web version to get to this payment form. OK, so they're saying I think we have an issue that we don't offer the manual option further upstream here. So in the session they say, OK, what can we do about that? Well, we could we could just add an option here. Here's alternate version B right again. Copy and paste the whole thing. Version B under tap to pay on the previous state. We could have a manual payment button. And that could just take you to the native manual thing that we already designed. It seems like it would work, right? Are we done? When we see the circuit, when we see the flow of all the information moves, when we can see all the parts, we can start to play out use cases. So here the product manager says, you know, if when I put myself in the shoes of the customer who is calling to get the credit card information over the phone, In the majority of cases, they aren't collecting a tip. Usually they don't need a tip for that. And this tip step is happening always. And then the fork, the branch in the logic happens after the tip step. I think that's going to be annoying for these people who are doing the manual phone payments. And the other thing is we're really surprised by how many people are using this use case. And we would really like to kind of market to them. that this app is going to be convenient for them. So it would be nice if the option to do the manual payment was somehow more visible. It was somehow further upfront in the process. You know, it could be there in the screenshots on the app store and stuff like that. It would be clear that we have this functionality. So we think, OK, can we come up with a version C? And there is a way, right? The team comes up with this idea for version C that we're going to get rid of the manual payment option under the preview step. And instead, on the home screen, when you first load the app, we'll have the amount, the sales tax option, and then either tap to pay, which takes you to the path of doing a tip, or manual. And then manual is just to type in the credit card information yourself, jumping over to this native manual screen that we designed. So here we can say, looks good, seems to be working. We seem to have solved it. But then again, the product manager is playing it through and says, but you know, they sometimes do want a tip. Right? So, okay, but now what are we going to do here, right? Well, we say, aha. So how about we need to do something here again on the native manual page that we designed. So let's add an option to modify the tip. That'll take us to a place where we can modify the tip when we set the tip. It'll take us back to the native manual form. The amount breakdown will be updated with the new tip amount. Seems to work. Does it still work with the fallback case? Yes, it still works. Success. Okay? So this is an example of what it looks like to have that collaboration and to be making design decisions on the spot together using this format. So what did we see in this live shaping session? We saw those three things. We saw that it was collaborative, that all the perspectives were there, and that issues could come up, maybe that the designer didn't know about, that the product manager knew about, that needed to be addressed and would have otherwise blown up all the work we had done, right? We saw that it was concrete. because we were looking at specific flows and looking at how the system really works at that moment, we were able to spot issues and identify what we would need to do to make changes or what changes would look like. And then it was lightweight. We were able to make the changes immediately. And this is really important. Making the changes, you know, deleting things, moving things, it felt like progress. It didn't feel like we're throwing work away. It didn't feel like we're slowing down. It felt like, oh, like, yes, like the energy in the room is high and it's getting more interesting and we're getting closer and closer and it actually feels good to be making changes, right? That's a really different thing. So what happens? Oh, so this, by the way, this is the moment where I would say, if there's something that you want to go home and do, it's that. You can call a shaping session when the project is totally unclear. even better before the project starts, before the time box starts, and you can have a few hours together in a room, and I promise you that some things will get more clear by trying to do that. Even when we're new at doing it, it will clarify things. So what happens when we do that work and we put that into the time box? We're going to see some different results. We're going to see that everyone involved has much more clarity about what it is that they're supposed to be doing. We're going to see that the engineers are unblocked because they can already see the wiring and the piping that needs to happen for the information flows, even though all the detailed design work isn't there yet. The designers are on solid ground to really put their heart into that art and making that Figma file beautiful because they know that we've already checked a lot of the fundamentals together around whether this approach is going to work. And when everyone is working together in that time box, the feeling is that the work is continuously adding up to something. It's not that we're stopping and saying, oh, but what about this, right? And then the energy goes down and we're moving backwards. Instead, it's like, no, we do this and then we add this. And now this condition is working and the interface is looking better. And now I improved the style of it like better, better, better, better like that. So that's what I wanted to demonstrate to you. What are some possible next steps? This is like a little piece of a very big thing. I just wanted to give you something you could use. If you want to learn more about the kind of universe of ShapeUp, there's a video on YouTube, Shaping in a Nutshell, also on my website. That's a quick overview. More about breadboarding in chapter four of the book, which you can read for free online. And there's the Shaping in Real Life course where we teach how to do all this stuff to companies who are in very different, who are structured very differently from Basecamp, where a lot of this stuff originated. So the Shaping in Real Life course, we have the next cohort running in December. So all of that's on the website and I would also be very happy to hear from you. So please, you can write me, reach out with your questions, objections, what about this, what about that. And I also hope that we can meet together in the halls during the conference and I'd love to hear what you think. So thank you very much. Ryan Singer. Brilliant. Thank you, Ryan.