Study Along: Shape Up by Ryan Singer | Product Development

hello guys we are live for the fourth time in the last 20 minutes last three times have been quite unlucky because the wi-fi is not supporting me let's see if it's fourth time lucky succeed the fourth time so what is the agenda today well we are going to study a book together called shape up before that i'll just like to confirm If the stream is live, the audio is working fine. Before that, and just like... Nice, nice, nice, nice. Yes. Yes, we are good to go. Okay, so this is a book called Shape Up. So a disclaimer here, this is not like smart summary or a gist of insights from this book. This is just the first raw reading of the book along with you guys. So a new approach, a fresh approach at product development at shipping software. uh has come out of a company called base camp and the guy ran singer from the same company has penned down this fresh approach in his book we'll find out what the approach is which they have named as shape up so they do not follow many of the conventional product development approaches like kanban or agile or the waterfall which no one follows nowadays and they have a new approach and we'll find out what that approach it approach is and the new approach has been quite uh popular these days and many companies are trying to adopt this so together let us begin okay so i just went through their contents and they have named uh they have divided the book into three parts the first part is shaping second part is betting and the third part is building Shaping, I guess, is shaping the business requirement, the business insight into a rough idea of what we want to make. Betting, I guess, involves defining the scope and the specifications and what work needs to be done. We'll find out. That's my guess. And building, of course, is the execution part. So we'll jump straight into the part one, which is shaping. And this is part one shaping. let us try and read it through so together we'll read this for one hour or so and then we'll take it forward from there in the next episode okay so i guess this diagram tells us a lot so there's a state where the idea of what we want to make is completely abstract and the and gradually you get to a state where it's extremely concrete and in between we have a stage where the idea is shaped okay understood that one so what are the principles of shaping uh by the way am i visible yeah i must be visible why won't i be visible okay okay so what are what are the principles of shaping when when we shape the work we need to do it at the right level okay okay so it need it should not be too vague it should not be too concrete because guys if it's it's too vague And you are not able to ask the right questions and understand the scope of it. If it's too concrete, it's bound to fail in the long term because any product development, unexpected problems arise. And only when you go deep into the woods do you realize the exact situation. OK, so yeah, it says that wireframes are too concrete, that wireframes are generally where we start our product development. So these guys don't like wireframes. Hmm. When designers directly build wireframes, they define too much detail too early. Okay. Okay. A friend of his said this, I'll give a wireframe to my designer. And then I'm saying to her, I know you are looking at this, but that's not what I want you to design. I want you to rethink it. It's hard to do that when you are giving them this concrete thing. Okay. I didn't get that. I'll give a wireframe to my designer, and then I am saying to her, I know you're looking at this, but that's not what I want you to design. I want you to rethink it. It is hard to do that when you're giving them this concrete thing. OK, OK, OK. Overspecifying the design also leads to estimation errors. OK. OK. Oh, someone has already highlighted stuff. So it's not someone. It's the book itself. okay so they are saying that wireframes are too concrete and words are too abstract okay so there are some projects where all you have is a word generally in a hackathon the you only have idea and you just start executing so that's the other extreme they've given some example like ad group notifications and then programmers are off to building that you have to be a mind reader okay okay so under specified projects naturally grow out of control because there's no boundary to define what's out of scope yeah so that's the problem with more abstract idea for product formulations where it's not concrete and you don't know what to leave out so wireframes are too concrete and words are too abstract okay so we'll look at a case study the dot grid calendar i'll just fix this guy here this guy i feel we are leaving out stuff which we should not okay fine fine fine hold out yes fine okay so we have a case study the dot grid calendar what's the dot grid calendar i'm not sure how so we have launched three of base version 3 of basecamp without a calendar feature it has a scheduled feature that just listed events one after the other without any kind of monthly weekly or daily grid so there there was no grid and only it listed down the events i guess so customer were asking okay bro add a calendar So we had big calendars before and we knew how complex they are. It can easily take a lot of time to build them. Okay. So what makes a calendar complicated? Dragging and dropping events between cells to move them. Wrapping multi-day events around the edge of the screen. Different views for monthly, weekly or daily time scales. Okay. Dragging the edge of an event to change its duration. okay so so managing a calendar and giving so many features to the user makes it complex color coding events for different categories handling different expectations for desktop versus mobile okay so they are saying this was a complicated task and they knew exactly why building a calendar is complicated so only 10 percent of customers had used it earlier and that's why They didn't have the appetite to spend so much time on this. Okay. On the other hand, they are saying, if you could do something to satisfy those customers, you know, who were writing us in one six week cycle, we are open to doing that. Okay. So they were ready to give six weeks to this. With only six weeks to work with, we could only build about a tenth of what people wanted in a calendar. So what, what? part of what one tenth of the expectation do you fit in that is a hard question indeed we did some research and narrowed down a use case that we wanted to solve we eventually arrived at a promising concept inspired by calendars on phones we could build a two-month read-only grid view so any day with an event would have a dot for each event okay okay A list of events would appear below the calendar. Clicking a day with a dot would scroll the events from that day into view. We call it the dot grid. So it wasn't a full featured calendar. There was no drag and drop and other fancy UI operations. We'd just repeat the dots. There'd be no color coding or categories. So this is how they have narrowed down the product of calendar so you have a grid view of the different dates and you have dots for days where you have events and the number of dots tells us how many events when you click on it it just shows a list of events for that day i'm guessing so it's selling that the sketch is really rough and a lot of details are not there so there's enough room for the designer to come in and build this stuff and also it's it's the scope is quite defined what you want to leave out and how you want to so this is a very good example of what a shaped up idea is okay so at the end of the project this was how the calendar looked okay so you have a very simple old-fashioned calendar dots you click on them and you go to that date okay makes sense so what does this example tells us it tells us it's rough okay at this shaping stage the work has to be rough okay it cannot be it cannot be too finely detailed so designers and programmers need room to apply their own judgment and expertise to discover all the real trade-offs that would emerge okay second property is that it's solved Despite being rough and unfinished, shaped work has been thought through. Okay. All the main elements are there. And, okay. Well, surprises could still come, but you have a rough idea of what the solution is. The solution to the problem is there to a large extent. It's bounded. What you don't have to do is clearly specified. Okay. so to completing the project within a fixed amount of time requires that you limit the scope and leave out the non-important stuff so that should be there that has to be there okay so the three properties uh with that it's rough and it's solved and it's bounded so you are clearly telling that this is what we are making you are not you are proposing a solution that will have these things and it will cater to these needs but still everything is rough and it's not written in stone yet okay so who who does the shaping up the shaping is a is creative and integrative okay it requires combining interface ideas technical possibilities business priorities so i see that the business guy the design guy and the developer guy these three guys these three minds have to work together on this so either you need the skills as a generalist or you need collaboration so it's primarily a design work okay so it's a interaction design viewed from the user's perspective it defines what the feature does how it works where it fits into existing flows so okay it's not a you know a tech solution or technical document that you are writing that this is the exact way we would execute this this is more from the point of view of the user that this would be the flow and yeah guys just give me a second yes guys we are back we are back okay so what we understood that this is mainly from the user's point of view the flow which is similar to the way quite similar to the way a designer and a product manager sit together and design a flow for the product but i guess there's a lot more detail uh in what we get there and basically this is saying that you keep it rough you keep it rough you have a basic expectation of what the feature is you also keep it bounded but also it's rough so that i think there's some scope some there's some leeway to cut out scope and you know make it fit into your appetite in how much time you want to build at the same time you are you are defining the business value for the end user that you definitely want to create okay so it says that you don't need to be a programmer to shape but you need to be technically literate you should be able to judge what's possible what's easy and what's hard okay So it's also a strategic work. Setting the appetite and coming with a solution requires you to be critical about the problem. Why it matters? What is the business value of this? And where does the company go if this succeeds or if it doesn't? So you might be alone sketching on a paper in front of White Lowe's collaborator. So it's a closed door creative process, which means that you have a fewer set of minds. brainstorming on the idea oh is the internet even working wait is the internet working guys let me just check the speed is it working it seems to be working interesting fine yeah i guess there was some lag in between but now it's fine now it should be fine okay so there would be rough diagrams in front of you nobody outside the room would be able to interpret so it's not a documentation process it's a brainstorming process is what i'm understanding so when working with a collaborator you move fast you jump from one promising position so it's private rough early work okay so we understand like who is involved in shaping up and what does it roughly look like two tracks okay you can't really schedule shaping work because by its very nature it's unknown work okay shaping up itself is unknown work so for that reason we have two separate tracks one is a shaping track and one is a building track so during any six week cycles the team are building work that's been previously shaped and the shapers are working on what the teams might potentially build in a future cycle okay so work on the shaping track is kept private and not shared with the wider team until the commitment has been made to bet on it that gives shapers the option to put on this okay okay so i think this is followed commonly as well that you have this uh design track and you have this building track uh but yeah the the way of thinking about the designing plus part i think is quite different here and we'll we'll find out other more details so what are the so what have we learned so far okay okay shaping as we can see so there are principles of shaping so i guess we are still inside principles of yeah we are at the very end of principles of shaping let's let's finish this part and then we'll try to summarize what we have learned steps what are the different steps to shaping so there are four main steps first you set boundaries okay figure out how much time the raw idea is worth how much is it worth and how to define the problem that gives us the basic boundaries Then rough out the elements. So you sketch a rough solution. So it has to be rough, not concrete wireframes. And the output of this step is an idea that solves the problem without the fine details. So you don't have the fine details, but you have a rough solution. Then you have addressed the risks and rabbit holes. We need to take a hard look at it to find out holes and unanswered questions. And then write the pitch. once we think we have shaped it enough to potentially bet on it we package it up into a formal write-up called a pitch the pitch summarizes the problem the constraints the solution the rabbit holes and limitations okay the pitch goes to the betting table for consideration if the project gets chosen the pitch can be reused at kickoff to explain the project to the team okay first so what i understand is first you have the raw idea you understand how valuable is it is it even valuable and what is the problem statement what are you trying to solve and then you get at a rough solution then you understand the risks and edges and then you write it down then you write down the problem the resolution the risks the edges write a formal setup okay okay so these are the four steps okay and what have we studied overall overall we have studied about a few properties of a shaped up idea uh why how how shaped up idea is different than a worded idea which is too abstract and wire framed idea which is too concrete and then it's basic properties that it's it's rough but you have a solution it has some kind of a boundary then we know who does it and roughly in what how does it look like how it's private and brainstormed and not really a formal process and then we see the steps where actually the final step is to write a formal write-up which which will be placed at the betting table we'll see what that is okay so we have a rough idea of everything now so i guess uh there are four steps and we'll go step by step so what are the four steps let me just write down the steps okay in my copy so the first step is setting boundaries right the second step was to have the rough solution what are we calling it we are calling it rough out the elements i'm not sure about this rough out the elements so maybe we have to yeah the different elements of the solution third part was i guess understanding the risks and rabbit holes yeah so you find out the most uncertain and most risky parts up front otherwise you're not stuck at the 11th hour and just make your team completely unreliable and fourth part is write the pitch okay so i guess the different chapters are arranged as per the four steps and the first chapter is setting boundaries they said they wanted categories we should redesign the whole section yes okay okay okay this is this is common you design the whole system with a single identity and then finally you build a mountain on top of it and then some set of important super users want multiple accounts multi-identity support and then you rebuild the whole thing okay rebuilding is common you can never avoid it can this approach avoid it completely i don't think so i but i hope it will help in reducing such instances okay so the first step in shaping up an idea is to set boundaries okay let's get into it the first step of shaping is setting boundaries on what we are trying to do okay okay so The conversation about building a feature generally starts with a raw idea. Like, this is a demand coming to user support. So it's saying that instead of immediately discussing how to solve it, there are some terms. So I guess there are some terms which this company uses. And let's understand the terms. Setting the appetite. Okay. so idea gets us excited writer yes it often does in that case we need to temper the excitement by checking whether this is really something we are going to able to invest time in or not if we don't stop to think about how valuable the idea is we can all jump too quickly to either committing resources or having long discussions about potential solutions that don't go nowhere so this is very common one idea strikes us it appears very tempting and we immediately jump on it so yeah always sleep on it is what i have been told other ideas are less exciting and feel more like a challenge we didn't ask for the customer wants a calendar we don't really want to build one but we know it's kind of important so so whether we are chomping or we are reluctant it helps to define how much time and attention the subject deserves okay but is this easy to define such a thing okay how much time will it take is it a minor tweak so we call this appetite appetite is the time budget okay so how much time are we ready to invest for this feature okay so these guys set appetite in two sizes small batch big batch small batch is basically one designer two programmers okay where you can build the thing in one or two weeks Okay, many such things are clubbed together in a six-week cycle. That is a small batch and a big batch. Big batch is you are making a big feature. Small batch, you are making multiple small features is what I understand. Okay, so they have a fixed six-week appetite is what I am able to see. I don't know why fixing this is important or fixing this is the main idea here. Okay, fixed time. variable scope okay so they have answered my doubt so you have fixed time and you have variable scope okay so an appetite is completely different from an estimate okay okay so i personally am very bad at estimating the amount of time a particular feature or a product would take but i know a lot of engineers who are as bad or even worse so estimates is an issue estimate start with the design and end with a number that is correct we get a design handed down to us we are told about all the flows and all the nitty gritties of the design and then we take some time to make a wild guess about what the bottlenecks could be and how what are the ways different ways we can implement it and then we figure out some time for research some time for poc and then we give our churn out a number so we take a design and we churn out a number right yeah so we use appetite as a creative constraint on the design process okay so the design is not wild design is not including thousands of complicated flows but there is a constraint on the design process itself so you first fix the appetite and then the design starts this is what i understand The principle called fixed time variable scope is key to successfully defining and shipping projects. Take this book for example. It's hard to ship a book when you can always add more, explain more, improve more. When you have a deadline, all of a sudden you have to make decisions, you have to make trade-offs, you have to cut off things. Okay, I can choose between fixing typos or adding a new section. That's the tension between time, quality and scope. i don't want to release a book with embarrassing typos i'll choose to reduce the scope by leaving out the extra section correct without the pressure of fixed deadline i wouldn't make the trade-off correct correct correct correct we'll skip a few lines we apply this principle at each process from shaping to building and shipping okay first the appetite constraints what kind of solution we designed in the shipping process okay Yeah, I've seen this when as product team, we design a new feature which we think is important. And then we present the solution to the broader team. And the team gives estimates and even starts working on it. And then there comes a feeling that this feature, is it really that important? because while designing the designer did not knew how much time this will take but after you know that well this will take two months or three months to build and you already started building it and then midway you realize key was it really worth three months of development maybe not and if that was the case you would cut down the scope or maybe you'll completely leave out this feature so yeah that is that is a major disconnect that i have personally personally seen okay so this is the idea that design then estimate and then building this is not what's happening here first you find out its worth and set a very rough idea you know and its value and then you set an appetite for this and then i think you do more solutioning and only then do you start building we'll see we'll see The book will explain. So good is relative. There's no absolute definition of the best solution. The best is relative to your constraints. So without a time limit, there's always a better version. Correct. You don't always want the best solution. The amount of time we set for appetite is going to lead us to different solutions. Got it. Got it. I think it's driving home the same idea with a lot of different analogies. We'll move ahead. Responding to raw ideas. Our default responds to any idea. Interesting, maybe someday. This is very common when some junior engineer or even some senior business guy comes up with an exciting idea. And then people say, yeah, very interesting. But it never gets picked up. OK. so we give it space so we can learn whether it's really important and what it might entail okay yeah we have this concept of backlog and then we put things in backlog and then pick up sick things up one by one so they're saying there's no backlog here okay it's too early to say yes or no on first contact okay even if we are excited about it we shouldn't make a commitment that we don't yet understand We should not make a commitment that we don't yet understand. This is a life lesson, I must say, and not just about product development. We should never make a commitment that we don't understand yet. Okay, so we need to do work on the idea before it's shaped enough to better resources on it. Okay, so you always shape an idea and then you move forward. You do not work on unshaped ideas. you do not say yes or no to unshaped idea is is it am i understanding this correctly if we always say yes to incoming request we'll end up with a giant file yes never do that that is the recipe for disaster we don't want to shut down an idea that we don't understand new information might come in tomorrow that makes us see it completely differently on the other hand right away can set the wrong expectations correct Be like Sachin Tendulkar. Don't show too much excitement and don't show too much content also to any idea. Narrow down the problem. In addition to setting the appetite, we usually need to narrow down our understanding of the problem. We once had a customer ask us for more complex permission rules. It could easily have taken six weeks to build the change she wanted. Instead of taking a request at face value, we dig deeper. It turned out that someone had archived a file without knowing the file would disappear for everyone else. Instead of creating a rule to prevent some people from archiving, you realize you could put a warning on the archive action itself that explains the impact. That's a one-day change instead of a six-week project. Correct. You need to go at the root cause of any business requirement. Another example is the whether we are in frames dropping some frames have dropped but i hope it's working fine now okay okay so we have flipped from what could we build to what's really going wrong what okay what is the what is the root of the user problem of the pain point that the user is facing instead of building things you are finding out root causes of problems. Sure, a calendar sounds nice, but what is driving the request? And at what point does someone's current workflow break down? Okay, correct. You cannot keep on taking requests and keep on building them. You have to always narrow them down and always you will have to weigh how important a feature is. So we are going to study a case study now. okay so in the case so what have we studied so far first we understood about the principles of shaping up where we saw that shaped up idea is the right stage to take an idea before saying yes or no and that is a stage where it's neither too abstract nor very concrete and while and you have some sort of a boundary you have some sort of a solution but it's all very rough and we also saw that there are four logical steps that have been laid out to us whether in the first step you set boundaries then you maybe rough out the elements we'll see what it means understand the risks and the edges and then write a formal pitch Okay, so now we were studying the first step, which is the setting boundary step. So here, one thing that we understood is that we are fixing time. Generally, we had like a design, then you estimate, and then you build. Instead, you shape up idea, and then you define the appetite. And then maybe you narrow it down and take it forward. But defining the appetite means that you are fixing the time. The time is fixed. Now you can cut scope, make it simpler, take out a feature. But yeah, that is what we understood till now. And now we have a case study. So the case study is that people want to know. So I'll just quickly look at my stream because I don't think anyone is watching. So I'll quickly see. It's simpler. Yes. yes yes it seems to be working perfectly so we'll study for another let's say till 10 30 and we'll stop oh hope we are able to complete the whole chapter of shaping today itself okay defining calendar so in case of the calendar request we called a customer who asked for this feature instead of asking her why she wants a calendar and what it should look like we asked her when she wanted a calendar What was she doing? Then the thought occurred to ask for it. She told us she worked in an office with a big calendar drawn on a chalkboard wall. Her office mates marked when they were meeting clients in the handful of meeting rooms on the calendar. one day she was looking from home a client called and asked her to schedule a meeting she had to drive to the office to look at the wall calendar traffic was terrible in the end there wasn't a free space that worked for a client she could have saved an hour and a lot of frustration if she had been able to check for open spots on the calendar from her computer at home okay so the insight wasn't computerized the calendar What we learned was that C free spaces was the important thing for this use case. Not do everything a calendar does. Okay. So it gave us a basic specific baseline to design against. Okay. So Basecamp already had an agenda view of events. it worked for listing major deadlines and milestones but it wasn't good for resource scheduling because you couldn't see empty spaces so we narrowed down the need from do everything a calendar does to help me see free spaces so i can figure out when to schedule something okay we didn't have a solution but now we felt like we had a problem that was specific enough to spark an idea This lead led us to the simpler dot grid concept from the last chapter. Okay. What if we can't figure out a specific pain point or use case? Our appetite can tell us how much research is worthwhile. If it's not critical now and we can't get our hands around the problem, we'll walk away from it and work on something else. Maybe in the future, a new request or story will pop up that gives us better insight into the problem. Watch out for grab bags. When it comes to unclear ideas, the worst offenders are redesigns or refactorings that aren't driven by a single problem or a single use case. When someone proposes something like redesign the file section, that's a grab bag. What's a grab bag? I don't know. Not a project. It's going to be very hard to figure out what it means where it starts and where it ends. Here's a more productive starting point. We need to rethink. the files section because sharing multiple files takes too many steps so i think here instead of saying what we want to build you are saying what the problem is okay now we can start asking what's not working in what context are there too many steps what parts of the existing design can stay the same and what parts need to change okay a telltale sign of a grab bag is level 2.0 Hmm. Okay. Okay. We have seen that before. Our excitement about improving a huge part of our app got the better of us. We know there were a lot of problems with our files feature, but we didn't ask ourselves what specifically were we going to do. Project turned out to be a mess because we didn't know what done looked like. We recovered by splitting the project into smaller projects like better file previews and custom folder colors. okay so unless you don't know what the problem is the solution would always be vague and you don't know when it is done okay understood that boundaries in place when we have all the three things a raw idea appetite and a narrow problem definition we are ready to move to the next step and define the elements of a solution Okay, elements of a solution is the second step, right? Yes, it is. So let's go to the second step. But before that, what did we read? In setting boundaries, what did we read? We understood that first you need a raw idea. A raw idea maybe encapsulates what the problem is. Maybe how valuable is it? How urgent is it? and then you set an appetite and based on that appetite and the raw idea then you define the problem narrowly so that it is the solution fits with the appetite i guess i guess so this is what we learned that not to go after grab bags you know not to go after the perfect solution go with a good enough solution for this requirement in a limited time but with variable scope okay find the elements okay here i guess we would be doing some brainstorming so now that we have the constraints of the appetite and the problem we are solving it's time to get from an idea in words to elements of a software solution There could be dozens of ways to solve a particular problem. So it's important that we can move fast and cover a lot of different ideas without getting dragged down. Move at the right speed. Two things enable us to move at the right speed at this stage. First, we need to have the right people in the room. They're working alone or with trusted partner who can keep pace with us. Someone we can speak with in shorthand who has the same background knowledge and who can be frank with us. Okay. And to avoid... the wrong level of details and sketches. If we start with wireframes or visual layouts, we'll get stuck. The challenge here is to be concrete enough to make progress without getting dragged down by finer details. Okay. So the questions we are trying to, so where are we right now? I guess we are already done with the raw idea, setting the appetite and then narrowing down the problem statement. And now we have come to finding the elements part. okay so this is this is the solutioning part okay solutioning or the designing part i guess so what are the questions we are trying to answer so where in the current system does the new thing fit okay how do you get to it okay what are the key components or interactions okay where does it take you okay so these are not straightforward questions let us try to understand them To stay on the right level of detail and capture our thoughts as they come, we work by hand using a couple of prototyping techniques, breadboarding and fat marker sketches. These allow us to quickly draw different versions of entire flows so we can debate the pros and cons of each approach. Okay, I did not really get these questions completely. So where in the current system does the new thing fit? This is an obvious question and something we should definitely think about. How do you get to it? Maybe this is from the point of view of a user. What are the key components of interaction? This is obvious. Where does it take you? Not quite so obvious to me. We'll see. Breadboarding. So it's a concept from electrical engineers to help us design at the right level of abstraction. A breadboard is, we know a breadboard. was an electrical engineer you basically are building a prototype from a diagram on a chart paper you go to the next step where you take the simplest possible implementation of each thing and you just wire them up to see if the whole thing is functional or not okay and and it's very flexible you are not you haven't wired stuff you can easily chop and change and come to a good solution So it's a prototype. Okay, so deciding to include an indicator light and a rotary knob is very different from debating the chassis material. Whether the knob should go left of the light or right, how sharp the corner should be and so on. So discussing at the right level of detail is very important. Similarly, we can sketch and discuss the key components and connections of an interface idea without specifying a particular visual design. To do that, we can use a simple shorthand. There are three basic things we'll draw. Places, affordances, and connection lines. Places. These are things you can navigate to, like screens, dialogues, menus, UI elements. Affordances. These are the things the user can act on. like buttons and fields we consider interface copy to be an affordance to reading is an app that gives this information for subsequent actions okay connection lines these so how show how the affordable affordances take the user from place to place so you have the design and you have the user actions and then you have the workflows on top of user actions We'll use words for everything instead of pictures. The important things are the components we are identifying and their connections. Okay. Let's look at the example. Suppose our product is an invoicing tool. We are considering adding a new auto pay feature to enable our customers to pay future invoices automatically. How do you turn auto pay on? What's involved? We can pick a starting point and see that the customer landed on an invoice. That's our first place. We draw it by writing the name of the place and underlining it. This is the invoice. On the invoice, we are thinking we could add a new button to turn or not. That's an affordance. They go below the place. Now, where does the button go? Some place for setting up the auto. We don't specify whether it's a separate screen or a pop up from what's connected to what standpoint. It's all the same. OK, now we can talk about what belongs on that screen. Do we ask for a credit card? Is there a card on file already? Et cetera, et cetera. OK, as we think it through, we decide. we should ask for credit card details here and show the logo okay so we have written that there's a logo of the financial institution you have the credit card fields and then you have a submit button okay straightforward enough but wait did we actually pay the original invoice or not now we have both functional and interface questions what does enabling autopay actually do does it apply only for the future or does Paying with autofay the first time also pay the current invoice. And how do we explain and where do we explain this behavior? So now we are starting to have deeper questions and discussions prompted by just a few words and arrows in the breadboard. OK, this is the breadboard. OK, since we are using a lightweight notation and we aren't bogged down with wireframes, we can quickly jump around and entertain different possibilities. OK, OK, so pay balance now. OK, it's a question there. but now we are complicating the responsibilities of the confirmation screen we are going to need to show a receipt if you pay your balance now should the confirmation have a condition to sometimes show a receipt of the amount just paid okay how about an entirely different approach instead of starting on an invoice we make auto pay an option when making a payment this way there is no ambiguity about whether the current amount is being paid we could add an extra autopay was enabled color to the existing payment confirmation page okay sketching this out reminded us of the current payment form supports ACH in addition to credit card we're discussing that we can use ACH too what about ACH What about after AutoPay is enabled? How does the customer turn it off? How does the customer turn it off? Up to this point, many customer systems didn't have usernames and passwords. They followed tokenized links to pay the invoices one by one. One might naturally assume that now that the customer has something like AutoPay, they need username and password, some landing place to go and manage it. Okay, okay. Too much scope. Reflecting strategically on what they knew about their customers, they thought it would be quite alright if the invoices customers had to reach out to the invoice and ask them to turn off the auto pay. In that case, we could have a single option to disable auto pay in the customer retail page that we offered to invoices. okay so this is the invoices list and inside a customer page you can turn off auto pay this example illustrates the level of thinking speed of movement to aim for during the breadboarding phase writing out the flows confronts us with questions we didn't originally think of and you know it makes us make important decisions once we get to the place where we play through the use case and the flow seems like a fit we have got the elements we need to move on to start defining the project more clearly we are getting more concrete while still leaving out a huge amount of detail okay fat marker sketches what is what a fat marker sketches sometimes so this is the dread boarding i think is just the words and arrows part fat marker sketches would be more visual Sometimes the idea we have in mind is a visual one. Okay, breadboarding would just miss the point because the 2D arrangement of elements is the fundamental problem. In that case, we don't want to waste time on wireframes. Instead, we use fat marker sketch. Broad strokes that adding detail is difficult or impossible. Okay. Okay. Okay. So this is a UI problem, which you could only explain using... Some visual representations other than just breadboarding. Okay. Okay. We are going to skip this one. Elements are the output. In the case of the auto pay example, we ended up with some clear elements. Okay. So guys, where are we? 50 minutes down the line. We'll maybe wrap up this subtopic and then we'll end the stream. take it forward the next time from here so elements are the output in the case of the auto pay example we ended up with some clear elements a new use this to auto pay checkbox on already pay screen disable auto pay on the invoices side okay for the to do project there was lose to do's above the first group and group to do's So this helps us in narrowing down what we want to accomplish. So this is like finding the elements. So finding the elements was basically you are writing down the flow, like what is your main, what are the different locations as they have said, locations or places. These are pages. And how does it begin? How does it flow? And where do we finally get? Also, there's a lot of room for designers. You don't have to say, I know I drew it like this, but ignore that. Regardless of what you say. Any specific mockups are going to bias what other people do after you. So they'll literally take every detail. Okay. so working the right level of abstraction ensures that there is a clear communication about what exactly we want to build without having unnecessary details which a designer should come up with okay i guess that is what it is saying it not deliverable yet this step of shaping is still very much in your private sphere okay it's normal for the artifacts oh my mac will shut down soon okay so we'll We'll finish this chapter, and then we'll close the stream. So it's still private. It's still a cloudy idea. We have gone from a cloudy idea like auto pay to a specific approach and a handful of concrete elements. But the form we have is still rough and kind of an outline. But there can be significant unknowns, and we need to consider the unknowns before we give it to the team to build it. So we need to check for holes and challenges. Also keep in mind that at this stage we could walk away from the project. Like we haven't bet on it. We haven't made any commitments. So we have gotten closer to a good option that we can later lobby for when it's time to allocate resources. So you have a shaped up idea. Is this the shaped up idea? No, it's not. We are there somewhere. We have a rough solution. We had a raw idea. we understood the appetite we narrowed down the problem now we have a rough solution so at this stage you can keep it in the back burner and maybe pick it up later okay so uh so what we have done till now is we have set boundaries and we have found out the elements either through breadboarding or through fat marker sketches and we have a rough solution in front of us next we want to do is understand the risks understand the uncertainties and the edges and then only write a formal pitch so we'll take these up later on and we'll close the stream today okay tata guys i hope uh this reading was useful you also understood some new things with me because all of us in involved in software delivery whether we are engineers or designers or business people we have been running in circles we have been building the same features again and again we have not been able to ship out important features in time it always gets delayed and i think understanding this fresh approach can help us hopefully help us go away go away happily after a product or a feature is done Okay, then on that note, we'll end the stream and we'll take it from here next time. Okay. Sayonara. Bye-bye, 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.