Long before a product team is truly stuck, the tensions are already building: work drags on, pressure mounts to move faster, and product, engineering and business all seem to be speaking different languages. The trouble usually isn't bad estimates or bad design; it's the inability to align on what's actually worth building and whether it can really be done in the time available.
Drawing on seventeen years at 37signals and the Shape Up method, Ryan Singer offers a shared vocabulary for the journey from idea to execution. He separates framing (the problem to solve) from shaping (the solution to build), makes the case for a fixed six-week appetite, and uses the story of Basecamp's calendar, reframed from "build a calendar" to "see empty spaces to book," to show how narrowing the problem unlocks a concept a team can finish. Rather than shredding projects into a thousand tickets, he shows how nine well-sequenced slices give everyone a clear answer to the question that really matters: where are we now?
Auto-generated transcript - may contain errors.
Tap a timestamp to jump the video.
Good morning. Very nice to be in such a beautiful city. I have to say this is an amazing place. I don't know. How many are local? Really quite okay. So I don't have to tell you. Yeah. But it's really fantastic. So happy to have the opportunity to see this for the first time.
So I'm gonna talk about getting unstuck in the product development kind of flow. And maybe stuck is a strong word. Stuck is kind of the endpoint that I sometimes see when folks finally reach out and and ask for help. The stages before stuck, it's kind of like tensions are starting to build between the product side and the engineering side.
Tensions are starting to build between business or sales and engineering. There's this feeling like the things that we said we were going to do, they're dragging too long. And then the things that we said we were going to do are taking too long, and then at the same time, there's this, like, more and more pressure that we should be moving faster or we should be building the next thing.
You know? And then if we're working on the actual product development, whether that's on the sort of PM side or the business side or the design side or the engineering side, we kinda start to get caught in between all these tensions and pressures.
Is that is that at all familiar to anyone? Okay. I see a little bit of vibration in the heads. Okay. And, and then what happens is, you know, when we don't solve this and then we keep just thinking we can throw more engineers at it or we are going to whenever.
You know? We are just going to, keep scrum cycling our way. Then eventually we get to a point where we realize, like, we haven't shown enough progress in too long, and that's when I would say the word stuck is fair. Okay? So if you're not stuck yet, but, you're starting to feel like why are things taking so long?
Why is it so difficult to get projects through? That's kind of what I'm talking about here. You know, my background is I came into Thirty Seven Signals in two thousand what was it, two thousand three and, two thousand three, and I came in as a UI designer.
And, I started to discover that just if I made mock ups, it was too difficult to actually see, turn them into reality, and the feedback loop with the engineering was much too long and painful if I wanted to make changes. So I started to get more technical.
And then as I started to also be able to code, I became kind of someone who could translate a little bit between the design side and the engineering side. But then I understood that if we're building the thing that isn't the thing that, you know, leadership wants or the thing that isn't selling or isn't the thing that customer wants, then we get into a place where we do all of this work, and we're not happy with the result anyway because it didn't scratch the itch.
Right? So then I got interested in the kind of the business side and the strategy side. So that's sort of my journey over the seventeen years that I was at thirty seven signals and mainly working on on Basecamp, our our main product there.
And one of the things that I learned through that experience and one of the things that I needed to sort of, like, figure out again and again is how to bridge those gaps because product and engineering and business, they all speak different languages.
They see problems in different ways. And if we can't really understand each other and align on multiple steps through the whole life cycle of a project, from this is something we might maybe do to this is an idea that we actually have appetite for, that there's energy that we want to invest in, to here's the thing that we all think we agreed we were doing, to here's the thing that we expected to see a demo of but it's already been three times the amount of time that was
estimated to we're finally seeing the demo, and it's not what we thought it should be, and now we have to go backwards. Right? All of these different moments in the life cycle of the project, very often, it's not just a question of, you know, the engineers didn't estimate well.
It's not just a question of the design isn't the thing that we ended up wanting. It's the ability to come together and understand each other and actually align on is this what we want and is it actually doable. Okay? So that's that's kind of the I'm trying to unpack the title.
Okay. So when I say technical and non technical people working together in these kind of key moments through the life cycle from idea to execution, I want to give you a sketch of that. And I can only do so much in thirty minutes, but what I would like to give you here is some language around these different stages.
I would like to give you a model of what it can look like when that goes well, when we really have clarity at these different stages between the technical and the nontechnical roles, and then maybe give you some new questions turning in your mind of, you know, is the way that we're doing things really working?
Should we be thinking of something else? How could that apply for us? But what about this or what about that? And as those questions come up or even those objections come up as you see what I'm sharing, I would love for you to kind of keep it in mind because we have this fantastic format of the speaker circle.
You know? So what I can do in these thirty minutes is try to put some things into your brains for those of you who have problems like this. And then when we get together in the speaker circle, that's a real chance to, in a in a very short amount of time, you know, use this language and refer to these examples to have an exchange that jumps straight to the thing that you're wondering about.
Okay? So, I'm really happy about this format. This combination of speed talk and then sitting together in the round is is is fantastic. It probably you had a good experience with it yesterday. Yeah? I could imagine. Yeah. Okay. So, let's get started. So I wanna give us some some common language around this process, and I also have two major assumptions that I need to check with you.
Okay? So the first assumption is that when we are actually building something and engineering time is being spent on something now this is this might sound crazy. The assumption is that we actually consider engineers' time to be very valuable and expensive, and we want to use it well.
Okay? I know it's a very, very far jump, but this is the assumption that I would like to make, okay, that we value engineers' time, that we treat it as one of our I mean, the thing if we're working in software. I mean, what are we doing other than building things? Right?
And and how do we use that time well? How do we treat that time as important? Okay? So if you're with me, then we can continue. Alright? So let's let's let's pretend that also the other people at your organization agree. Okay? Okay. So the engineer's time is very important.
If the engineer's time is important, then we need to do some things. Right? Just throwing tickets onto a onto a giant kanban is not necessarily going to give us good results from that precious time. So what can we do? So I'm just gonna give you some words here.
Right? So this term, shaping. So one thing that we can definitely be doing is having more clarity at the beginning. I know this is not popular in the world of scrum. Actually, having a plan. This is the thing we're gonna go build. Like, if we're gonna build a house, it's not like, I don't know. Let's give it two weeks and see what comes out.
But, like, no. How many bedrooms does it have? How many floors does it have? What is the layout? Where does the electricity wiring need to go? I mean, the basics. Right? So having a clear concept of what the solution is before we actually make that time commitment and ask engineers to go build something.
Okay? So that's the shaping aspect. It's the solution side. It's the concept of what to go build. That's one thing. But if we want to have more clarity around the thing that we're actually going to go build and not just kind of iterate without knowing where it leads, then we also need to do something else, which is we have to have clarity around the problem or the opportunity that we're pursuing, which is a different thing.
Right? So and I'm just gonna use the word framing in this talk. Okay? This is also the language we use in shaping in real life. It's this work that we do to say this is the thing that we're trying to solve, and this is how we know if the project actually succeeded.
You can think of it almost like the acceptance test for the whole project. Right? How do we know it's working, and what is it supposed to actually do, and why are we investing in this thing now? And there is a further step upstream that I'm not going to talk about today, which is, of course, our decision around which problem to to to solve, which feature to build, which thing we should be improving or fixing that should align with some kind of there has to be some kind of a bigger
strategy or vision or probably some pressures coming to us, you know, that stakeholders really we need to see more activation for for for q three. Right? Or we have to solve this churn problem. Or we have this major new feature area that sales believes they can upsell if we could actually get it into their hands to to go sell to customers.
Right? So what is the thing in this period of time that's actually important that we're going after, and how does that filter down the things that we then frame and shape and then try to make a smart investment, a time investment into? Okay.
So this is a very kind of simplified picture of the life cycle from idea to execution, and especially the different kinds of work that we need to do and where we have to integrate together and understand each other. So I'm gonna start with this, framing step and then we're gonna work forward into building from there, and we're just gonna use one example that's easy to relate to as we go through this.
But before we come into the example, I have a second assumption that I wanna check with you. Okay? If we look into this framing moment I I sorry. I can't decide which TV to look at. I want to point to you. You know? Let's try this one. Okay.
If we look at this framing moment, then we're thinking, okay. We have this thing sales wants. We have this thing that the engineers are complaining about. We have this thing customer supports wants. Product has been complaint have has been arguing that they want this feature.
Right? We have all these different things, and there comes a moment where some time becomes available. Okay? So I want you to think about this moment, that time is becoming available. So so let's say some team is becoming free. Right? Imagine that. That would imply that they finished something.
But anyway, somehow some resources are going to be available to us. Right? And now out of all of these possible requests and problems and opportunities, there is some body and some of you are in small teams, some of you are in bigger companies, there is somebody somewhere who says I get to decide how that time is spent.
What are we gonna use that time for? Okay? Now this picture already has an assumption in it, which is that the time that we're going to invest is finite. Okay? That it's like if you wanna go buy a car, it's not like, well, you know, let's just pay let's just pay for the car every month and see how see how it goes.
You know? Or let's just pay two weeks a little bit more for the car, you know, and see how it goes. We we generally would like to say, what is this car cost? What does that car cost? Are we buying a Porsche? Are we buying a Volkswagen?
Like, what are we doing here? Right? Are we buying a used Toyota? Like, it's very big differences. So here's the assumption. When we actually make a time commitment, when we plan to spend time on something, we intend to finish the thing. From the beginning, we plan to finish it.
Okay? And it sounds ridiculous, but if we look at how projects are being run-in most cases, we don't see this finite time box that has a clear beginning and end, and we're gonna finish it and celebrate. What we see is one of two things.
You'll see which one looks more familiar to you. We see the never ending open ended time box. Very often, this sounds like, oh, you know, we went to engineering, and they said, you know, they think it'll take three months. They think it'll take three months.
Right? Or they think it'll take three weeks. Right? They think. We'll see. Open ended. Right? So this is one possibility, which we very often see. And, of course, when it's open ended, the end never comes until all of a sudden somebody starts yelling.
We talked about that pressure. Right? The tensions build, and there comes a point of, like, oh, this has to end somehow. Right? And then we go into emergency mode. The other thing that we see is instead of the open ended time box, we see the tiny little slice of time.
What is this thing called? A sprint. Tiny little slice of time that you can't actually accomplish anything strategic in. Right? I mean, you can do bug fixes. You can do little growth hacky things. There are things that you can do in a tiny slice of time.
But if it comes to building a feature, making something that we're gonna go sell, you know, making a meaningful change to a product, you can't do that in in a week or two weeks. You know? So what happens is we have to cut it down to something that doesn't actually do anything by itself, so then we have to have another and another and another and another, and it's another version of open ended time, actually, just just in a different dress.
Okay? So, so the picture that I wanna give you here is, the way that we talk about this in in ShapeUp and with the teams that are inspired by ShapeUp is we have a kind of a fixed time box, which is maximum six weeks, which is kind of the furthest that we can see where we can say, I can make a promise.
I can make a promise to everybody around me that we can come up with something, we can shape it, we can build it, and we can release it and finish it and celebrate at the end of six weeks. And at the end of the six weeks, you will see a relationship between what we talked about and what was shipped.
Okay? This is possible in this in this amount of time. So, sometimes we see teams saying six is a little long, they do, like, five or four, and they figure out how to combine it with quarters. There's there's things like that. But let's say a chunk of time, and we're going to talk about six weeks here.
So this is the this is the the first thing, is actually even just setting clear expectations around time. What is the time budget? What does the work have to fit into? When do we expect to celebrate something? Okay? So now let's say that we are aligned on the idea of finishing something and working with a time box that is, let's say, like something like six weeks.
Okay? Then now the question is, how do we actually get clarity around what we're supposed to solve inside of that time? Now we really come into the framing work. And very often, when work comes to us as an idea of what we should be doing, when it comes from sales or customers or support or the CEO's idea in the shower that morning or whatever it is, it takes this form.
We're gonna build notifications or we're gonna build a dashboard, the classic example. Right? Or we're gonna add this permission feature. You know? Customers want this permission feature or sales thinks that if we add this additional permission option, then we're gonna be in better shape and so on.
And all of these things are what we could call the supply side. They're not describing what somebody's trying to do. They're not just trying to describe the problem being solved. They're not describing the itch to be scratched. It's a solution. Right? It's describing what to go build, so it's a supply side definition of the problem.
And of course, if we say go build notifications, how can we align on what that actually means? How do we know where it ends? How do we know where it stops? And how can we possibly fit it into a finite time box and understand what that celebration moment is gonna look like when we ship?
It's very difficult to align on that. So what helps here is to flip this around to the other side and to look at it from the demand side. The demand side is what is the problem, who is struggling with this, why does it matter, why is now the time to fix this.
This is the kind of clarity that we aim for, and I'm gonna give you a little picture for this. Okay? This is we're doing the the the high speed version of this, but I wanna just give you a few things that you can take away to to stick into your mind.
We know what the supply side looks like. Somebody says notifications or dashboard, and everybody has a different picture in their mind of what that means. How do we picture the demand side? A good way to think of the demand side is someone who is trying to cross a river.
Okay? So what this highlights is that somebody is trying to do something that they can't do today. It means that there's a struggle. Right? Something is wrong. And the person who is on shore a is in some kind of a context, and we're saying, what are they doing now?
Not what do they want. What are they doing now? And why isn't that working? Right? Then if they could cross the river somehow, right, how would we know that it was better? What would progress actually look like? What would it mean to be on the other side?
Because you can say build notifications, but it's like, are we there yet? Are we there yet? Are we there yet? We don't know. Right? So what is the actual outcome? Then the supply side, that feature that we're gonna build, is like the bridge that goes across.
Okay? And the more that we understand what someone is trying to do in the circumstance we're in, that's what gives us the constraints to make the trade offs on the supply side. What I mean is if the task is to build a bridge and you say, okay.
From where to where, how long is it? Is it for heavy trucks to carry cargo, or is it for hikers who are just on a little journey through the forest to get over the small river? Right? If it's for heavy trucks, the bridge needs to be built out of steel, and it has to support masses of weight.
Right? If it's for the the the hikers who are walking through the forest and need to cross a small river, then the swinging rope bridge is romantic. Right? You know? It's a question of what fits the circumstances. So this is a very good picture to flip our mind out of the supply side into the demand side and say, who is in this situation?
What are they trying to do? What isn't working today? I'll give you let's look at a at an example here. There some of you might know the example of the calendar from the from the book Shape Up, but I'm gonna show it to you in a different way here.
It's my it's my favorite example because it's easy for everyone to quickly catch up on the background. So let's say we have a request for calendar. Right? Okay. Who what are they doing today? Why isn't that working? How would we know if calendar was solving it for them?
So this was a real project that we had at Basecamp. And, quick backstory. We have there there have been four major iterations of Basecamp. And and and a couple and let's say, two times along the way, we totally even rewrote the app and built it again from scratch successfully, by the way.
It's possible. And and, on the on the second version, we had built a full featured calendar, I mean, really quite full featured, and we saw from our data that almost nobody used it. And it was a big effort. I mean, it was months of work, and we didn't see people use it.
So when it came time to do the third version of Basecamp, and we built it from scratch, actually, at that time, we said we're not building the whole calendar this time. It wasn't worth it. And instead, we built this kind of very simple we called it a schedule, and basically, it was just a list of events, you know, where like an agenda view.
You know? You could see date, event title, date, event title, and it was just for some important dates in the project. So we built this schedule version instead in version three. We thought that it made sense because nobody used the calendar before, but we kept getting these feature requests.
Again and again and again, people said, we need a calendar. We need a calendar. And, of course, customer support is on the front line, and they have to keep saying, sorry. No. You know? Again, they said no. Sorry. You know? And, or making longer and longer excuses. You know?
So eventually we said maybe we should try to understand what do they mean when they say calendar. And when we looked into it, we started with this question. What are they doing today, and what's going wrong? So on the context side, the short version of this is they were trying to book a scarce resource with a third party, and they couldn't see the availability.
They couldn't see open dates on the agenda view because it only showed a list of things that were booked. So they couldn't see where are my chances to book. An example of this is, we had one client, and they had a they had this, like, mainly open desk seating in the office, and then they had this one fantastic conference room.
You know? And, like, the conference room was the place if you needed to meet with a client or if you had a really important kickoff or you needed to work out a really hard problem, you wanted to be in the conference room. But the problem was that, you know, like, you had to book this conference room so it would be available to you.
Right? And, they had tried using, other services like other calendars so that they could see a date when they could book the conference room. But there was always this problem of, you know, oh, it's not in Basecamp. It's over in the the Outlook calendar thing or it's in the the the Microsoft calendar thing or it's this other Google calendar.
And then they didn't have the link or they didn't have the permission to see it or they couldn't find it. You know? Then you end up with double bookings and showing up and somebody is already there and stuff like that. Okay? So when they tried to hack it by putting the calendar in using a tool outside of Basecamp, People weren't finding it or they didn't know how to get into it or they couldn't access it, and then they had all these problems.
So what we understood was when they said calendar, they didn't need everything that a Google Calendar can do. Right? They didn't need what a doodle can do. They didn't need, like, high fidelity dragging interactions and stretching the length of something on a week view or a day view, you know, complicated front end engineering and and and and everything.
What they needed really was to see empty spaces so that they could see when was available to book something, and they needed to be able to access it where all the other stuff was on their Basecamp account. And for us, the outcome was to be able to say no to all these to to stop saying no to all these requests, to say, actually, we have an answer for that.
When we narrowed down the problem from build a calendar to see empty spaces for booking things, to see availability, now it became possible to actually talk about what is a solution to that that we could actually finish inside of six weeks. Right? We really narrowed down our understanding of what we're trying to solve.
And so we were able to say, oh, we're not trying to build a calendar. And we shaped a specific idea that's not a calendar. We called it the dot grid. And the dot grid was basically this. This is what we shaped. It's a two month view similar to what you see on your iPhone.
It's like a there's a there's a there's a calendar grid for the month, but there's just dots to show if there's something happening on that day. And then you tap on a day, and then the agenda view that we already have scrolls underneath, and then you can see kind of what's already booked that day.
And you can very easily, just by clicking through on different days, see what's booked, where the openings are, and then book a free space for yourself. Okay? So and if we if we spell this out, what are the moving parts here? Okay. We're not looking at a million Figma files.
We're not reading a ten page document. We're looking at a little ridiculous drawing. Okay? But it's so clear what the idea is. You know? There's a two month grid. We can navigate forward and backward in the months. The days in the grid are selectable.
When I select a day, it scrolls the agenda view below, and we're gonna have the ability to add something to the selected day. Right? This is something we say, uh-huh. This is something we could accomplish in six weeks. We understand it. We know what we're saying yes to.
So this is what I mean when I talk about clearer shaping and a clearer frame. Now what does this look like if we're actually then supposed to be building this thing? So if we said yes to the dot grid and we're going to put this into the time box, but now we're in the role of the engineering team and we're supposed to be building this thing, or we're in the role of the designers who are detailing out different interactions and high fidelity for this thing.
This is the picture that we can have. When we're doing the building, we have above us a big picture of the whole. Ah, this is the whole concept. Not a ticket, not a hundred tickets, one clear concept. This is the thing that we're building, the floor plan.
Right? And then above that, at an even higher level, we have the containing walls of the frame. This is what we're solving. This is what this project is about. All of this is to see empty spaces, and this helps us to avoid a lot of common problems.
You know, a lot of times, people work on a project, and they have some kind of a definition of what to go build. Maybe there are Figma files, maybe there are sketches, maybe there are requirements, but they don't have a frame. And when we don't have a frame, then what happens is there's no containing walls to keep the scope in.
So what happens is the team ends up boiling the ocean, and the scope keeps expanding and expanding and expanding because we're back to calendar. Right? We don't know when to stop. On the other hand, if we have just the frame, oh, we just need to see empty spaces.
This is a common problem I see with teams who adopt shape up just by the book. Common misunderstanding is they think that this pitch that they write should just describe the outcome, and then the team will figure it out. But if we just say see the empty spaces, the team, if they have to start building I mean, if the clock starts and they're inside of that time box and they should be using the time well, they're asking themselves, like, oh, what do we actually do?
You know, they don't have the concept. So what we see here when a project starts like this is no visible movement, lots of discussion. Maybe it's this, maybe it's that. Oh, we're sketching an idea. Right? And no actual progress on the project. When we have both of these things and questions come up, it's easy to answer them.
So, for example, somebody says, shouldn't we have color coding of the calendar of the different calendar events? Every calendar has that. Right? We're building a calendar. Shouldn't we have color coding? And you can say, does it help us to see empty spaces? Is it good one.
Okay. Actually, we don't need it. Right? And they say, you know, what about when we have multiple day events, you know, and it's just we're gonna have dot dot dot dot dot for the same event? Wouldn't it be much better UX if we had a line going across?
Right? And the line wrapped around if it was a really long event and we could see just from the grid when it started and stopped. You say, oh, fantastic. Beautiful UX idea. Does it help us to see empty spaces? I say, wow. Not really.
It doesn't really impact our ability to scratch the itch to solve the problem. This is really the key to keeping scope under control and to getting that alignment and that focus is having a clear answer around what are we solving. Right? And you can see how it's both on the framing level and the shaping level.
Okay. So we talked about clear expectations about time. We talked about much clearer expectations around what are we solving and what are we building in terms of the framing and the shaping. And I want to end by giving you a look at how we can have clearer expectations when we are kicking off the project and through the timebox, through the building of how to answer the question, where are we?
Right? What are we working on? How close are we? When do we get to demo something? Is it coming together or not? These kind of questions. Okay? Now how does this get handled today? It's painful. I'm just picturing what I often see when I when I work with teams.
You know? It's like, so where are we on the project? And then you open the board, the issue board. What is that? That's not an answer. It's a million things. So putting a million tickets onto a board and saying, oh, we have forty five percent of tickets complete.
That tells us nothing about, like, how what this thing that we shaped, like, is it working? Which piece of it is working? What's still unknown? Like, what is most important to solve next? Right? What are we going to demo? There's just a million small little shreds there.
So this is, when we're at this kickoff moment, when we're starting to build, how do we actually define the implementation work, what to go do? And this typical process of treating projects as being made out of issues, I like to call it the paper shredder.
You take a concept, and you say, now we will make a million tickets. Congratulations. Now you know what to do. Of course, they don't all glue together perfectly into a working final solution. Right? It doesn't work. So here's an alternative. We could talk a lot about the paper shredder.
Issues, by the way, are made. Tickets are made they come from the world of the help desk. You know? They are perfect for that. If you have a thing that has somebody who is waiting on the other side of it, a customer, a stakeholder, a thing that's on fire, there's a problem that's urgent, and it needs to be resolved, and we need to know if it's still open or closed, that's what a ticket is for.
Right? Something that's on fire. If it's not on fire, if it's a project, then tickets have nothing to do with actually getting to a clear solution to the project. Right? You don't go build a house with a million tickets. Right? We have to have some big, clear chunks of work that we go after.
So Here's a simple way to do that. This is a technique that I have a lot of teams doing, and it's looks like this. Instead of slicing the work into endless tickets, we simply take that time box, let's say it's six weeks, and we divide that time into nine boxes.
Okay? Just nine boxes. Now we get to do some math. Okay? So let's take the extreme case of a six week project. Alright? Six weeks is thirty business days. Thirty divided by nine boxes is three point three three three three, so less than four days per box.
So if we wanna finish something in six weeks and we just break it into nine things, not a thousand things, not a hundred things, nine things, then each of those things is less than four days. A unit of work that needs to be done, like, actually done in four days is something very real.
That's something that any of us can look at whether we are looking at it from the technical side, you know, into the implementation detail. Four days is something that is we can actually answer that. Is that really going to happen or not? What is involved?
What are we going to do? So the exercise goes like this. At the kickoff of the project, we don't have a product manager figuring out what these nine things are. We don't have some representative of the team giving the team their tasks. The team themselves, because they have an understanding of what to go build, because it was clearly shaped and they have the meaning of it from the frame, they can define their own tasks.
Right? The ones who are actually doing the work, who understand the work then can define their tasks. So the technical people actually building can fill out, here's the nine major things that we need to need to build as vertical slices. Right? We're gonna get the two month grid rendering.
We're gonna get day selection working. We need to be able to have this scrolling agenda. There's this multi day event case that we're gonna have to be able to solve. You know? These are the things. And if we do these things less than nine, the project will work.
Right? That's the right level of understanding for us to have an overview. And we can go further than that as now on this on day zero of the project, we can also talk about sequencing. By the way, I have little to dos in gray under here because if they also describe what some implementation tasks are, this shows that it's not just some hand wavy idea but that they've actually gone into some concreteness.
So this is very helpful to have a little bit of a sense of here's some to dos of what it looks like to do that thing. So we've got the nine boxes, and the second thing we can do is to sequence those and say, what's the thing we wanna demo first?
What's the thing we wanna demo second and third? And remember, if each one of these boxes is only four days or so, it means we should be seeing something working that connects to our big concept already at the end of week one for sure.
For sure. And teams who do this, they do it again and again and again and again and again, right, because of the clear expectations. So there's sequencing. There's a lot we can talk about with sequencing, but I'm gonna wrap. The last piece is then when we actually do one of these things.
So let's say rendering a two month grid is first. When we get a two month grid to render, what do we get to do? We get to check it off. Such a pleasure. Right? To take a major chunk of territory and say, this is handled.
This is done. This works. The problem space is smaller. Right? Our task has shrunk. We are nearer to the end. Right? This works. This doesn't work. This is next, this is already done. That's the kind of conversation we want to have, not the opening up the issue board and looking at a million things.
This is something that has meaning. Right? And then we say, what's next? And we get it working. What's next? And we get it working. What's next? And we get it working. Right? This is what it looks like to have a clear map of where we are in the work, where we are in the cycle, what is being built, what is next, and to have all those conversations.
Okay. So we talked about time. We talked about getting clear about what we're solving, what we're building, and we talked about having a much better answer to where are we now by using the right tool for the job when we're doing project work instead of putting fires out.
Right? So that's what I wanted to share with you. I hope it gives you some ideas and some questions and stirs some conversation for our sitting circle at ten fifty. And if you want more, you wanna connect with me, I would love to hear from you.
Feel very much welcome to just write me an email or a short note on LinkedIn or something like that and tell me what resonated, and you'll also find more on my website there. So thank you very much, and I look forward to seeing you later.
