“Scaling Shape Up Beyond Bootstrapped Companies” by Ryan Singer

Hello everyone, I'm very happy to be here in Paris. Thank you to Le Product Con for having me. And I'm excited to talk to you about, well, we're going to talk about a few things. The official subject is scaling ShapeUp beyond bootstrapped companies. And I am going to talk a little bit about ShapeUp. I am going to talk a bit about applying it beyond just companies like Basecamp to a wider variety of companies. I want to get real with everyone here. We're talking about product management. We are a bunch of product managers here together. And there are so many things that we are in theory supposed to be doing. We should be interviewing customers. We should be figuring out the strategy. We should be aligning. We should be talking to people in all these different silos. And we should be transforming everything. We should be making the whole business led by product. And we should be doing all these different things. And if we look at the reality of what is happening in our daily work, What's really happening is we are under... By the way, I'm trying to see you. That's why I'm doing like this. We are under intense time pressure. There are projects that are running that are unfinished, that were supposed to already be finished. There's a bunch of stuff that we came up with in our discovery or whatever process we went through that isn't really happening in real life. There's a bunch of unexpected technical complexity. There's unanswered questions. Everything is in a rush. And we are responsible for somehow getting the project finished. Not for setting the strategy for the whole business, but for actually getting individual projects finished. And we find ourselves under a tremendous amount of pressure to actually do that. Let's start with a... This was the initial slide, so hello. Now we are at the official beginning of the talk. Welcome, and let's get going, okay? So I want to talk about this real situation of being under time pressure to deliver. and what is going on in our daily work as product managers. So the situation very often looks like this. This might be us talking to the technical folks. Why aren't we done yet? This might be someone above us coming down to us and saying, you are responsible for this team. Why isn't the project done yet? And then what's going on? Well, sometimes this is the reason why. It turned out that what looked easy on a drawing turned out to be a little bit more complicated when it got to the engineers and it actually had to be built. Or we might see something like this. The designer creates a beautiful Figma file, right? With a million different screens and perfectly every color and every little detail. And then after lots of work and putting their artistic heart into this, it goes to the developers and what do they say? Oh, we can't build that, right? Or sometimes it happens differently, where we create a big brief, right? And here are all of those strategic reasons why this is important. Here's all the research we did. Here's the business case. Here's all of the alignment work that we did. And it's going to be powerful, and it's going to be fast, and it's going to be easy. And we bring it to the technical team to actually go build, and they say, I have no idea what to make. How do I make it? powerful and fast and easy. There's no trade-offs there, right? Even when we do come up with a very coherent concept, when we manage to get all those different roles together and we have something that is realistic, that's actually buildable, that is well thought out, that has the different answers to the different questions that are going to come up, in most teams today, this work that we produced goes through what I like to call the paper shredder. This is what is called the scrum, if you've ever heard of that. It's where you take something which is meaningful as a whole and you shred it into separate tickets. Right? And what happens is all of the context, all of the relationships, all of the backstory, all of the meaning in the project is destroyed. And since people just now have individual work assignments, The theory goes that everybody has their assignment and it's all going to come together in the end. But we are not like the brilliant designers of IKEA furniture, where we can create all the different parts and the assembly manual and then they will just put it together and they'll have the bookcase standing there. No, usually the pieces don't fit together like that. So what happens is everyone's holding their ticket and who do they have to go to? They have to go to the product manager to say, I'm missing requirements. I don't understand what this means. This isn't buildable the way that it was drawn. I'm blocked on somebody, right? Can anyone tell me, do they recognize what I'm talking about? Yes? Okay. So this is like daily life, right? We are busy with this stuff. How are we supposed to think about strategy and do user research and do even a deeper, longer, more complicated discovery process when we are kind of chasing after all the little pieces of work that we already thought that were solved? So this is actually not okay anymore. I mean, if it's okay for you, then that's great. Congratulations on having a luxurious situation. But what we're finding is that the environment has also been changing around us over the last 10 years. You know, when we have these unexpected technical complexities, when we have all of this basically waste, creating a complicated drawing and then having to throw it away. When we have all of these tickets that are for unfinished projects, and then we're supposed to... We look at the roadmap, or you look at your product board, and you have a million other things that you're supposed to be doing, but the current work is still unfinished. Projects are dragging, right? And then, of course, the work is getting rushed. because we're running out of time, which means equality is going down, which is leading more bugs and more problems in the future that we're supposed to be responsible for. So, you know, the circumstances changed, and it used to be that everything was about growth at all costs. Right? Before this situation we've been in in the last 10 years, all that mattered was growth. But now the environment around us has shifted back to the fundamentals, back to... What's really important is being efficient, using our time effectively, profitability, delivering things that really work, and then moving on to the next thing that's valuable to do. We are in a new world. Many folks actually started in product management within the last 10 years inside of this kind of growth-at-all-costs mindset. And because of this, most... Most of us were never actually trained in how to effectively deliver, how to make sure that the time goes toward creating value, how to make sure that actually we are shipping on time and quality and it's moving the business forward. This is something that nobody taught us that we haven't learned how to do. This has been the main focus of my work for the last 20 years. I started at Basecamp in 2003. And originally I was a UI designer, so I was doing hands-on interface design work. And I started to discover that when I could imagine something that I wanted to make, I could picture the button and I could see how it should all go in terms of the user flow. But because I wasn't technical enough, I couldn't turn that into something that actually got delivered. So I learned a little bit more about programming. And then when I knew both the design side and the programming side, I became kind of this bridge person. who could communicate between the two worlds, and that's how I got into this product management role. And then the next problem was, well, now we know how to build things, but how do we actually figure out what is meaningful to build, what is valuable to build, what is strategically a good use of time? So this led me more into the strategy role and eventually head of strategy at Basecamp. And then over the last three years, I've been helping teams at a wider variety of companies to apply the different things that we've learned. And the things that I learned were kind of formalized in this book, Shape Up, that came out in 2019. Now, I want to tell you a little bit about the things that we learned when I was at Basecamp at 37 Signals, because it was a fantastic learning environment. It was a really special opportunity to solve these problems related to time pressure. When I was at Basecamp in the early days, when we first did the first version of the product, David, the CTO, was the only programmer. and he only gave himself 10 hours a week to code. So we had two designers, one programmer, only 10 hours a week. So we had to use trial and error to really figure out how do we get meaningful things done in this tiny little bit of capacity that we have. And also the partners, Jason and David, they were very, very slow to hire and slow to grow because they wanted to keep that constraint where we always felt the time was precious and we had to use it well. And it means that we had to come up with a lot of different techniques to actually figure out how to successfully do that. So the first thing that we would do is we would play this game of always asking ourselves, what's some version of this that we could do in six weeks? Or what's the one-week version of this, right? Is there a quick way that we could hack it? So like using time as a design constraint, not just coming up with something and then estimating how long it's going to take, but saying, if we play with the time, can we come up with different ideas for how to actually solve it? We would put technical and design people together very early on in the process. And this is something I want you to kind of keep in your mind as we go through the talk today. Think about when do you have PMs and designers collaborating, and when do you have collaboration with technical people? In the whole life cycle of the project, do you have strategy, strategy, research, research, discovery, drawings, design, prototyping, and then the last little sliver is, oh, and then, by the way, execute and build it, right? or are the technical people involved earlier? This is going to be a big theme. So we understood that we needed to put the technical people and the design people together much earlier so that all the real hard facts about what is technically possible, that those complexities were surfaced earlier in the process. To avoid throwing away work, we created this kind of habit of doing really rough drawings that showed what was important about the relationships in the system. but we weren't doing the high-fidelity drawings that were pixel perfect, because we knew that it was much too early at the beginning of a project to make a perfect rendering of exactly how it should look. We knew from experience that we had to throw that work away when we did that, and it never went into the final product. And this was waste, and we couldn't afford that wasted time. And lastly... We understood that if the team always had kind of questions they had to come back to answer, if there were always things that people were blocked on, things that they were held up on, then the projects wouldn't be able to move forward. And as product managers from this kind of seat, even though we didn't have that title originally in the beginning, there wouldn't be time to think strategically if we were constantly herding the cats to answer the questions and solve all the unexpected problems that were coming up. So we needed to figure out how can we make the build teams autonomous so that they can answer questions themselves, they can make judgment calls themselves, and then we'll have time to think about what's next without being interrupted by all those things. So these practices are things that I learned by working with Jason and David and that we were experimenting with together in the early years of 37signals and developing Basecamp. And of course, the company grew from three people to 10 people to 20 to 50. And the environment, of course, changes as you grow. And one of the things that really changed was in the beginning, a lot of what happened, it was almost a little bit like automatic or natural because, you know, you have lunch together and you know each other and you have a similar way of thinking. And a lot of it just kind of happened by itself. But as we started to hire more people, we found that we needed to be able to explain the way that we were working and to... have a language and some structure around how we work so that we could bring more people in to participate in that. And that led me to write this book, Shape Up, in 2019. And what's in there, basically, is a formalization of what we just talked about. So this question of what might we be able to do if we gave the project six weeks, versus what could we do in two weeks, this question of sort of setting the time limit as a constraint. So there's a huge difference between saying, here's the solution, how long does it take? That's an estimate. If you reverse it and you say, here's the time we want to take, what are four different solutions that might fit inside of that time? That's a design problem. That's a totally different approach. So this became the notion of an appetite instead of an estimate. And then this practice of making trade-offs to really get into the details of the solution design and say what can fit inside of that time box. If we think of the time box as a cost, what are the costs of the different parts of our solution? And if we piece them together, are we still in the budget? Both in terms of time and effort and available people and all those things. This is what we actually called shaping. And then the rough drawings, these practices of not doing the Figma sketch, but actually coming up with these other methods. This got formalized as fat marker sketches and breadboards. And then originally, a lot of people latched onto this. We were just doing all projects in six weeks because we found that we were able to accomplish much more meaningful chunks of work in six weeks than in two weeks with a two-week cool-down for alignment and coordination and planning what's next in between. We've since found out, and I've been learning by working with other companies, that this six-week thing is not the key point of using the shape of practices. It can be very helpful to work in a longer cycle, but it is absolutely not necessary, and it's not the central point. So here's the thing. The book came out, and quite a few companies started writing me emails and saying, oh, we're doing this, and it's great, and it's describing things that we were always doing. But those companies, they all kind of had the same profile. They were basically the same as Basecamp in these dimensions. They were bootstrapped companies, meaning they didn't have this external pressure. They were kind of setting their own timeline. They had mostly senior people. So the way of kind of interacting and making trade-offs and stuff, this was a bit more natural to them. And they had a higher ratio of designers to technical people. which is quite uncommon in a lot of companies, but they had that. And if they were structured like that, they matched the structure of Basecamp as an org, and they could take what was in the book and boom, just directly apply it. But most companies, especially a lot of larger companies, are not like this. So there's a misfit between a lot of companies that are trying to apply this. They have external pressure, either from different stakeholders or especially companies that are venture-backed. You cannot just kind of say, oh, we're going to do it in the next cycle, six weeks from now, eight weeks from now. In that situation, people say eight weeks is way too long before we can start on the next thing, right? So this wasn't a fit. We saw a lot of companies with junior-senior gaps. And in that situation, The leadership would say, how am I supposed to just kind of trust the team that I'm going to shape something and give it to them and they're going to be autonomous for six weeks? Like, I can't trust my most junior technical people to make the right decisions if I leave them alone for six weeks. So this was a question. And of course, when we have a more typical ratio of designers to engineers, then the question came up of, you know, I cannot embed a designer in every build team for the entire cycle. So how are we going to get to the UX that we want? This is, you would think that because these misfits are so stark, that people would just say, well, you know, ShapeUp isn't for us and we have to be structured like Basecamp to use it. But I kept getting emails and I kept getting LinkedIn messages from people saying, well, we're kind of trying to hack part of ShapeUp and we're trying to use this and that and it's kind of working, but we need some help. And I started to ask myself, like, why do people keep asking to apply this when it kind of doesn't fit for them? And when you look at it, it starts to make sense. What are the alternatives? What are the ways that we are taught to work today? We're basically two kind of options you see on the table. You see an option which is something like Scrum. We just need to get, we need to make better tickets and we have to get better at estimating and we're going to do story points and velocity and whatever. You'll hear this more from the engineering side, but the idea is like, we're going to solve these problems. by delivering better with better tickets or whatever. And of course, tickets are great for dealing with reactive work, work that is not part of a project that you're planning, but when a customer has an issue or a server is on fire or something like that, then tickets are good. But for project planning, many of you probably already realize that this doesn't actually help with the situation. The other thing that we see companies trying to do is they say, well, maybe if we did a longer upfront discovery process, then we'll have more of the answers and we'll be able to give the team everything that they need and they'll be able to just deliver independently and everything will go fine. But what we see in practice is that most of these kind of extensive discovery processes are led by product and designers with no technical people involved. I have not seen any one of the main kind of design sprint or discovery processes where there's a lot of user research, there's a lot of documentation that gets created. But I'm sorry, the honest truth is that all of that documentation, all that time, it goes to the engineering team and they say, we still don't know what to build, right? So it's not helping. So people actually need something. What I understood that needed to happen was to kind of evolve what was in shape up. from being this one true way, which was the perfectly dialed in system that worked for Basecamp, to something which really fits to real life, that fits a variety of companies in real life. So we have this course now, Shaping in Real Life, where we teach the evolved version of this. And what we've done is take it from you have to be doing six-week cycles and this and that, to separate tools and practices. that can be adopted individually, and you can kind of mix and match and say, I don't control our whole company process, but we can use this, and we can use that, and it's going to make a difference. And especially things that can be adapted to the working environment that we're in, so we don't have to be in a company that's just like Basecamp. So what I want to do now is I want to give you a very fast kind of crash course of what is in this, and we'll use the time as well as we can to touch a few key points. So the first key point, is to look at the work that we're doing today. What is it that we actually consider that thing which is ready to go give to technical people to go build? Right? What is it when we think that this is the product that we're going to go make, this is the feature we're going to make, what is that thing that we produce? We all do this thing that we call shaping. That's what it is in some way. And the question is, like, how do we actually get from that initial idea to something that we're going to start building? And we saw these before. So sometimes this is some kind of a brief or requirements document, and it describes all the reasons for doing something, but it doesn't say what to actually go build, right? So this is what we could call undershaped. Then we saw the other extreme, where there's a bunch of detailed drawings and everything like that, but it doesn't actually have... It's like there's so many details, and they're the wrong details, and this is overshaped. Very often we see... these things kind of mix together. It's like if we're doing a renovation of the house and we're going to have a new living room, we see that this over-shaping and under-shaping, they combine. We have a perfect rendering of what exactly we want the new living room to look like. And here's the paint color, and here is the new couch, and there's going to be this lamp on the wall. And we specifically chose the perfect lamp, right? And then the thing is, so on the one hand, we are specifying every little detail. But we didn't ask the important questions, which is, is there actually electricity in that wall or not? And we go and talk to the contractor and they say, oh, we have to make a hole, we have to do this, and now the budget just went twice as high as what we thought it was. So what we're trying to do with well-shaped work, we want work that doesn't bounce back to us because we didn't think of something that was actually central to the problem. Work that doesn't get completely redone or changed at the last moment when it gets to the technical people. And work that doesn't blow up with a bunch of complications we didn't foresee, but instead something that is concrete and technically feasible, and it's tailored to fit the actual constraints of what's going on. Okay, so this concrete and feasible is very important. And in order to get there, we're going to have to think differently about how it is that we shape the work. how we get to something that we can give to builders. So one of the main practices that we use for this are these things that we call a shaping session. And a shaping session is not a meeting. This is a live work session where we're actually doing work, where we are getting into the weeds of what we could build. We're doing the work right there, and the idea is that we're going to cover more ground, and we're going to especially... This isn't brainstorming. It's not like, let's come up with a million ideas and then see what is the best idea. It's, let's cover more ground so we can hit the obstacles and hit the walls and discover those landmines that are going to blow up, that are going to destroy the project later. And we do these in very intense two to three hour sessions. And the key thing here, which is a shift for a lot of folks in product, is who's in the room. We involve a person that we call the technical shaper. The technical shaper is a senior technical person who knows what can really be built, who knows the current system, who knows what is costly and what is cheap to do and what is viable and how the things are all wired together. So in the shaping sessions, we have kind of three roles represented. The product person, the designer, And here design means someone who is mainly thinking about interaction design. What are the steps that the user could go through which would make sense? And this technical shaper which represents the engineering point of view. And here what product contributes in this session is the link to strategy. We in the product management role should know why this project is happening, what we're trying to accomplish with it. what the customer is trying to do, how that relates to the business. And we don't need to have the ultimate understanding of this because honestly, we don't even always have the time or the resources to answer that. But somehow, we're supposed to be making something happen. So we should represent whatever is known about the mandate or the research that we did or the reason why we're trying to do this. So this is what product brings into the session. And this means that we're bridging the gaps between the roles from the very beginning. If we look at what happens inside of a shaping session, a very typical thing here is that the product person will be saying, oh, we have this very good idea for onboarding. We're going to improve conversion by skipping this step here. Right? It sounds easy. We're just going to skip a step. We're going to pre-fill the data from the source we have so we don't have to ask the user. And conversion is going to go up. Right? And here, if it was only product and design, they would be saying, excellent, very good idea. Right? But when the technical shaper is in the room, and this is not after a solution was already solved, This is the first putting together of heads to try and figure out what to do. We don't already have the Figma file and we're trying to de-risk something. You hear this term de-risk very often. No, this is our first getting together. And on day zero, in the first 15 minutes, the first 30 minutes of the conversation, the technical people says, actually, let me take a look. The technical shaper opens up the code. takes a look at the conditions around that part of the onboarding screen and says, there's not one step that we can skip there. There's actually three different conditions that depend on the partners that we're integrating with and where the data sources come from. And then boom, all of this complexity that was two weeks in our future, four weeks in our future, six weeks in our future, just blew up in our faces on day zero. And that's the right time for that stuff to blow up. That's when we want to encounter that information. Because here, before we've committed to the project, before we've written the brief, before we've tried to align everybody on it, this is the time when we can say, oh, that's not going to work, right? What else could we do? What do we understand about what we're trying to accomplish where we could come up with a different approach? This ties very well with this notion of exploring multiple paths. What you see very often is that people latch on to the very first idea that comes up, and then everyone is just about, how do we get that thing done? But inside the shaping sessions, we look at option A, option B, option C. And it's actually by looking at the differences between different options. And again, this is not six months of research. This is three hours in a room. Where we say, oh, what if we did it this way? Oh, what if we did it that way? Oh, but if we do it that way, we don't get this. Is that really important? Uh-huh. Why is it important? Because this. Uh-huh. Oh, what if we did this? So looking at contrasting different possibilities. The other thing that we do is what we call spikes. So a spike is when we are at a certain level of a conversation. We think that we can plug in the data from our partner instead of asking the user. And then someone says, can we really do that? They say, well, of course we can plug in data. We have the data. We have programmers. We can do it, right? Or you say, well, how do we know that the client validation is going to still work? Or how do we know that the data format is going to match? Or that the API works the way that we think it does? And sometimes we can answer the question right on the spot. But other times we have to actually dig deeper and say, you know what? Let's break. Let's have somebody look into that as a tiny unit of work for an hour. And then we'll come back to the session when we have clearer information. It's like if you're doing a renovation on the bathroom and you talk to the plumber and it's a very old building and the plumber doesn't just give you a price estimate. The plumber says, I need to look behind the wall to see how old those pipes really are. You have to do a little bit of digging into the hard facts of what is there today. So this is where we're looking at some different paths in the shaping session. We have a few parts that we think are going to fit together as a viable approach, and we say, ah, but this could destroy the project, right? This is something that could blow it up. This could be a danger. This needs to be understood better. So we create small work assignments to answer those things. And very important, we don't ask yes or no questions. Because if we say, is it possible? And someone says, sure. Or we say, is it possible? And they say, oh, this is such legacy code. No way. But what we really need to know is what would it take? How is it possible? What is the cost? What's involved? After we've done the spiking and we're more clear on, we've basically filled in the missing knowledge about what is really possible and viable at different parts of our solution approach, then we can also get to a point where we're starting to narrow down. Is it really path A or path B? We can make trade-offs. Very often, we avoid making trade-offs when we are coming up with a project. There's a trade-off, for example, we have a lot of different things we want to ask the user because we want to have that data about them. But on the other hand, if we don't ask them, then conversion will be higher because they'll move through the process, right? And then sometimes people will say, well, we'll make it a preference if you can add these questions or not add those questions. And then the scope just keeps getting bigger and bigger. So making these trade-offs is really important. I'm going to keep moving because of time. The last thing that we should do is we actually package everything that we learned. into one document that we can give the team that includes not only why we're doing this and what the outcome is, but specifically here is the technical approach of how the hip bone connects to the leg bone. There's a real architectural approach here that we have worked through with technical people and not at a superficial level. We have gone deep and we know that this is actually going to be possible. So this is where we've packaged everything, and when we've really done the deeper digging, then it means that those unexpected issues are not going to be blowing up later because the team really had what they needed in order to work autonomously. So before, we had all this wasted time that happened because we were waiting too late. to connect with the realities of what is really buildable and what is the specific approach. But when we have the shaping sessions and we use the different practices, which I could barely touch on, but I just touched a little bit on the practices inside of the shaping sessions, then what happens there is we are getting into those real hard questions that are going to arise later, and we are kind of diffusing those time bombs. And it means that when the team is inside of a build cycle, they can be humming along and they can be productive. And we don't have this queue of people who are blocked and unanswered questions, and we are running around trying to make sure that the project still keeps going. But instead, they have what they need, there are clear boundaries, there's a viable approach, and the team is able to just keep moving forward. Which means, by the way, that we then, this is the beginning of us as product managers, starting to carve out our own time, right? Because the more that the team can work productively on something meaningful without needing their questions answered, then while they're building, this time starts to appear where we say, aha, I can actually think about the next thing. I can do that little bit of research I wanted to do, or I can look at that data that I wanted to look at, or I can have those conversations across different parts of the company that I didn't have time for before. A lot of times when people think that they're shaping, they're actually not. And I want to give you another piece of language that can be helpful to describe some different work that all of us are doing in some form. And this is where we talk about shaping versus framing. So when shaping was figuring out what to actually build, what to actually make, framing is more the question about what is the meaningful thing to build, what is the problem that we're solving, how do I make the case to do it? So we talked before about very often we see these briefs that only make the case to do something, and they describe the background and the reasons why we should do it. And they maybe have requirements in the sense of customer outcomes, but they don't actually tell us what to build. And this is valuable. We have to go through some process of figuring out what should happen in terms of the customer outcome or the business outcome, but it's not shaped. It's not telling us what to do. It's not telling the engineers. This is the direction of what we're actually going to go build now. So framing is different work than shaping. Framing is that work when we are figuring out what is really the problem? What is the outcome we're trying to get to? How do we make the case that this is the thing to spend time on instead of something else? Why is this the thing that we're going to start building instead of all those other things? And then shaping is where we go further from we not only have a problem and an outcome and a budget, but... What are we actually going to do? How does the solution actually fit together so it's technically viable and it's going to be deliverable on time and at quality? This is not only different work that happens at different times integrating different people. Time is moving here. But I'll just mention shortly. If we want to go deeper into framing, let me say it this way, these are different ways that we can add value depending on kind of what is attractive to the way that our brain works. If we want to go deeper into shaping, it means getting more technical. It means coming closer to the technical people. Shaping is more about the system. It's more about the technology. It's more about how the parts fit together. It's more about the cost of individual parts and their interfaces. And it's about how do we get the outcome at the right cost. If we don't feel very comfortable in that technical side, then we can focus more of our energy on the business side. The framing side is more about how does the business make money? What are customers trying to do? If we do this thing, how is it going to reduce churn? Or how is it going to bring in new customers? So it's more about understanding customer behavior in the business and implementing strategy. So what I hope you take away from this is the very, very first little glimpse at a virtuous circle, that we don't start by doing a million new things that we don't already do today, that we already don't have time for, but instead, if we can shape a little bit better by bringing the technical people earlier and making trade-offs about what's really possible at what cost earlier in the project, then we will find that we have fewer blocks and issues coming up in the cycle. And even if we just have 10% fewer interruptions and unexpected complications, that's 10% more me time, our personal time, to figure out how we can grow and what it is that we're going to get better at or how we can contribute more to the organization. And this is especially important as we come into this environment where everything is getting tighter and we are coming back to normal. where it's not about growth at all costs, but it's about actual profitability. It means that we're going to need to kind of figure out the ways that we can get better at these different things, because it's on the framing side of understanding the business better, and it's on the shaping side of being able to deliver on time and at quality. Those are the places where we're really going to be seen adding value to the org, and where we're going to also discover that we have more and more options in our career going forward. So I wanted to give you the ability to kind of see this. to understand that ShapeUp is not about six-week cycles, it's more about actually how we come up with what is the work that we're going to do and how this impacts the time that we spend and the ways that we can grow going forward. We can talk on the side at the speaker's point or the meeting point about some other things that I ran out of time for that, like I said, cycles don't have to be six weeks long. The way that we package the work, there's not one template. It's not that you have to make a fat marker sketch instead of Figma. It's a question of what does the team need to be unblocked and how much latitude do they need to make creative decisions. And we can also talk about if you're not doing Figma up front, how to do much more of that as an interior design phase that comes much later in the project. We have some amazing successes with companies moving the Figma file to the far end of the project, just like you In an architectural project, you have to figure out where do the walls stand and where do the pipes go and where do the electricity wires go. But you're not choosing the tile or the paint color on the beginning of a project. This happens at the end of a project, right? So there's actually some very interesting possibilities there, but we can talk on the side. So I hope I kind of exposed you to a few things that might be interesting that might provoke some questions for you. And here are some next steps for you. If you're interested in the book and you haven't had a look, you can see the original book. It's ShapeUp. It's free online. Shaping in a Nutshell is a 20-minute video that gives you an overview of the main concept so you don't have to read the whole book to get the key ideas. And then Shaping in Real Life is our new online course. It's a two-week course where you learn all these individual practices and the language so that you can start finding ways forward to get the team in a place where you're using your time better and making more progress on the things that matter. And you can find out all about that on the website. And I would love to also connect with you and hear from you on LinkedIn. So please get in touch. Let's please talk at the speaker point. And I'll also be at a fireside chat with Melissa and Sebastian, hosted by Oxlil later in the afternoon. So we'd be very happy to talk more and meet you all. And thank you for your attention.

Ryan Singer, founder @Felt Presence and author of “Shape Up”, tells us how and why the Shape Up methodology took shape within the Basecamp company. Throughout this talk, he explains the advantages of this method to quickly developed meaningful products. He highlights the importance of identifying on the early stage of our project the blocks and issues that may surface during the cycles, by involving the 3 roles of product : Product, Design and Engineering.

00:00 Intro
01:58 Why Shape Up methodology was created ?
15:17 Does the Shape Up methodology match with your company ? 
20:18 Crash course on well-shaping process
32:57 Shaping vs. Framing

📗 Product Management in 14 rules! Build the right product and build it right. Download our book Agile Product Management: https://www.thiga.co/fr/livre-product-management


🎤 What's La Product Conf ? : https://www.laproductconf.com/
💻 What's Thiga ? : https://www.thiga.co/en/
📰 Discover our média : https://www.media.thiga.co/
🎓 Thiga Academy trainings : https://www.academy.thiga.co/en/


🔵 Follow us on Linkedin : https://www.linkedin.com/company/la-product-conference/

#productmanagement #productmanager #shapeup #organisationproduit #LPC2023 #LaProductConf