Ryan Singer: Ship what matters — the right products at the right time

It's wonderful to be here at HowToWeb. I've been hearing for, I think, since 2019, a good friend of mine came here and he's been saying, you have to go to HowToWeb, you have to go to HowToWeb, that people there are really building things, they're really doing things, and it's a great place. So I'm very, very happy to be here today. When we're talking with a room of builders and founders, I think this subject is very important to all of us, which is like, We don't want to sit in meetings. We don't want to just be talking about things We don't want to be waiting for things that are supposed to already be happening that are just dragging and dragging But we want to be moving forward and actually finishing something and shipping something and then doing the next thing that we think is really meaningful, right? So what I want to do in this talk is Talk about some things that you might be experiencing some things that may be happening in your team And then I want to give you some ideas about a different way of approaching things. And I also want to give you some kind of very specific things that you can take back to your team as an inspiration. So let me just jump in here. You might recognize some situations like this, for example. The product person or the business person or the founder is saying, why aren't we done yet? Yeah? And if you go to the answer from the technical people, from the engineers, well, it's kind of hard to explain. Maybe it got a little bit more complex than expected. Maybe in the beginning when we talked about the project, the technical people said, yeah, yeah, that'll be no problem. But then it turns out to be more complicated. So we see disconnects very often between the product side and the technical side. We also see big disconnects when it comes to trying to define the work that we're going to give to the technical people, and then how do they react to that? So, for example, you might have seen where the designer makes the beautiful Figma file, the masterpiece of art, and everything is there, every state is described, everything is beautiful, every color is there, right? And they think, it's done, I have solved it, it's beautiful, it's perfect. right but then when you give it to the technical people they say that's actually not possible the way that it's designed it doesn't fit with our technical libraries it doesn't match what's really going on with the code or with our systems right so all of this work has to be thrown away it has to be changed right it was a lot of time wasted and instead of moving forward now we're going backward again to figure out how we can actually make this happen sometimes we see the other extreme where instead of having everything very, very defined in a perfect pixel masterpiece, the product people make a kind of requirements document. Yeah. And this requirements document is saying it's going to be fast and it's going to be powerful and we're going to make a new dashboard and it's going to have everything that the customer wants and then sales are going to go up and it's going to be amazing. Right. And all of those things, they might be true. It might be a really good business idea. But if it doesn't actually say how we are going to do that, what is it that we're going to build, what does the solution actually look like, then when this work goes to the engineers, then they're saying, I get that you want it to be fast and powerful and it should be a great dashboard, but what do I actually build now, right? So then the cycle starts. Whatever system you're working in, it's time that the work actually starts, and then the developers, they have to actually problem solve to invent. Sometimes you hear discovery happening inside of a cycle, yeah? They have to figure out what does this actually mean? What do we actually do now that the clock is already ticking? Even in cases where there is a beautiful coherent concept, if we are able to take the time to really figure out what is the solution, what is the basic architecture, how does this solve the problem, is it technically feasible? Can we do it in the amount of time we have? Even if we come up with that very coherent solution, in most teams today, when it comes time to actually turn that into real work, it goes through something I like to call the paper shredder. Maybe you've heard of something called Scrum, yeah? It means that we took something which was a whole, which was meaningful, and we shredded it into separate tickets, right? In theory, we should be able to shred this work into little pieces of work, and if we give each person one piece, then the whole project is going to be finished. But of course, this isn't realistic, right? We cannot foresee all of the real work that's needed to happen. We are not like the genius IKEA designers who can make assembly instructions for all of the separate parts, you know? And when it comes time to actually do the work, When all of these tickets are assigned, especially for those of us who are more in the leadership role or in the product role, we end up with this situation where there's constantly questions being asked because nobody has the context. When there's an individual ticket, you have one little task that you're supposed to do, but you cannot see how it connects to the whole, how it all fits together into the bigger picture, right? So there's a lot of questions. It's not just moving forward the way that we thought. And then even when the work is moving forward, very often we look at the board of what's supposed to be showing us progress, and we see tickets are getting completed, but somehow these tickets, they don't actually add up to overall progress. They don't actually mean that we are closer to shipping. It's like more and more tickets are getting done, but the project still isn't over, right? Does anybody recognize what I'm talking about? Is this familiar? Good, okay, yes. So, this is the kind of thing that I've actually been really interested in solving for a very long time. I started at Basecamp in 2003, and it was a very luxurious, lucky situation when I was there for 17 years because we got to do a lot of trial and error. of trying different ways of working and different ways of going through this process of designing something and then turning it into real software and shipping it and then going through that loop again. And we also had a very small team, so we had to figure out how to do the things very effectively, very efficiently. And after doing that for 17 years, then I eventually formalized what I learned into this book ShapeUp. I don't know if anyone's familiar with the book or anyone is applying it. We have a few folks. Yes. And since then, I've been working to help more teams take advantage of the experiences that I've learned and these different things. So what I want to basically do here is I don't want to try to convince you that you should be doing ShapeUp. What I've actually learned over the last few years of helping a lot of teams is that there are some kind of major principles that you can take away and use in your current way of working to start to solve some of these problems, even if you don't fully adopt what is in the book. So I want to share with you three main ideas that could be helpful to you. The first one is this notion of the difference between an estimate and an appetite. So you've probably experienced what happens with estimates, right? The way an estimate works is we talk about something that we want to do, so we have a kind of design in mind or a technical solution in mind, and then we say to the technical people, how long will it take? And of course, it's always wrong. But it works like that. First, we start with the solution, and then we ask, how long will it take? The notion of an appetite is to flip that around completely and say, instead of asking, how long will it take to build this particular solution, we say, how much time strategically do we want to spend on this effort? As a business, as a team, how much time does it make sense to spend on this thing for what we're going to get out of it? So we have a fixed time. And then, now that we know that this is the amount of time, or you could also say budget, yeah, that we have, now let's actually come up with different design solutions. that fit inside of that amount of time. So the time becomes a design constraint instead of an effect or a consequence of the design that we decided upon, right? It's a completely different process. And my favorite example of this is the calendar. This was a project that we did at Basecamp. And I love this example because it really shows what it means to kind of How do you say work with this scope? Yeah, so you might have also heard when we say appetite You might have heard this phrase before fixed time variable scope it goes back to the extreme programming people like Kent Beck and so on and Fixed time variable scope means if we have a fixed amount of time that we're going to build something then we have to figure out what how can we vary the scope what are those different design decisions we could make so that it fits inside of the time box and with a calendar this is really easy to see because if we just say customers want a calendar and we need to build a calendar i mean there's no end to the scope we could build a calendar for years right There's the month view, there's the day view, there's the dragging of things, all of those interactions, the scheduling of meetings, the interaction with different cloud calendar providers. I mean, there's so many different aspects to that. And in this case, there was a clear demand from the customer base that we needed to include a calendar feature in the app. But we knew that it also was only a small slice of customers. And it wasn't the main feature of the app. And so we had a lot of other things that we wanted to do in the product. But we agreed that if we could build something that would satisfy the customers asking for a calendar in six weeks, if we could set six weeks as our appetite and build inside of that, then we would be very happy spending that amount of time. So the question then is out of all of the different things that a calendar could be how do we actually make some judgment calls, right? So we interviewed customers and we figured out what was actually important about this request for a calendar and we use that to make trade-offs. So we were able to say, these things are important about the calendar in our situation. And there are all of these other things that we don't need that we can exclude from the scope in order to build something that is going to be doable and is going to satisfy the customer inside of this fixed amount of time. And what we ended up with was this very simple concept. It's a little bit like an airline booking, where you have two month views side by side. then dots to indicate when there's an event present and you click on a dot and then it scrolls an agenda view underneath and this is something where when you look at this you can see aha month grid month grid agenda view dots scrolling you can start to kind of add up the scope in your head and you say aha that's something I can get my head around that's something that we could actually complete right and you'll also see it's not a figma file right and on the other hand it's not just some words that say calendar simple easy right it's a it's a specific architecture it's a specific concept so this is what we shaped and this is what it looked like when it was actually built you can see that there was all of that high fidelity came at the end not at the beginning so how do we actually get to that right how do we do that project after project what i found works really well is something called a shaping session And I want to contrast this against the ways that we often do design. So we talked before about when there isn't enough detail. So we could say that this is like undershaping the work. The work isn't defined enough. There isn't enough shape to say this is what we're going to do, right? Just the business case, but not actually the technical solution or the parts that need to come together to make the thing work. overshaping the figma file there is a lot of detail there but actually it's the wrong detail it's too much detail it's on the surface you know if we wanted to do let's say we wanted to do a home renovation okay and we were going to have a new living room with new couch and new paint on the walls and and it's going to be beautiful right and we had an interior designer who made a perfect 3d rendering of what the new room was going to look like, and chose all the new furniture and the new colors, and in particular chose this lamp. And it was the perfect lamp. And they spent days and days searching for all the different lamps and finding something that fit into the budget and also looked good and was available on schedule, right? And you look at the rendering and you say, beautiful, let's do it, yes. But what's missing here is something very, very important. Do we actually have electricity in that wall or not? Right? Can we actually put a lamp there? And if we don't, what does this mean in terms of the overall project cost and schedule? Because now it's not just a question of buying something from the shop and then installing it. We have to rip open the wall and add new wiring and change the electrical system. So this is something very, very different. And this is not something that we can see when we look at an artistic rendering. So the surface, a rendering of the surface, is not enough for us to go in and say, this is going to happen on time. And the other thing that surely doesn't work, even though it's quite popular today as well, is having a long asynchronous discussion on some document. because when we have the asynchronous discussion it's like 27 comments 32 comments 38 comments and everyone is adding their thoughts but no one is actually wrestling with each other to make the trade-offs and say no that's not going to work what can we do instead right it's just more and more and more discussion and then we say okay let's just go do it anyway so what we do instead of these two things it's not the figma file it's not the long discussion thread but it's a live work session and in the live work session we bring together three things that we need the person who is technical this is very important it's not just designers and product people in the beginning it's the technical people because what we're building is something technical we have to know what is possible in the time we want to spend in the actual code in the system right so the technical person is there then also the person who is able to think things through in terms of experience in terms of the user's movement from point a to point b and also someone who is aware that this fits into a bigger system of of a business strategy and we need to find something within this amount of time and this is the value that we get out of a business if we do it right yeah so bringing these different things together into the room and when they're inside of the room i want to highlight what it can look like to have a technical person involved in these discussions and not only the product people because this is where we get to look behind the wall and say is the electricity there or not so for example if we have the technical person in the room and the product person says we have an idea We're going to skip a step in our onboarding process because we found out that we can actually just get the data from a third-party person instead of asking the user. This was a financial, like a fintech company. And instead of asking the user to input more and more data about themselves, they could actually use an API to pull that data in. And from the product standpoint, it was easy. We're going to skip the step, and then conversion is going to go up because we're going to have less friction in the onboarding flow. And if they had just said, great, let's go do it, then the problems would appear much later. But here, when the technical person is right there in the room, they can say, you know what, let's have a look at that. I'm just going to open up the code right here and see if skipping a step is as simple as you think it is. And when they look at the real code right there in the room, they say, you know what, there's actually a lot of conditions here. there isn't one flow the way that we think of it depending on which customer segment they're in and which integration they're on and which partner we're using there's actually three different totally different branches of code here right so the scope of this change is actually three times what we thought it was originally and this is the kind of thing that we want to be able to find out in day zero instead of on the third week of the project or the fourth week of the project or so on right so Getting that technical information. The other thing that having a technical person present gives us is we not only get to avoid these, you know, like time bombs, which would have exploded later in terms of complexity and bad surprises. It also allows us to attach a cost to things, right? If we are working inside of a fixed time. and we want to come up with some work that is going to be doable inside of that time, we need to have a realistic understanding of the cost of each part of the solution earlier in the process. So you can think of it kind of like if we were, let's say you're buying a house. If we're buying a house, we understand very well we have a budget in mind, right? There is some sum of money that we can spend on the house and not more than that, right? Because we only have so much. And now, we might start our house buying process with a vision of what we really, you know, our dream, of what we really hope we can find. We say, oh, we want three bedrooms and two bathrooms, and there's going to be a terrace. And not only that, but the terrace, we're going to find a beautiful location, and the terrace is going to have an amazing view. Right? And of course, when we... get into the details of what does it really cost and what is available on the market, then we find out that this is too much, let's say, scope, right? The cost is too high for what we have to spend, so this isn't going to work. So what that means is, it doesn't mean that we just give up on buying the house. It also doesn't mean that we just spend more money, which is what we might do in a software project, just spend more and more time, right? But we make trade-offs, right? we say okay so what can we do with the budget we have and one option might be well we can have the same size we can have three beds two baths and the terrace but in a neighborhood where we don't have any view and we just look at the we look at the apartment building next door right so same same space different location we can do that inside of the budget or we could go down to two bed one bath But then with a smaller place, we could actually afford it in the location that has the view. So now we have to make trade-offs. We have to have a hard conversation with each other. Like, oh, what is this really about? So like with the calendar, is it really about the month? Is it really about like scheduling my meetings 15 minute by 15 minute? Or is it more about just what's happening on that day as a milestone for a project, right? Is it about coordinating schedules, or is it more about broadcasting a plan? Depending on what we're trying to do, we can make those different trade-offs, and that's how we get to that smaller scope. When we do this in software, we usually don't think of budget as money. We're used to thinking of budget more as time, right? So we usually operate in units of sprints or something like that. If we have a time budget, and then we think, OK, this is going to be a four-week project, or it's going to be a six-week project, and then it's going to be over. When we look at something like, for example, a breadboard, this is a technique that I teach in the book, we can have these are the main components that we think are going to make this concept work, both from an interface standpoint and from a backend standpoint. If we do these things, this thing is going to work. And now we can really start to have that discussion of, We want to have the full screen photo viewer as part of this. And if we want to innovate and experiment with the interactions in the photo viewer, what does that mean in terms of our ability to do all these other things inside of the four weeks, right? Do we need to think of that as a future improvement or can we include that in the scope now, right? So this is really what's happening inside the shaping session. We have the technical person who can reveal the true cost of things. And then together with the product side and the design side, we are negotiating and making tradeoffs together to figure out what is the right scope, what is the right design, the right concept that fits into the time that we have. And then we come out of a session. Actually, when we're in the session, we might just see something like this in a whiteboard app or something scribbled on the wall. And it doesn't mean so much to the people who weren't there. But what we can do then is we can actually kind of package. what we came up with in the live shaping session. And then this can be some documentation that explains our reasoning and the main parts of the solution so that this is something that we can pass on or which will survive the passage of time. So you didn't have to be there in the room to understand that aha moment that we got to at the end of the session when we said, ah, that's what's going to work. So this we can package together and give to a team. The last thing I want to share is So these first two points were more about how we actually come up with the concept, how we interact with each other to shape the work that we're going to give to a team. The next thing that I want to share with you is more about how do we actually give that work to the team, right? And how can we have that shift in responsibility, and is there an alternative to the paper shredder? So we saw before... When we looked at this paper shredder, there wasn't a lot of autonomy, right? You couldn't just trust to leave the team alone and they would be able to happily work and figure out the scope of the project and execute and make everything really Well, to get to a point where it's a good finished product, because there would be all of these gaps between the tickets, all of this missing context, not enough understanding of how it all holds together, and also not the ability to make, they wouldn't be able to make the trade-offs they have to make when difficulties, unexpected difficulties arise, yeah? So suppose we've done our job of shaping, and we have a very clear concept that is doable. in the amount of time we want to spend. Rather than putting that through the paper shredder, we can do something else. We can change our mindset about what it means to assign work. Instead of assigning tasks, instead of assigning tickets, individual units of work inside of the project, we can actually assign the whole project. We can Say to the team, here's the whole concept. This is the whole thing. You have enough time. We have worked together to figure out if this is really doable or not. Now you can figure out the tasks. You can figure out all the small implementation details as long as it fulfills this concept. So it means that the team is able to see the whole. They have that context. where they can understand, OK, this is why I need to do this API integration, or this is why we're adding this button on this place. Because it connects to this, which connects to that, which allows us to get the outcome that we want. So there's kind of two aspects to this. One is that the team has the context that they need. They're not looking at an isolated piece of work, but they can see the relationships between all of the pieces of work that have to happen. They can see how everything connects. The other thing is this concept of latitude. And this might be an unfamiliar word. Not a lot of teams use this word so far, except for shape-up teams. But latitude means when we give work, we actually have the freedom to decide how much to spell it out. If you have a junior programmer and they're not very experienced, they will actually be happier if you give them more instructions. So get the test running and use this technique when you do it and make sure that you do this, this, this, and this when you do it. And they say thank you very much because now they don't have to be nervous that they're going to do a bad job because they don't have the experience. But if you go to a senior person who's very experienced and you say, and then when you write the test, make sure that you also do this, this, this, and this, they're going to say, come on, don't talk to me like a child. I've been here for 15 years or whatever. You know what I mean? So the way that we give the task, the amount of freedom that we build into the work depends on who we're giving the work to, right? So on the one side, we can assign the whole project and say actually individual tickets this is not the unit of work that is of interest let's say to the business and even at the product management level it's more the big chunks of work and how the whole project is moving that really matters here right so we assign the whole thing and then we give the latitude that's appropriate to the team to make the creative decisions along the way so this is basically what i wanted to share with you was this mindset change from estimate to appetite to get a little bit of a sense of what it really looks like to use fixed time and variable scope right it doesn't just mean that now we have a fixed time but we run our old way of working through this and now everyone is just under more pressure than they were before right but we are making those trade-offs earlier so that the team is really supported because they have a project that's doable from the beginning. And they're not being squeezed like that. And also, the scope isn't expanding in all directions. So that's a little bit of a vision of a different way of working. And I'm sure you have some objections or some questions. And I want to address a couple very common objections first. And then I would also really love to hear any questions from you. One of the first things that people very often ask is, well, what about the small things, the bugs, the issues, the technical debt, like the urgent request for marketing, the customer needs something all of a sudden? How, if we are working in units of six weeks or four weeks and assigning whole projects, where will we do these small pieces of work? And the answer to that is that the standard ticketing system that we all have is fantastic for that kind of work. There actually are very different kinds of work. There's planned strategic work, which is this is something that we are deciding to spend our time on that's meaningful to the business that moves us forward in the direction we want to go. And then there's the urgent, reactive, unplanned work of, oh, this server is on fire and this customer is freaking out and marketing needs it so they can launch the new campaign tomorrow and that kind of a thing, right? So a ticket-based process, there's a reason why all support tools are ticket-based, right? Because when we are dependent on someone else's schedule, then we have to keep them moving through a ticket system. But when it comes to the planned strategic work, That's where we can use a very different way of working, something more like what I talked about today. If you read ShapeUp, if you look into things about ShapeUp, you're going to run into this number six very often because this kind of six-week cycle is the way that Basecamp implemented ShapeUp. And there are quite a few teams who also do this six-week cycle style process, but actually it's not necessary. It's possible to do all of this with different time budgets. So the question is, what is the right unit of fixed time? It might be three weeks for this project. It might be six weeks for that project. It might even be two weeks for something. It's more about applying that concept of fixed time variable scope to the time box that you have. And finally, when it comes to big projects, sometimes people have a misconception that every project has to be only six weeks, right? And this is definitely not the case. It's just about an individual effort that has a meaningful end. So even if we have, let's say, a brand new product, and we know that we're going to have to build out five or six major features before this is something that we can actually give to customers, we can still chunk those features into individual, let's say, six-week efforts, and then in that way make progress and stay on track with our timeline throughout the whole thing as well. OK. That's what I wanted to share with you. Maybe the last thing I'll mention is if you read the book, if you look into ShapeUp, you might get the impression that you have to do everything the way that Basecamp did it, that you have to follow this entire structure. But actually, it's more helpful to think of it like a development framework. If you have something like Rails or you have something like React or you have some library, there's a bunch of stuff there that you can use to create your own app. a framework of principles and tools and practices, and you can pull different things together to make a process and a way of working that fits your particular company and your particular circumstance. So that's just another kind of a mindset thing. So if you'd like to hear more about all of this, there are places you can go. You can go to my website at feltpresence.com. The book there is free. There are some videos and a lot of things you can read. And then there's also a course, Shaping in Real Life, which is more about how do we actually figure out what it looks like to do this in our specific team with our unique needs. So that's what I wanted to share with you today. I'm very, very happy to be here. Thank you very much for your attention. And we have some time for questions, and I hope that you have something from your side. So thank you very much, and I'd love to hear your questions next. So we have a first question. Thank you so much, Ryan. Thank you. We already have a question there. We have a question here. Perfect. It's a perfect start of the day. We already have something there. So please. Hi, Ryan. Hello. Thanks again for the book, for the methodology, and for the presentation. My question today would be, can you give some examples of tests? for interviewing developers in order to uncover those people who have the type of skill you are describing, people who would be able to adjust the scope as they are thinking the project, as they are coding through it? So actually it's- How can you cherry-pick this kind of people in a real-life interview? Yeah, thank you very much. People often imagine that if they're going to work in a shape-up environment that they need all the developers to be creatively adjusting the scope all of the time. It's simply not at all the case. Most of the variable scope, when we talk about fixed-time variable scope, happens in the shaping session. 90% of the benefit we get is by nailing down what the actual concept is that we are investing our time into. So before we start the cycle and the build team starts working, most of that happens actually before kickoff. So there, we only need one person. Minimum, we need one person who is able to represent the technical role and help us to make a realistic concept that reflects the true costs and the true possibilities in the technical system. Really, we can do, I've seen it again and again. the exact same build team. You can give them tickets and then they'll ask you questions or you can give them a very, very clear concept and they'll say thank you very much and they'll make progress. This gentleman was first here. Hi, Ryan. Thank you very much for the presentation. I have a question regarding the two types of work, the bugs and urgent requests versus the strategic work. What would you recommend to have different teams performing those different types of jobs or the same team? Oh, that's a great question. That depends very much on your size. You may be at a scale where you can have different teams. It can be sometimes There are actually some developers who they actually get their energy from short successes. You know, if you give them small things, small puzzles to solve, at the end of the day, they will say, that was a good day. I solved 10 things. And there's other developers, if you give them 10 little things to do, they'll finish the day and they'll say, I didn't accomplish anything today. I only did 10 small things. Right they would rather be working on something for four weeks six weeks and then shipping and then they say ah that was a victory right so this When you reach a certain scale you can take advantage of these differences and and and put people into places where The type of work suits them right when we are still smaller, and we cannot do something like that Then there's a lot of possibilities one possibilities that we have a kind of rotation where we have a a fixed number of people who at a given time are over in the reactive type of work. Another possibility when we're really small, if we're like three people, four people, is that we all stop everything and on Friday we fix bugs. You know what I mean? Or something like that. Honestly, when we're very small, we can even just do it all in one blurry mix. We can have the tickets and we can have our planned work and we can just interrupt ourselves and go do a ticket because it's needed. and then go back to the planned work. I mean, when we're really small, you don't need that much structure. But when you get bigger, it doesn't work, right? So the first step, I would say, regardless of size, is to have the two different, the recognition that these are different kinds of work and they're different time investment. And then, depending on the size, what we want to go toward is that we have a kind of fixed time and fixed capacity for each. You know Mm-hmm. We have time for one last question if possible Let's try to make it the short one. Maybe two we'll also have a session in the afternoon exactly and I'd also please you can you tap my shoulder around the conference during the day, and I'll also be happy to chat Hello Ryan first of all, thank you very much for the amazing presentation You're awesome really great ideas, and thank you for the insights provided My name is Andrei Kursarou, the founder and CEO of the Center for Youth International Studies. We are a Brussels-based NGO, now Euro-Atlantic, and we're focusing on emerging threats to youth. providing focus on research and and strategic engagement one thing that we're working on is communication policies and not only our stratcom externally but also internally in terms of how do we communicate our processes what is our walls how do we approach things effectively and efficiently so my question to you today is how do you communicate this to your stuff how can you communicate this to embed this process is in their minds because we want to have a culture of harmony to know how we approach things, but how do you communicate this clearly and efficiently? Thank you. It helps to define different kinds of, so there's a couple of, I mean, actually, it's a big subject. But one starting point that comes to mind is to start to label the very different kinds of work in a kind of default The way that we just naturally go into a company and try to work together, especially in software, we kind of are either in a meeting or we're coding. And that's what you'll see in the calendar. Like, you know what I mean? It's either I'm in a meeting or I'm building something, you know? And this doesn't map to the different kinds of work that we have to do together to move a project forward. So, for example, shaping is different than coding. You saw that shaping session, right? That thing where we're looking at the different house options and making the trade-offs, that's a strategic session that happens at a specific time for two to three hours with certain people in the room at a certain life cycle of the project, right? So we can identify, oh, there's something called shaping, and this work happens at a certain time, and that's different than other work. There's also, you can contrast shaping with what we call framing. Framing is earlier, is this an opportunity? Is this a real problem? How much budget is it worth? Maximum? So think of it more as the business strategy aspect of the project formation, right? Is this a real thing? Is it more important than the other things? Do we do it next or do we do it later this year? That kind of a thing, right? So there needs to be some framing of what is the problem and opportunity and what is the maximum we're willing to invest. And then taking that understanding of the problem into the shaping session. And then in the shaping session, saying, now, what is the technical solution that's inside of our budget that we can do? And then taking that into, now, how do we actually turn this into real work? So the more that we understand the different kinds of work that happen along the lifecycle of a project, from raw idea to finished product, we can start to communicate about those things. And then in terms of turning those into company processes, the best success I've seen is to first have a pilot project. That pilot project is so clearly different from what people are normally doing that everyone says, what did they do? How did that happen over there? And then you can start to use the concepts and the language to describe what they did. And it's not just those people are magical people. But actually, they worked in a different way, and we can use that same language and framework in other places as well. Thank you so much, Ryan. Thank you. Unfortunately, we do not have now time for more.

The ‘growth at all costs’ reality has changed –  being efficient, profitable, and delivering things that work, on time, is more crucial than ever. Ryan Singer shared how his experience with Basecamp, where he spent over 17 years, developing meaningful products quickly, building common language, and mix-and-match tools to fit your team. If you’re running in circles, pushed-back timelines, and disconnects. It's time for Shape Up!
________________
Ryan Singer is a Product Builder, Advisor, Author @ SHAPE UP

20+ years in product building and pioneering design & development processes, 17+ years as ex-Head of Strategy at Basecamp, now on a mission to get tech teams unstuck, and build by the principles of Shape Up.
_______________
Tap into more insights by joining us at the next edition of How to Web Conference 👉🏻 https://www.howtoweb.co/