Study Along: Shape Up by Ryan Singer | Product Development (Part 2)

uh there's a team uh in base camp basically base camp is a a company which is following this strategy for the past 10 years i guess and now finally ryan singer ryan singer how do we call his name so he has written this book shape up and which is uh quite famous now and many companies are trying to adopt it so yeah last time we saw that how it is different from the normal way we do it So we saw that you first shape an idea and then you build it. And here, while shaping an idea, the main difference is that you do not say how much time will this thing take to make. Rather, you say how much time are you willing to spend on this feature. So that is the difference. Let us begin. There are three stages, I guess, which the book told us that there's shaping, there's betting, and there's building. So what we were was, we understood how the shaping process goes. Inside shaping also, we saw that there are four rough steps. First step is defining the boundary. You find out your appetite. you first have a raw idea using that you find out your appetite how much do you actually want to spend on this and then you make out a rough solution so ryan suggested us two ways to do it one was the breadboarding technique where you just write down the base just write it down the basic flows the page where you are the different elements that in that page would be the different actions and what the different actions would do and and where where where all of this fits in in the existing product and also ran suggested us to maybe use fat marker sketch wherever some visual solution is required we can use that so that was about roughing out the elements then the third part is risks and rabbit holes where we left off last time and after you understand the risks and the biggest uncertainties in this solution you then write a formal pitch and that goes to the betting table and from there whatever ideas get picked up pitches get picked up those are sent into the building process okay so that was the quick recap and we left off last time here in risks and rabbit holes so we are inside shaping up we have understood roughly what setting boundaries and roughing out the solutions is Now let's go into the third step. Let me quickly check my YouTube. Is this working at all? Yes, yes, yes, guys. We are live and everything seems to be working fine. So let's go ahead and continue reading this amazing book. Just a disclaimer here, guys. This is not a summary or a useful gist. This is just the first raw reading of the book. So it would be... it might be boring for you just letting you know okay so risks and rabbit holes remember that we are shaping work for a fixed time window yeah so we know that we have fixed the time window and we don't have estimates anymore we have appetite can we make it in this much time we may trust our experience that the elements we fleshed out in the previous chapter will develop within the appetite but we need to look closer because all of it All it takes is one hole in the concept to derail it. Correct. If there is an anticipated problem, then you suddenly burn out a large portion of your time budget. This often happens, guys. Any developer would know that you give an estimate, but you always hit some unexpected blockers where you just spend all your time. Sometimes you have a problem that don't just delay the project. There's no apparent solution. Correct. So there are blockers. which you discover very late in the project these have to be avoided as much as possible we assume the designer will figure it out we didn't do the work in shaping phase to validate that a viable approach existed once the project has started it turned out to a much harder problem none of us were able to find a suitable design solution we intended abandoning the project and rethinking it later so all this thinking if it can be done in the initial phase itself which is the rabbit holes part where you find out the rabbit holes That would be better. Of course, there will always be unknowns. That's why we apply the many practices in part three. Okay, we'll see that as well. Laying out room for the unexpected. But that doesn't mean we shouldn't look for pitfall. We can eliminate them as early as possible in the project. Okay, so different kinds of risks. Okay, let's look at those. In terms of risks, well-shaped work looks like a thin-tailed probability distribution. Okay. There is a slight chance it could take an extra week, but beyond that, the elements of the solution are defined enough and familiar enough that there's no reason it should drag on longer than that. Okay. Okay. However, if there are many, any rabbit holes in the shaping, technical unknowns, unsolved design problems, the project could take multiple times. Correct. The right tail stretches out. Okay. So basically you are, charting out the probability curve of how much time it would take so this is the classic estimation where generally you give a time range it would take four to six weeks here we are seeing it in greater detail so what we want to do is we want to remove the knowns and tricky problems from the project so that our probabilities as thin-tailed yeah the tail right here it cannot be as thick it has to be as close to zero as possible That means a project with independent, well-understood parts that assemble together in known ways. Okay. Okay. Understood. So fleshing out the elements of the solution was a fast-moving exploratory process. It was more breadth than depth. Correct. We were trying to understand exactly where the flow would start, what all elements would be present, and how would it... uh move forward and how will this whole thing integrate with our existing product so yeah it was a very fast moving uh process where your initial design like for example the dot calendar example your initial design may be that the person clicks on his profile and then on a calendar and then you have the whole process and then after doing it after exploring it you understand that why not just integrate with his actions or with his meetings directly where you can click and just expand so while while the bread in the breadboarding phase you may come up with rapid transformations that is why it has to be bred first but that is well and good now i guess what ran is telling us is that we need to slow down and look critically did we miss anything did we make any technical assumptions okay So one way to analyze the solution is to walk through a use case in slow motion. How exactly would a user go from start to end? OK. OK. Then we should always question the viability of each part. Does this require new technical work that we have never done before? Yes, this is very crucial. A technical work which has not been done before is a rabbit hole for sure. Are we making assumptions about how the parts fit together? Correct. It might be possible that one data point, which you're assuming would be available on another page, might not be there at all. Or accessing that data from another page might require you to write some interfaces or some API calls, which might again need a lot of time. You never know. Are we assuming a design solution exists that we couldn't come up with ourselves? Okay. is there a we are just guessing already but maybe it's not there maybe it's not shaped up maybe there were issues found out later on and you don't know maybe you're using another team's let's say payments teams api and you knew that three months ago there was a launch it was looking fine we'll easily integrate that i had read the prd and the solution that time it might happen that there were some big issues later on and it might not be in the right shape right now so you need to find all those out case study patching a hole okay so we have defined the to do groups project now we introduce the idea of dividers in the to-do list okay we like the idea of dividers and the logic of loose versus grouped to do made make sense to us lose this i guess rough to do what is it but when we look closer we realize that we didn't address how to display completed items in the pre-existing design okay So this is a to-do project where you are just writing down what all things do we have to do. And then you can easily take whatever you have done. But then we don't have a design to show what all has already been completed. OK. In the earlier design, the completed list were displayed, completed items were displayed at the bottom. OK. So now should we render complete items below each group or at the very end? Okay. Or should we handle it completely differently? Okay. So this was a hole in the concept. If we didn't address it, we'd be pushing a deep design problem down to the team and unreasonably asking them to find a solution under deadline. Okay. So this is an example of a hole where there is an obvious requirement and you haven't thought it through in your current solution. Hmm. so we knew from our experience that changing the way completed to do's render has a lot of complicated implications in ux okay navigation performance okay to remove uncertainty in the project we dedicated decided to dedicate a solution in the saved concept we would leave the complete exactly as they worked previously instead of grouping or segmenting them we would just append the name of the group to each completed item it would be a little messy but we justified the trade-off it just typically simplified the problem and you still show complete items from a group on the group's detail page okay okay this is a simplified solution this is the kind of trade-off that's difficult to make when you're working inside the cycle under pressure there are lots of reasons why a different design order would be objectively better yeah this is not the best design possible but this might be uh good enough to be shipped in the time the appetite you have for this solution as well as good enough to solve the main pain point that the user has some designers might be unhappy but yeah that's how things should work in my opinion as well so there are a lot of deeper reasons why a different design or deeper reconsideration of completed would be objectively better why not try rendering them inside each group a designer could reasonably think maybe if i experiment with the styling a little more i can make them blend in better they could easily waste a few days or a few weeks going down at that end as shaper we are thinking less about the ultimate design and more about basic quality and risk okay so in the shaping up process you are talking about the basic quality uh the performance should be decent enough the ux should be good enough the main pain point should be solved and you have to understand the risks so involved in just multiplying the appetite uh by three times or four times with the compromised concept we get to keep all the elements that made the project worth doing and we get to cut off a big tail of risk Yes, you minimize risk. Next, when we write the pitch for display, we'll point out this specific patch as part of the concept. That way, nobody down the line will get tripped up on it. Okay. Declare out of bounds. Since everyone on the team wants to do their best work, they will, of course, look for all the use cases to cover and consider them necessary. As the team gets more comfortable with scope hammering, this improves, but it's still a good idea to call out any cases you specifically aren't supporting to keep the project well in appetite. Okay, so Ran is saying that in general, the team themselves would start cutting off scope that is not important to the core idea of the feature. But still, even during the shape of process, we might declare some things as out of bounds. Let's not touch these things. For example, we worked on an idea for notifying groups of people in Basecamp. Rather than checking of five programmers one by one, you could just click programmers, and they'd be selected for notification. Select all. As we looked at the product, we saw tons of places where this kind of behavior might make sense. If we let you choose a group when posting a message, why not? when assigning a to-do or mentioning people in the chat room we decided for the purpose of the project that the core value was narrowing down who to notify about a message basically marked off other cases as out of bounds okay so so there must be focus to the specific pitch this pitch is about a specific feature that you want to build and you have to stick to that even if you you don't go after wild ideas cut back so there may be so i'll just let me just note it down we are talking about rabbit holes okay we are talking about rabbit holes so we have to look for so let's just recap this let's just try to recap without reading so we are talking about risks and rabbit holes okay so we have to look out for holes okay holes would mean uh other pieces of uh other pieces of apis or pages that this space interacts with not to make assumptions about them uh not to make assumptions about our technical capabilities uh look carefully at some new technical work that is that has not been done before and don't make assumption about design considerations what was it what it don't assume that design solution exists and the last last part was if there is a hard decision a hard trade-off then let's make it right now okay so we saw example of patching a hole you identify a hole and then patch the hole and you add this patch also in your pitch so that everybody is aware okay so we looked at the Example, then it says out of bounds. Okay, out of bounds is important. And what was the next point? Okay, let's see what this is. There may be parts of the solution we got excited about during the sketching phase, but that aren't really necessary. So when we designed, we thought it would be great to color code the different groups. No doubt the page would look more interesting with color coded labels. The feature might be more useful too, but we had to flag this as unnecessary. Cut out everything that is unnecessary and just provide the value that the user seeks. We could mention it to the team as a nice to have. But this is OK. OK. So maybe you also label out some things as nice to have. OK. Up to this point, the shaping has been a closed-door activity. Before you are ready to write up the idea to share more widely, you might need input on some parts of the concept you aren't completely sure about there may be a technical assumption that you need to verify with someone who understands the code better or perhaps you want to make sure that the usage data doesn't contradict our assumption you're making about the current customer behavior so sometimes in a piece of a problem where you want to allow the user to let's say let's say add an event and also to let's say see his calendar okay so the the you it might be natural to you that or you might assume that you first show the calendar always whenever he or she clicks on the calendar and then you allow them to add an event but if if your first specific use case the data tells you that what they generally do always do is add a calendar and only sometimes look at the overall picture then maybe You have that beforehand. You directly have the ad calendar beforehand and have the whole view deeper down the UX. Okay. Tell that this is just an idea. Okay. We are just shaping up a potential bet. Not something that's coming down the pipe yet. Okay. The mood is friendly, conspiratorial. What is this? What does this mean? I don't know. Generally, Mac. My laptop starts telling me about definitions of words when I don't want them. Okay. Okay, fine. Does not work. Okay. Here's something I am thinking about. I'm not ready to show anybody yet. What do you think? Okay, okay. So you are saying, I am showing this only to you. Beware the simple question. Is this possible? In software, everything is possible, but nothing is free. Don't ask, is this possible? we want to find out if it is possible within the appetite we are shaping for instead of asking is it possible to do x is it possible to do in six weeks talk through the constraints of how this is a good solution given the appetite so they are partners in keeping the project at the size you intend and emphasize that you are looking for risks that could blow up the project it's it's not just a what do you think conversation we are really hunting for time bombs that might blow up the project Okay. Try to keep the clay away. Rather than writing up a document or creating a slideshow, invite them to a whiteboard and redraw the elements as you worked them out earlier. Building up the concept from beginning. Stick completely to the concept you already worked out to get feedback on the work you have already done. Then once you have covered the work you already did, open it up and invite them to suggest revisions. Having seen this concept, do they have any insights about how to drastically simplify or approach the problem differently? Okay, so you may have either validated your approach or discovered some new problems that send you back to the round of shipping. Okay, so this is very critical. So once you have shaped up the idea to some level, before you write the pitch, there is going to be iterations where you discuss it with the technical team, maybe with your analyst team, etc, etc. And based on their feedback, you may have to repeat the process again another important thing which i found was uh you don't show them uh the bread the design that you made you make the rough solution again from scratch so that that that is a great suggestion i indeed okay so after we have looked at the risks and rabbit holes are we done de-risked and ready to write up at the end of this stage we have the elements of the solution we have the patches for potential rabbit holes and fences around out of bounds okay so we have a roughly framed solution with potential risks so that we are willing to bet our future on so we are going to make transition from privately shaping and getting feedback from inner circle to presenting to the broader team in the betting table So you write it up in a form that communicates the boundaries, spells out the solution, so that people with less context will be able to understand and evaluate it. This pitch will be the document that we use to lobby for resources. Collect wider feedback if necessary, or simply capture the idea for when the time is more ripe in the future. So we have the solution. Also, you understand the risks. Now we are ready to write the pitch. So we have de-risked our concept. So we have a rough solution and then we de-risk the solution. But the concept is still in our heads or in some hard to decipher drawings on whiteboards or notebooks. Now we need to put it in a form where other people are able to understand, digest and respond to it. This is where we say, OK, this is a ready to write. this is ready to write up as a pitch so we'll walk through the ingredients of a pitch and show some fully worked out examples okay the purpose of the pitch is to present a potentially good bet so it's basically a presentation okay so let us look at the ingredients so there are five ingredients that we should include in a pitch okay the problem the raw idea the use case okay the business requirement the appetite by the way guys is a user problem and a business requirement the same thing i guess they are one in the same appetite how much time we want to spend and how that constrains the solution okay i understand the first part but we also in appetite we also need to tell that because of this appetite okay it it's in each uh it starts to constrain the solution that we can provide to this problem maybe we do not cover the whole problem maybe because of this appetite we cover only one part of the problem okay then the solution then the rabbit holes okay and then the no goes okay so this is part of the different things that so what makes a pitch okay we have the problem the appetite the solution the rabbit hole, and the no goal. Okay, cool. So first we have the problem. It's critical to always present both a problem and a solution together. It sounds like obvious point. How often teams jump to a solution with the assumption that's obvious why it's a good idea to build this thing. Never present just the solution. It should always start with the problem. diving straight into what to build is dangerous correct you don't establish any basis for discussing whether this solution is good or bad without a problem add tabs to the ipad app might be attractive to ui designers but what's to prevent the discussion from devolving into long debate about different ui approaches so without a specific problem of the user there is no evaluation metric on what to build and what is important and what is the real flow that we need to create here. So once we have the problem, then the discussion is easier and reaching to a good solution is also easier. OK, we want to be able to separate out the discussion about the demand. So we could spend six weeks on an ingenious solution that only benefits a small percentage of customers known to have the retention. So you want to be able to separate out that discussion of the demand so we don't spend time on a good solution that doesn't benefit the right people. So how far you have to go to spell out the problem will depend on how much context you share with the people reading the write-up. OK, the best problem definition consists of a single specific story that shows why the status quo doesn't work, what the current problem is, what the current user behavior is, and why it needs to change. this gives you a baseline to test the fitness against people will be able to weigh the solution against this specific problem so we need a user story or other solutions if a debate ensues and judge whether or not the story has a better better outcome with the new solution swapped in so that a specific user story that for example he always gets a call or always gets an email and immediately opens the app to uh add entry so but there they always face difficulty let's say in searching the person so this is a problem and when you have a solution that immediately how it solves that particular problem uh so it helps a lot in getting to the solution second ingredient is appetite okay so um we know what appetite is how much time are you betting on this solution how much time is the company the team willing to spend on solving this problem given the impact the scale the urgency of the problem stating the appetite in the pitch prevents unproductive conversation there is always a better solution the question is if we only care enough if we only care enough that is important we care differently about different parts and we want to build things that we care a lot about that the user cares a lot about and not just build incremental stuff okay solution like solutions with no problems sometimes companies bet on problems with no solution yeah we as a company your goal is to solve problems in the world solving ideas in your head is wrong and again going after problems that cannot be solved uh is is not the need of the let researchers do a deal with that our goal is to fit the solutions with existing problems a problem without a solution is unshaped work okay giving it to teams means pushing research and exploration down to the wrong level So if the solution isn't there, someone should go back and do the shaping work on the shaping track. Help them see it. So in the solution, help them see. During the elements phase, it was critical to sketch ideas at the right level of abstraction. So we don't slow down. We also need to draw at the right level of detail when we write the pitch. Here, the challenge is a little different. We have time to slow down and prepare a proper presentation. so we need to stay high level but at a little more concreteness okay than when we work together with our partners people who read the pitch and look at the drawings without much context need to get it so we need more concreteness how do we but we don't want to over specify with wireframes okay they'll box in the day they'll box in the designers who do the work later we'll also we all guys just give me a second i have a call coming in so they'll box in the designers yeah so we don't want to box in the designers we still want to give so design name is part of this building process it's not just part of the shape of process in many teams even in our teams The design used to stop before the building process started. So it was design and design completion was when you picked up tasks from your backlog. Here we are seeing, we also reached site tracking topics like color, presentation, layout that had nothing to do with the actual shaping work we did. At the same time, handwritten breadboards, you had to be there. yeah okay people who don't watch the breadboard unfold step by step it's very difficult so therefore we need some techniques to see okay embedded sketches suppose your breadboard look like this okay so the breadboard was a dashboard where you have a same formally change from setting go to form in the form you fill the form you get a thank you okay people might have trouble visualizing Where these new affordances go on the dashboard, we could sketch a new box on the dashboard to make it clear Payment form preview and links go here But we are still asking to imagine too much It's worth the trade-off to go one step down into fat marker detail Payment form, send the link to customer, change your form settings, go to your form This makes it easier to see what the elements are and evaluate how clearly the features presents itself on the dashboard the downside is we have got into some layout decisions that would have been nice to avoid designers should feel free to find different design than the box divided with the vertical line we'd add a disclaimer here in the piece that reminds designer of the latitude they should take getting into more visual detail because we need to sell the concept to sell anything you need to show it Fortunately, we don't need to make as many visual decisions in other parts of the concept. Okay. So maybe you don't need to show visual stuff in all parts of the concept. This was a linchpin part of the design. Everybody had to see in order to get it. Yeah, you have to get it what this feature is, where it would it be, where it would start. And maybe you need not show it visually for the rest of the stuff. Annotated fat marker sketches. Sometimes ideas are inherently visual. Okay. So here we would that market says can be very effective. You just need to make that clean. Redrawing the sketch of an iPad still with the fad brush size works well. You can use different colors to separate the labels. Okay. Or you might add some call outs to any more discussion so you can create a divider in two ways. Okay. Okay. In green. So. So we listed out the problem, the appetite. Then we listed out the solution. In the solution, we want to give them more visual feedback. It has to be cleaner so that people get it. Then you let the team know what the different rabbit holes could be. Okay, for example, URLs would never line up custom domains. This is the kind of thing. It's not central, but it can be a rabbit hole. Okay. If there are no-go, then you tell it to the team. So let's look at a few examples. This pitch for grouping to-dos together starts by showing a workaround people are using in the current design. Then it sketches out all the main ideas for how to enable optional to-do groupings. But where is the problem and where is the appetite? I see the solution directly. Let us try to read it. Let us try to read it. I should not have done that. For 13 years we have done stuff like this. So the workaround is that you are intentionally adding to-do entries which are actually acting as your labels for the different batches. I get it. Another way people do it is you create just the label here and then you write stuff beneath it. so what we are trying to do is create is it visible yeah it is visible let's zoom in a bit more can we zoom in a bit more yes we can okay so what we are trying to do is create a simple groups of to-dos within a single list so we are hacking so we are hacking it so we are either getting artificial dividers or pre-pending a batch of to-dos with the label qa or old standby the trustee which is code for maybe yeah it works but it's messy and it's not refining pattern to share with customers 13 years in its time to level up but shouldn't there be a user story like but yeah people actually doing this it means that you just have this problem and they are altering their behavior hacking the solution to achieve what they want to do why not give them a simpler solution so to do groups so i think now we have defined the problem so we should come to appetite and solution a couple of weeks ago ryan and i spent an afternoon working out an idea to make to do groups first class citizens without adding neutral complexity the purity of today's solution we are pleased with where we've landed like to put it forward as a big batch project this cycle here's how it works so okay so i think when you say a big batch project this cycle there itself you're saying that this the appetite is six weeks first to-dos without groups will look identical to today's to-dos we won't add any additional ui no new buttons etc okay now here here here here but if you add if you add group or groups it will look like this okay so there is a name listing and then you have You have groups. Within each group, this is the overall list name. Then you have some loose entries, which are basically ungrouped to-dos. And then you have grouped to-dos, where you have a group name. And maybe you can add an entry within each group. This means now you could make a list for a specific scope that had a section for design specific to-dos, the QA specific to-dos, etc. A group is defined by a divider. You can name a divider. anything you want it can't be checked off it's not a to-do list itself any to-dos you put below the divider becomes a part of that group and critically groups always go below any loose to-dos this simplifies a bunch of behaviors and prevents loose to-dos from being lost between groups if it's loose it's at the top you can get divided in two ways okay one divider is like a document with a name the other one is just a hyphen with a line Oops, sorry, my mistake. In the first one, click the hamburger menu. In the first way, you click on the hamburger menu next to the list title. You'll get a menu. One of the items would be create a group. You'll then add a blank divider at the end of the list to do. Then scroll right to the point. You can name it. Our second option is you can multi-select multiple loose to-dos and instantly create a new group. If you do this, an unnamed divider will be created and the to-dos will be placed under that divider. Key to this concept is that we will add a to-do button at the bottom of each group and the loose to-dos at the top. Okay. Okay. Got it. Got it. Got it. Got it. Completed to-dos will be grouped in a single collection at the bottom. Okay, completed to-dos will come in the end. If you uncheck a completed to-do, it could go back up. Okay, this also has been listed down. The solution has been defined out quite well. Quite well. What we like about this concept overall is that it's very straightforward. It doesn't change existing at all. No new permanent UI. No behavior changes. If you don't use groups. Okay, but if you want to level up. would use the shit out of this then you can add groups to a list no groups within groups no indenting just as many one level groups that you like there are open questions things like if you move the divider do all the items move with it i'd say yes since it's a group but we have to work that out also since you can't put groups above to do's lose to lose we'll have to prevent dragging above certain point but that's doable as well i'm sure there are a few questions but you can work those out as you go down the road we'd like to explore adding to do templates to dc3 okay okay okay so we got the rough idea there two screenshots demonstrate the problem fat marker describe the solution so the initial two screenshots actually demonstrated the problem and then fat marker stretches describe the solution uh rabbit holes motivated some of the sketches okay cool now the second pitch let's not go in detail in this pitch and we'll just look at it overall okay so this pitch was about you know how notifications work with a few videos the black box is worth the end or visualization of you that support a decision in the pitch so the pitch is backed by user behavior backed by user data as well so let's zoom in again why did we zoom out okay so last November this guy wrote a pitch after looking at the pitch so how did this come out wanted to take last swing at it narrowing down a problem case perspective she told me so it's telling a story like how the problem started how did you identify it who told you what then you went to this guy we are telling who were the people involved in shaping up this solution so i guess that is also important okay okay so i guess the same one choosing so we are discussing the problems here with proper visualization okay Let's just glance to this. This is again a fat marker sketch, which is quite neat. Then do events get a different solution? I think now we are discussing the rabbit holes. Rabbit holes take a lot of time, you see, not just the initial solution is important, but these are also very important. Then you look at data, and so there are additional explanations why this problem is important and exactly how should we solve it. What we are not doing. so this is no goal this goes a step further narrow than the last pitch no auto completing groups anywhere still no connection with teams just a better way to narrow down subscribers okay okay so it's created around what these guys are not doing okay so now you we have the pitch we know all the ingredients in a pitch and we are ready to present uh it can happen in a couple of days so we want to make this uh Kesaril describes a bet worth making. So we prefer asynchronous communication by default and escalate to real-time only when necessary. Okay, so the first step of presenting a pitch is posting the write-up with all the ingredients above somewhere that stakeholders can read it on their own time. Okay, so this in ideal conditions everyone has time to read the pitches in advance and if that isn't possible the pitch is ready to pull up for a quick lifestyle okay so why do we prefer asynchronous communication is because it gives everyone that their own time to think about it people have different frequencies in this thing so here they basically post pitches in base camp under pitch and okay people just pick it up a pitch as a message okay when we need to include a fat marker sketch we'll draw an ipad take a screenshot it's pitching his company here so people comment on the picture just like your prd you write the prd and then people can look at it people can comment on it comment on it okay so now we have completed the shaping up part let's go into betting process Let's go into betting process. We have a few black screens, part two betting. Great, great, great. Guys, is everything all right? Are we zoomed in too much? Are we zoomed in too much? No, no, we are doing fine. We are 47 minutes into the recording. We'll try to cover as much as possible. And then we'll stop in another 12 minutes, I guess. Okay, okay, okay. Yeah, I've had this feeling before, which this sketch is having, this guy is having right now. When you look at your scrum board, the Kanban board, and you have so many backlogs, so it's crazy. So we have bets, we don't have backlogs. So no backlogs. Backlogs are a weight which we don't need to carry. Hundreds of tasks pile up, and the growing pile makes us feel like... tired okay backlogs are big time wasters they constantly reviewing grooming organizing so they waste time find a few potential bets before each six week cycle we hold a betting table where stakeholders decide what to do in the next cycle okay so at the betting table they look at pitches from the last six weeks or any pitches that somebody purpose purposefully revived and lobbied for again nothing else is on the table there is no giant list of ideas there is no time spent so right now the stakeholders people involved in the shaping of process all people right now what they feel is important only those things come and not what someone felt was important 12 months ago okay there are just a few well-shaped ideas risk reduced options to review okay these pitches are potential bets with just a few options these meetings are infrequent short and intensely intensely productive so right now i'm not able to visualize what will happen in the between on the betting table so hopefully when we read it read on we'll get to know if we decide to bet on a pitch it goes into the next cycle to build if we don't we let it go okay what if the pitch was great So if anyone wants to advocate for it again, simply tracks it independently and then lobbies it again. Decentralized list. We don't have to choose between a burdensome backlog and not remembering anything from the past. Everyone can still track pitches, bugs, requests they want to do independently without a central backlog. Support can keep a list of requests or issues that come up more often than others. Product tracks, ideas. product tracks ideas they hope to be able to shape in the future programmers maintain list of bugs they'd like to fix when they have some time okay so there is no one central list and product people have the list of ideas they want to do we have a list of bugs we have a list of requests and the right people have those lists independently in their own system or in their mind I hope they have some system for that okay and we also need regular one-on-ones between departments to cross coordinate ideas on what to do support guy can help germinate an idea in a product guy's mind a product guy can remind an engineer of a critical bug that's still there for a long time so people from different departments can advocate what they think is important this way the conversation is always fresh okay anything is relevant timely and for the moment It's easy to overvalue idea. The truth is, ideas are cheap. They come all the time when you create into big files. Really important ideas will come back to you. Important ideas will come back. Don't worry about losing ideas. Won't that take longer than six weeks? Okay, the betting table. Now we are at the betting table, guys. I am excited. Now that we have some good potential bets, it's time to make decisions about which projects to schedule. Okay, six-week cycles. committing time and people is difficult if you can't easily determine who's available and for how long when people are available at different times due to overlapping projects project planning turns into a frustrating game of tender tetris correct one person is waiting for the other person the other person waiting for the third person that person comes back this person falls ill it can become a nightmare a cycle gives a standard project size both for shaping as the list scheduling the scheduling component is all so important here Okay. Some companies use two-week cycles called sprints. We learned that two weeks is too short to get anything meaningful done. Maybe in the context of what Basecamp does, for some teams, which are pre-teamers, which are building very early products, it might make sense to have two-week cycles. Two-week cycles are extremely costly due to planning overhead. That is correct. That's correct. The amount of work you get out of two weeks isn't worth the collective hours spent around planning. And then you are breaking everyone's momentum. This led us to try longer cycles. So Ryan is recommending us to go for longer cycles. And after years of experimentation, guys at base camp have drilled down to about six weeks. So at the end of every cycle, there's a cool down period. After each, we scheduled two weeks for cool down. This is a period which no scheduled work. so you can breed meet as needed and consider what to do next programmers and designers are free to work on whatever they want after you have to ship something they enjoy their time under their control and they use it too so no one is allocating work allocating meetings allocating their time they are free they are they are in control of their time team and project sizes in addition to standardizing the length of our cycles we also roughly send us a type of projects and teams that we bet on our project teams consist of either one designer and two programmers or one designer one programmer so one and one or one and two they're joined by a qa person who does intuition testing later in the cycle these teams will teams will either spend the entire cycle working on one project or they'll work on multiple smaller projects we call the team that spends the cycle doing one project the big batch and thus Team doing multiple smaller projects, the small batch. So the small batches aren't scheduled unusually. You just have to work on them together. So now we have a standard way of thinking about capacity. The betting table. The betting table is a meeting held during cool down where stakeholders decide what to do in the next cycle. The potential bets to consider are either new pitches or revived. earlier pitches so just a few options to consider at basecamp they had the ceo cto a senior programmer and a product strategist okay that's all what about what about the team what about the team the programmer and the designer where are they c c level time is only available in small slices so there is no atmosphere of this there's an atmosphere of waste no time Everyone has a chance to study the pitches. Ad-hoc one-on-one conversation in the weeks before usually establish some context too. This was possible when there was no lockdown, there was no work from home, people were in offices. You could have these important ad-hoc one-on-one conversations. Unfortunately, now you have to schedule a meeting for everything. So the output of the call is a cycle plan. Between everyone present, there is knowledge of who is available, what the business priorities are, and what kind of work we have been doing lately. Okay. So there is no step two. Highest people in the company are there. You get the approval immediately then and there. This buying from the very top is essential. The meeting is short, options well shaped, and the headcount low. When these criteria are met, the betting table becomes... Hmm. And this is where people also get a feeling of hands on the wheel, and they are steering where the company is going, where the product is going. But my big question is, this guy is saying that only these guys are available? What about the team? I was hoping that the betting table would have the team. Okay. The meaning of a bet. We talk about betting instead of planning because it sets different expectations. First, bets have a payout. We are not just filling a time box. We want to achieve something when we bet on something. We want something in return. That's the payout. So we are not doing two weeks around a feature and hoping for incremental progress. We want a specific payout that makes the bet worth taking. Second, bets are commitments. If you bet six weeks, then we commit to give the team the entire six weeks with no interruptions. They're not trying to optimize every hour. So there's no micromanagement involved. We're only looking for bigger movement of the progress. Third, a smart bet has a cap on the downside. If you bet six weeks on something, the most we can do is six weeks. We don't allow... so yeah that helps in time boxing the feature development uninterrupted time it's not really a bet if we say we are dedicating six weeks but then allow the team to get pulled away to work with something else yeah yeah we are betting on this so this is critical if you are betting on something it's rather it's rather be important and when something is important you want it to be get to get done For that, you need the team to focus on that and not get pulled by other things. So when you make a bet, you honor it. We do not allow the team to be interrupted or pulled away. If you don't allow other people to get commitments, just a few hours, just one day. Momentum and progress are second order things like growth and acceleration. You can't describe them with one point. You need an uninterrupted curve of points. When you pull someone away for one day to fix a bug, you don't lose you don't just lose a day you lose the whole momentum this is very very critical still majority of the people working software companies do not understand this it's a second order as this guy said it's a second order thing it breaks the whole momentum what if something comes up okay so the maximum time we'd have to wait is six weeks six weeks if the cycle passes and that cycle is still the most important thing to do we can bet on it for that cycle this is why it's so important to only bet one cycle ahead this keeps our options open to respond to these new ideas and of course it's a real crisis we can always hit breaks but true crisis are very the circuit breaker We combine this uninterrupted time with a tough but extremely powerful policy. Teams have to shift the work within the amount of time. If they don't, the project doesn't get an extension. We intentionally create a risk that the project won't happen. This sounds severe but is extremely helpful. It eliminates the risk of runaway project. And if the project doesn't finish in six weeks, it means we did something wrong in shaping the project. So instead of investing more time in a bad approach, you come back later, reframe it and do it in a better way. Circuit Brickern motivates the team to take ownership. As we'll see, teams are given full responsibility that includes making trade-offs. Because you have to do it within the limited time, you maybe cut the scope, you take a different approach at the solution. And that forces the team to take trade-offs and hence they have more ownership and more joy out of what they are building. they're building it themselves they're taking important decisions what about bugs first we should step back and question our assumptions about bugs there's nothing special about bugs that make them automatically more important than anything else okay the mere fact that something is a bug does not give an excuse to interrupt ourselves or other people all software has bugs all software has bugs all software has bugs okay the question is how severe are they if we are in real crisis data is being sent the app is grinding to a halt huge swath of customers are seeing the wrong thing we'll drop everything to fix it vast majority of bugs can wait six weeks or longer and many don't even need to be fixed okay you can't ship anything new if you have to fix the whole world first that's it nobody likes bugs we still want ways to deal with them three strategies have worked for us use cooldown ask any programmer if they think they wish They could go back and fix. They would have a list to show you. The cooldown period between cycles gives them time to do exactly that. Bring it to the betting table. If a bug is too big to fix during cooldown, it can compete for resources at the betting table itself. Okay. The programmer can make case of fixing it and shape the solution in the pitch. Okay, cool. Schedule a bug smash. Once a year, usually around the holidays, you get a whole cycle to fixing bugs. You schedule a bug smash or a bug bash. the holidays are a good time for this because hard to get an outlet done if you are traveling or during time of the team can self-organize to pick the motion books and solve them keep the slate clean the key to managing capacity is being ourselves a clean slate with every cycle that that means only betting one site at a time and never carrying straps of old work okay okay even we have even if we have some kind of roadmap in our head at that time we keep in our heads in our side channel discussion each six weeks we learn what's working and what isn't what's important what's not there is no downside to keep an option open and massive upside from being available to act on the unexpected so don't plan too far ahead even if you have a plan let it be vague and broad and not too concrete and narrow What about, because you learn, because as the world evolves, you evolve, your customer evolves, your product evolves, your investors evolve, everything evolves with time. What about products that just can't be done in one cycle? Well, in that case, we'll only bet six weeks at a time. Suppose we envision a feature that takes two cycles to shift. We reduce our risk management by shaping a specific six-week target. This is what goes in the six-week window. Once you achieve that, maybe you have a part two in the next. betting cycle i hope that's what is written here okay then you have place your bets okay look where you are so what we have done so far let's go out of this mode which mode are we in and continue scrolling what about table of contents how do you access the table of contents i want to look at the table of contents sidebar right i don't know how to use this okay so we have this sidebar okay we finished shaping up we understood how to overall concept how to set boundaries find elements rabbit holes and then writing the pitch now we are inside betting inside betting we are at place your bets okay okay so we'll try and finish this off next time we'll pick up the building part okay cool cool cool cool let's hide away place your bet so look where you are depending on whether we are improving an existing product or building a new product we are going to set different expectations about what happens during the cycle this invites us to reflect on where we are in the arc of our products development and bet accordingly so what i understand from this is your company strategy what is your current company strategy bet according to that when we add features to an existing product we follow the standard shape of process shape the work bet on it and give it to the team to build we expect the team to finish and shift some version of the shape of work by the end of the cycle on an existing product all of the existing code and design that isn't going to change defines a kind of empty space that the new feature will fit into so you already have a product this new feature is fitting into shaping and building is like craft of a piece of furniture for a house that is already built Yeah, you already have all your sofa, your TV, your entrance, your decor. There you have to fit a new chair. New products are different. Whereas adding to an existing product is like buying a couch for a room with fixed dimensions. New product development is like figuring out where the walls and the foundation should go so that the building will stand. You have noticed three phases of work when we built a new product from scratch. In each phase, the way we shape and our expectations for how the team will work, are different so these phases unfold over the course of multiple cycles but we still only bet one second at a time actually let me read this we have noticed three phases of work when we build a new product from scratch okay in each phase the way we shape and expectations how the team will work are different okay so there are three phases and you work differently to the r d mode at the very earliest stage of a new product Our idea is just a theory or a glimmer. We don't know if the bundle of features will hold together in reality. A lot of scrap work. We might decide halfway that it's not what we want. In other words, we can't reliably shape up what we want in advance and say this is what we want. We expect to ship it after six weeks. We have to learn what we want by building it. We call this stage R&D mode and adjust for it in three ways. first instead of betting on a well-shaped pitch we mainly bet the time on spiking some key pieces of the new product idea the shaping is much fuzzier because we expect to learn by building two rather than delegating to a separate build team our senior people make up the team david takes the programming role and works with jason or a senior designer With Jason's guidance, this is necessary for two reasons. First, you can't delegate to other people when you don't know what you want yourself. Second, the agricultural decisions will determine what's possible in the product's future. They define the holes that future fits into. And this phase, the team needs to hold the vision of the product and be able to judge the long-term effects of design decisions. Lastly, we don't expect to ship anything at the end of the RNA cycle. The aim is to spike, not to ship. what is the meaning of spike okay we don't know in the best case we'll have some ui and code committed to serve as the foundation for subsequent work the goal is to learn what works so we can commit and just the same guys just says lunch computation let's wrap it up quickly we can't uh ship huh so in the r d mode you are not really the goal is to learn what works to commit to some load bearing structure the main code and ui decisions that will define the form of the product going forward we can't ship anything to customers in just a single cycle of r&d work but we still don't commit to more than one cycle at a time we may learn from the first cycle that we aren't ready to tackle the product yet or we may discover that our intuition ran true and the product is coming together depending on how it goes we'll decide cycle by cycle whether to continue spending informal time in r&d mode Then you have production mode. If we continue to get warmer after some R&D cycles, we'll eventually reach a point where the most important architectural decisions are settled. Okay. The product does those few essential things that define it and the foundation is laid for the dozens of other things we'll have to do before we can ship to customers. So in our terminology, we call this PMF. When we know that the market needs this and we have a product, which will most likely fulfill that demand and is already fulfilling that demand to the most desperate customers then you create a more stable more scalable version of it and roll it out to the larger audience with this structure in place that the senior team can bring in other people to contribute this is the flip to the production mode where we work in formal cycles with clear-cut shipping betting and bidding production mode is like working on an existing product the precedence set by the already work enables okay What we expect to see at the end of cycle. The team builds the products no longer limited to the senior group. Okay, it becomes possible to bet multiple teams. Shipping is the goal, not spiking. But because the product isn't publicly available, we define shipping differently. Shipping means merging into the main code, expecting not to touch it again. Since we aren't shipping to customers at the end of each cycle, we maintain the option to remove features on the final cut before launch. That means we can still be incremental. Okay, got it. Cleanup mode. In the final phase before launching the new product, we throw all structure out of the window we call this cleanup mode it's a free for all we have built enough new products to learn that there are always things we forgot things we missed details and the bugs that creep most likely there's something about putting your finger near the launch button that makes your hair stand up everything suddenly gets real things we dismissed before pop up at us with new importance that's why we reserve some capacity at the end for the unexpected so what do we exactly do in the cleanup mode i'm not sure there's no shaping the cycle is closer in spirit to the bug smash leadership stands at the helm throughout the cycle calling attention to what's important and corrupting away distractions there aren't clear team boundaries everyone jumps in to help however they can work is shipped merge to the main codebase okay discipline is still important we have to check ourselves to make sure These are must-haves we are working on and not just our cold feet begging us to delay launch. Cleanup shouldn't last longer than two cycles. Two cycles? You mean 12 weeks? Cleanup is also the phase where leadership makes those final cut decisions. A smaller surface area or even means fewer questions to answer, less to support, less we are committing to maintain. Okay, sometimes we need to see all the features working as a whole to judge. what we can live without and what might require deeper consideration so consideration happened at the shaping pre-shaping shaping at the betting table while building and consideration is also happening at this final stage so examples the dot grid calendar we built the dot grid calendar for base scan an existing product we shaped the project bet six weeks on it a team built it then we shipped it a new product hey internet after two years of development we launched a new email app A team of explored nearly a year of production, fleshed out the ideas and ended up two cycles of cleanup. These guys are making big, big features and still they are using six weeks cycles. So that's great. To be precise, there was some overlap, but okay, fine. Every bet on here was placed one at a time. The betting table didn't know that they were working on here for two years. Okay, nobody knew we were working on it for two years. and it's elemental feature hill charts so her example shows some gray area when we build the hill charts feature we had no idea if we're going to work or not yes that was an existing product it felt too risky so we framed the project more like production uh production mode back on the new product we shaped a first version that was just functional enough to use ourselves and okay this was a risk we've got one cycle okay Here's some common questions you might hear when people at the betting table are debating which bets to play. Does the problem matter? Okay, first let's look at the questions. Is the appetite right? Is the solution attractive? Is this the right time? Okay. Are the right people available? Okay. So what we'll do is we'll just look at the contents in this chapter and we'll start in the next session again from this point about What are the common questions asked in a betting table? People ask about problem, about appetite, about the solution, about the resources, about the timing of it all. Okay. So post the kickoff message. After the bets are made, someone from the betting table will write a message that tells everyone which projects we are betting on for next second, who will be working on them. So you want to have a kickoff message. Okay. Okay. Okay. So that brings us to the end of the chapter. Okay. Why not just look at the... questions and yeah let's quickly look at the questions does the problem matter okay just like in pitch write-ups we always take care to separate problem and solution okay of course any problem that affects customers matters but we have to make choices because there are so many problems so you weigh the problems how important are they okay so people from different perspectives different experience they judge the importance of a problem differently For example, a problem might impact a small segment of customers, but disproportionate burden on support. So depending on your exposure to support, you might think that that is more important. Sometimes the solution is too complicated or too sweeping, main wide questions about the problem. Do we really need to make so many changes? Okay, so there's a way to narrow it down. Is the appetite right? There always will be debate that can you actually get it done? It's good when we have a solution. shape to a reasonable time frame. But we might still have a debate whether it's worth the time. Suppose a stakeholder says that they aren't interested in spending six weeks on this pitch. The negotiation could go in a couple of directions. Maybe the problem wasn't articulated well enough. And there's knowledge that the shaper can add to the cover right now to swing the opinion. For example, yeah, it doesn't happen often, but when it does, people are so vocal about it that it really tarnishes perception. Maybe it sounds trivial, but support has go through 11 timing steps to get the solution. Sometimes saying no to the time government is really saying no to something else. Maybe there's something about the solution or the implementation they don't like. Asking how would you feel if you could do it in two weeks. Can uncover that it's not supposed to be the time. The CTO might answer, I don't want to introduce other dependency into that area of the app. Okay, the shaper might just let the idea go if the interest is too low. The shaper might go back to the drawing table, work on a smaller version and come back with it. Is the solution attractive? The problem may be important and the appetite may be fair, but what about the solution? Adding interface elements carries an invisible cost, giving up the real estate. A button in the corner of the homepage might perfectly solve the problem, but that is valuable. If you give it up now, you won't be able to use it in the future. Are we selling it too cheaply to solve this particular problem? Okay. What kind of project do we want to do next and depend on the project we have done recently? maybe it's been too long since we have made a splash of news with a new feature or we are building too many features and feeling some some fixes are overdue so yeah these are reasons that we might pass on a pitch even if it's nice because we want it's not the right time we want to do something else for which the time feels right are the right people available so i'm guessing you know we need someone with a specific expertise which can suddenly cut down the scope or the risk a lot for this given solution, then you want to have those people available. The type of future each person has been doing recently or for a long time is another factor. And lastly, there's the calendar trustee with people's availability, vacations, practical. So we need to ensure that the right people are available. So, we have seen other companies with different models, where instead of assigning the projects to people, they let the team members choose which products. Culturally, we are meeting awards for this extra step, but we have heard it can work well. So, you have a broader set of people, more engineers, more designers, and you have some pitches, second pitches, maybe the engineers can choose which pitch they want to place their batons, which they want to build. So guys, with that, we come to the end of the... What process? Betting process. You understood shaping? You understood betting? And we'll take up building in the next session. Okay, guys. Okay, okay, okay, guys. So with that, bye-bye. We'll have a few more sessions. And this was just the raw reading. Maybe we'll read other books. But we'll also have smart summaries. We'll also have maybe some guests in future. Maybe have some debate, discussions in future. which can help us understand how to ship products how to be good at product delivery and you know how to think about it for different kinds of companies for different stages of a product so hopefully we'll get all of that and thank you for today if you find this useful just subscribe and we'll keep posting okay tada bye bye see you guys

How does Basecamp get so much done so quickly at such a high level of quality with such a small team?

1. They are not into waterfall or agile or scrum. 
2. They don’t line walls with Post-it notes.
3. They don’t do daily stand ups, design sprints, development sprints
4. No backlogs, no Kanban, no velocity tracking, none of that.

They have an entirely different approach which is penned down by Ryan Singer in the book 'Shape Up' which we will study together.

#product #development #shapeup #ryan #singer