Shape Up (Ryan Singer) - Notes

Introduction

Guide How They do product development at Basecamp.

Growing Pains

When software teams start to grow some common struggles appear:

• Team members feel like project go on, with no end in sight.
• Product Managers can’t find time to think strategically about the product.
• Founders ask themselves: “Why can’t we get features out the door like we used to in the early days?”

There were tons of challenges faced by Basecamp, with trial and errors they figured out techniques that actually worked for the Basecamp. Three people built the first version of the product, Json Fried, Basecamp’s Founder, led the design, His co-founder David Heinemeier Hansson (DHH), programmed it (and created the well-known web framework Ruby on Rails as a by-product). Third one was a web designer focused on usability and user interfaces.

From the first prototype in July 2003 to launch in February 2004, David only worked ten hours a week and that was no enough. So the third person jumped into the programming world keeping his one foot in designing and one foot in programming world. Here is the overview of the main ideas from the book.

Six-week cycles

At base they work in six-week cycles.

• Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline is far from the start, so they use the time wisely.
• Decisions are also based on moving the product forward in the next six weeks, not micromanaging time.
• Not counting hours OR focusing on how individual spent their days.
• No daily meetings
• No rethink their road-map every two weeks.
• Instead their focus is at the higher level, They say “If this project ships after six weeks, we’ll be really happy”.

Shaping the work

• They shape the work before giving it to a team. A small senior group works in parallel to the cycle teams.They define the key element of a solution before they consider a project ready to bet on.
• Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves.
• When Shaping, They focus less on estimates and more on their appetite. Instead of asking: “How much time it will take to do some work?”, they ask “How much time do we want to spend? How much is this idea worth?” This is the task of shaping: narrowing down the problems and designing the outline of a solution that fits within the constraints of our appetite.

Making teams responsible

• They give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. Very different where managers chop up the work and programmer acts as ticket takers.
• When teams are more autonomous, senior people can spend less time managing them, with less time on management, senior people can shape up better projects.
• When projects are better shaped, teams have clearer boundaries and so can work more autonomously.

Targeting risk

• At every step of the process they target a specific risk: the risk of not shipping on time.
• Improving your discovery process should come after regaining your ability to ship. e.g. You have best strategy in the world, but if you can’t act on it, what good does it do?
• This is about risk of getting stuck, the risk of getting bogged down in previous quarter’s work, wasting time on unexpected problems, and being free to do what you want to do tomorrow.
• They reduce risk in the shaping process by solving open questions before they commit the project to a time box.
• They reduce risk in the planning process by capping their bets to six weeks. If project runs over it won’t get extension. Their “circuit-breaker” ensure that they don’t invest unnecessary time on something that needs rethinking first.
• They reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, They built one meaningful piece of work end-to-end and repeat it.

Part One of this book is all about Shaping - the pre-work they do on projects before consider them ready to schedule.

Part Two of this book is all about Betting - how they choose among the pitched projects and decide what to do six weeks at a time.

Part Three of this book is all about Building - the expectation they place on the teams and the special practices they use to discover what to do.

Principle of Shaping

When we share the work we need to find the right balance, not too vague and not too concrete.

Wireframes are too concrete

• When design leaders go straight to wireframes or high-fidelity mockups, they defines too much details too early. This leaves designers no room for creativity.
• Over-specifying the designs also leads to estimation errors. The more specific the work is, the harder it can be to estimate.
• When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth.

Words are too abstract

• On the other side, Projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. eg. “build a calendar view” or “add group notifications”. Team member don’t have enough information to make a trade-offs. A Programmer who worked in this situation said:

You’re solving a problem with no context. You have to be a mind reader. It’s like: “we’ll know it when we see it.

• Concerning estimation, under-specified projects naturally grow out of control. because there’s no boundary to define what’s out of scope.

Case Study: The Dot Grid Calendar

In version three of Basecamp calendar it had “schedule” features and customers started asking for daily, weekly or monthly calendar view. They knew how complex they are. It can easily take six months or more to build a proper calendar (There was no AI back then).

There are the kinds of things that make a calendar complicated: Dragging and dropping event feature, color coding events, wrapping multi-day events, handling different expectations for desktop vs mobile interactions etc.

Past version of Basecamp has calendars, and only about 10% of customers used them. That’s why they didn’t have the appetite for spending six months on a calendar.

With only six weeks to work with, They could only build about a tenth of what people think of when they say “calendar.” The question became: which tenth?

They did some research and narrow down the use case that they wanted to solve. They could build a two-month, read-only grid view. Any day with an event would have a dot for each event. List of events will appear below the calendar, and clicking on the a dot would scroll the events for that day into view. They called it Dot Grid.

The Dot Grid wasn’t a full-featured calendar. They weren’t going to allow dragging events between days or multi-day events or color coding events etc. They were comfortable with all these trade-offs because of their understanding of the use case.

This is the level of fidelity they used to define the solution:

Now designer had a lot of room to be creative and interpret how this should look and feel.

At the same time note how specific the idea is, It’s very clear how it works, what needs to be built, what’s in and what’s out.

End result from designer to and programmer looked like this:

This small example highlights a few properties of shaped work.

Property 1: It’s rough

• Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished.
• Everyone finds something to improve or contribute.
• Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge.

Property 2: It’s solved

• Despite being rough and unfinished, shaped work has been thought through. In short it should be solvable.
• All the main elements of the solution are there at the macro level and they connect together.
• While surprises might still happen and icebergs could still emerge, there is clear direction showing what to do.
• Any question, rabbit holes they could see up front have been removed to reduce the project’s risk.

Property 3: It’s bounded

• Lastly, shaped work indicate what not to do. It tell the team where to stop.
• There is a specific appetite - the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out.
• The roughness laves room for the team to resolve all the details and be creative in the solution, while the solution and boundaries act as guard rails.
• They reduce risk and channel the team’s effort making sure not spending too much time or get stuck.

Who shapes

• Shaping is creative and integrative. It requires combining interface ideas with technical possibilities with business priorities.
• Shaping is primarily design work. The shaped concept is an interaction design viewed from the user’s perspective. It defines what the feature does, how it works, and where it fits into existing flow.
• You don’t need to be 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.
• Its’ also strategic work. Setting the appetite and coming up with a solution requires you to be critical about the problem. What are we trying to solve? Why does it matter? What counts as success? Which customers are affected? What is the cost of doing this instead of something else?
• Shaping is a closed door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator.
• When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private rough, early work.

Two tracks

• You can’t really schedule shaping work because, by it’s very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building.
• Dusting any six week cycle, the teams are building work that’s been previously shaped and shapers are working on the what the team will build in future cycle.
• Work on the shaping track is kept private and not shared with wider team unless commitment has been made to bet on it.
• It gives liberty to shapers to drop it when it’s not working out.

Steps to shaping

Shaping has four main steps:

1. Set boundaries: Figure out how much time the raw idea is worth and how to define the problem. this gives us the basic boundaries to shape into.
2. Rough out the elements: Creative work of sketching a solution. We do this at a higher level of abstraction then wireframe in order to move faster. The output of this step is an idea that solves the problem within the appetite but without all the fine details worked out.
3. Address risks and rabbit holes: Once we think we have a solution, we take a hard look at it to find the holes and unanswered questions that could trip up the team. We modify the solution, cut things out or answer some tricky question if required to prevent team getting stuck or wasting time.
4. Write the pitch: Once we think we’ve shaped it enough to potentially bet on, we package it with a formal write-up called pitch. It summarize the problem, constrains, solution, rabbit holes and limitations. The pitch can be used to explain the project to the team if the project gets chosen.

Set Boundaries

The first step of shaping is setting boundaries on what we’re trying to do. The conversation about building a features always starts with a raw idea, like “customers are asking for group notification”. It should be at abstract or in board terms on the discussion to make it productive.

Setting the Appetite

Sometimes an idea gets excited right away, in this case we should determine that whether this is really something we’re going to able to invest time in or not. If we don’t stop to think about how valuable the idea is, we move towards nowhere.

Other ideas are less exciting and feel more like a challenge we didn’t ask for. The customer wants calendar; we don’t particularly want to build one, but we do feel we need to do something about the request.

Thinking about the value of the idea helped to define how much of our time and attention the subject deserves. Is this something worth a quick fix if we can manage? Is it a big idea worth an entire cycle?

We call this appetite. You can think of the appetite as a time budget for a standard team size. They usually set the appetite in two sizes:

• Small Batch: This is a project that a team of one designer and one or two programmers can build in one or two weeks. We batch these together into a six week cycle.
• Big Batch: This project takes the same-size team a full six-weeks.

In rare cases where the scope is so big that six-week project isn’t enough. If that is the case they will try to hammer it down by narrowing the problem definition. If they still can’t shrink the scope, they will break off a meaningful part of the project that we can shape to a six-week appetite.

Fixed time, variable scope

An appetite is completely different from an estimate. Estimates start with a design and ends with a number. Appetites start with a number and end with a design.

This principle, called “fixed time, variable scope” is a key to successfully defining and shipping projects. For example: It’s hard to publish article when you can always add more to it. When you have a deadline, you have to make a decision, either you add new section in the blog or fix grammar. That’s the tension between time, quality and scope. If scope wasn’t variable we won’t make a trade-off.

We apply this principle at each stage of the process, from shaping potential projects to building and shipping them.

• First, the appetite constrains what kind of solution they design during the shaping process.
• Later, They hand the work to a team, fixed time box pushes them to make a decision (trade-off) about what to achieve.

“Good” is relative

Good doesn’t have it’s definition. Without a time limit, there’s always a better version. The ultimate meal might be ten course dinner but when you’re hungry and in a hurry, a hot dog is perfect.

The amount of time we set for our appetite is going to lead us to different solutions. We could redesign the main landing page to accommodate a new feature, or we could push it back to a screen with fewer design constraints.

We can only judge what is a “good” solution in the context of how much time we want to spend and how important it is

Responding to raw ideas

Not each idea needs to be go in backlog, sometimes saying soft “no” can open up options to think about importance of the idea and what it might add value.

It’s too early to say “Yes” or “No” on first contact. We shouldn’t make a early even if idea is exciting. We need to do work on the idea before it’s shaped enough to bet resources on. If we always say “yes” to incoming requests we’ll end up increasing stack in the backlog.

It’s important to keep a cool manner and a bit of poker face. We also want to welcome the ideas at the same time showing too much enthusiasm right way can set expectations that this thing is going to happen.

Narrow down the problem

In addition to setting the appetite, we usually need to narrow down our understanding of the problem.

Consider the calendar view example, If they only want to spend six weeks instead of six months building a huge calendar, how do they narrow it down?

In that case they flip from asking “What could we build?” to “What’s really going wrong?”.

Case study: Defining “calendar”

When they got the having a calendar request, instead of asking Why she wants a calendar and what should it looks like, they asked her when she wanted a calendar. What was she doing when the thought occurred to ask for it?

She worked in an office with a big calendar drawn on a chalkboard wall. Everyone puts their client meeting there. When she was working from home, she had hard time searching for free slot for her client. She has to drive to the office to look for free slot. She could have saved hours just to get free slots.

This story was important to derive what is really necessary, Here what they learned was that “see free spaces” was the important thing for this use case, not “do everything a calendar does”.

They narrow down the need from “do everything a calendar does” to “help me see free spaces so I can figure out when to schedule something”. That’s how they built “Dot Grid Calendar”.

What if we can’t figure out a specific pain point or use case?

Out Appetite can also tell us how much research is worthwhile. If it’s not critical now and we can’t get hands around the problem, leave it and may be work on something else. Maybe in the future a new request or story will pop up that gives us better insights 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 use case. when someone proposes something like “redesign the files section”, that’s a grab-bag, not a project. It’s hard to figure out what it mean, when it starts, when it ends.

Here is more productive starting point: “We need to rethink the Files section because sharing multiple files takes too many steps”. Now we can start asking what’s not working?

A tell-tale sign of a grab-bag is the “2.0” label. They faced the issue of tagging their project as “2.0” without thinking much about what they were going to do. The project turned out to be a mess because they didn’t know what “done” looked like.

Boundaries in place

When we have all three things - a raw idea, an appetite, and a narrow problem definition - We’re ready to move to the next step and define the element of a solution.

Find the Elements

Now that we have the constraints of an appetite and the problem we’re solving, it’s time to get from an idea in words to the elements of a software solution.

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 OR nobody in the room. Either we’re working alone or with a partner who has the same background, keep the pace with us, can be frank with us as we jump between ideas.
• Second, We need to avoid the wrong level of detail in the drawings and sketches.

The challenge here is to be concrete enough to make progress on a specific solution without getting dragged into fine details. The questions we’re trying to answer are:

• Where in the current system does the new thing fit?
• How do you get to it?
• What are the key components or interactions?
• Where does it take you?

We use breadboarding and fat marker sketches to stay on the right level of detail. We quickly redraw entire flows and debate on pros and cons of each approach.

Breadboarding

A breadboard is an electrical engineering prototype that has all the components and wiring of a real device but no industrial design.

Deciding to include an indicator is very different from debating on whether the light should be on left or right, how sharp the corners should be and so on.

Similarly, we can sketch and discuss the key components and connections of an interface idea without specifying a particular visual design. There are three basic things we’ll draw:

1. Places: These are things you can navigate to, like screens, dialogs, or menus that pop up.
2. Affordances: These are things the user can act on, like buttons and fields. Interface copy could be an affordance.
3. Connection lines: These show how the affordances take the user from place to place.

We’ll use words for everything instead of pictures. The important things are the components we’re identifying and their connections. It links the idea to the use case that we’re trying to solve.

Example

Suppose our product is an invoicing tool. We’re considering adding a new “Autopay” feature to enable our customer’s customers to pay future invoices automatically.

How do you turn Autopay on? What’s involved? We can pick a starting point and say what the customer landed on an invoice. That’s our first place. We draw it by writing the name of the place and underlining it.

On the invoice, we’re thinking we could add a new button to “Turn on Autopay.” That’s an affordance. Affordances go below the line to indicate they can be found at that place.

Where does that button go? Some place to setting up the Autopay. No need to specify screen, popup or model. From a what’s-connected-to-what standpoint. Let’s draw the connection line from the button to the Setup Autopay Screen.

Now we can talk about what belongs to that screen. Do we ask for a credit card here? Is there a card on file already? What about other payment methods?

Just figuring out what to write under the bar starts the debates and discussion about what to build.

We decide we should ask for credit card details here and show the logo of the financial institution.

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 only apply to future or also with the current invoice? And where do we explain this behavior? We’re starting to have deeper questions and discussion prompted by just a few words and arrows in the breadboard.

Since we’re using a such a lightweight notation, we can quickly jump around and entertain different possibilities.

We could add an option to the setup screen…

But now we’re complicating the responsibilities of the confirmation screen. We would need to show receipt if you pay your balance now. Should confirmation have a condition to show receipt of the amount just paid?

How about entirely different approach. Instead of starting on an Invoice we make Autopay an option when making a payment. This way there is no ambiguity about whether the current amount is being paid. We can add extra “Autopay was enabled” callout to the existing payment confirmation page.

Sketching this out reminded us that the current payment form supports ACH in addition to credit card.

What about after Autopay is enabled? How does the customer turn it off? Up to this point, many customers in the system didn’t have usernames or passwords. They followed tokenized links to pay the invoices one by one. One might assume that now we’ve Autopay, we should have username and password and some landing place to manage it.

The team in this case decided that adding the username/password flows was too much scope for their appetite at the time. Reflecting on the domain knowledge, they decided it’s okay if customer needs to react out to the invoicer and ask them to turn off the Autopay. In that case we could add a single option to disable Autopay in the customer detail page that we already offered to invoicers. We drew out the flow like this:

This example illustrates the level of thinking and the speed of movement to aim for during the breadboarding phase.

Once we react to the place where flow seems like a fit, we’ve got the element we need to move on to start defining the project more clearly. We’re getting more concrete while still leaving out a huge amount of detail.

Fat marker sketches

Sometimes the idea we have in mind is visual one. Breadboarding would just miss the point because the 2D arrangement of element is the fundamental problem. In that case Instead of wasting time on wireframes and unnecessary fidelity, use fat marker sketches.

A fat marker sketch is a sketch made with such broad stokes that adding detail is difficult to impossible.

Here is an example: At Basecamp to-do lists they used to use fake item that looks something like “—- Needs Testing —” and puts items below. They want to build real divider instead of this fake to-do item.

They had to work out what the implications of adding a divider were. They came up with a rough idea of having “loose” to-dos above and “grouped” to-dos below. Adding subsequent dividers adds more groups below the “loose” items at the top.

They could add items via some affordance within each group, including the “loose” group on top.

They didn’t find placing button well, They talked about possibilities to place the “add” affordance inside of a menu that they already had to the left of each to-do item.

This notation is much less constraining than breadboards, which has downsides. This is too quick to change compare to wireframes where it might takes days or weeks.

It may seem a little silly to call fat marker sketches a technique or a tool. This prevents us adding more details to the sketch and which is important.

Elements are the output

In the case of Autopay example, we ended up with some clear elements:

• A new “use this to Autopay?” checkbox on the existing “Pay an invoice” screen
• A “disable Autopay” option on the Invoicer’s side

For the To-Do Group project, the elements were:

• Loose to-dos above the first group belong directly to the parent
• Grouped to-dos appear below the loose to-dos
• Adding button below to-dos doesn’t work visually, They’re ok with replying on action menu for inserting to-dos into position.

Similarly for the Basecamp’s Dot Grid Calendar, they used fat marker to sketch:

This enabled them to work out the main element of the solution:

• A 2-up monthly calendar grid
• Dots for events, no spanned pills
• Agenda-style list of events below that scrolls an event into view when you tap a dot

This list of elements is extremely narrow and specific compared to “monthly calendar”. Exactly the kind of narrowing we expect from the shaping process.

Room for designers

Later when it’s time to involve a designer, you don’t want to say “I know I drew it like this but ignore that…”. We don’t want to make bias from the sketches and let designer add their creativity.

Working at the right “level of abstraction” not only ensures we move at the right speed, it also leaves this important room for creativity in the later stages.

By leaving details out, the breadboard and fat marker methods give room to designers in subsequent phases of the project.

This is a theme of the shaping process. We’re making the project more specific and concrete, but still leaving lots of space for decisions and choices to be made later.

Not deliverable yet

This step of shaping is still very much in your private sphere. We’ve gone from a cloudy idea like “Autopay” or “to-do groups” to a specific approach and a handful of concrete element. We still have very rough form and mostly in outline.

What we’ve done is landed on an approach for how to solve the problem. But there may be some significant unknowns or things we need to address before we’d consider this safe to hand off to a team to build successfully.

No conveyor belt

At this stage, we could walk away from the project. We haven’t bet on it. We haven’t made any commitments or promises about it. What we have done is just adding value to a raw idea by making it more actionable.

Risks and Rabbit Holes

We’re shaping for a fixed time window. We may have a appetite for six weeks but we need to look closer, because all it takes is one hole in the concept to derail that. If they run into the unanticipated problem that takes two weeks to solve, they just burned a third of the budget!

Even worse, sometime you run into problems that don’t just delay the project, they have no apparent solution.

There will always be unknowns, That’s why They apply the many practices in Part Three so that teams tackle the right problems in the right order, leaving the room for the unexpected. But that doesn’t mean we shouldn’t look for the pitfalls we can find up front and eliminate them before betting on the project. Before we consider it safe to bet on, a shaped project should be as free of holes as possible.

Different categories of risk

In terms for risk, well-shaped work looks like a thin-tailed probability distribution. There’s a slight chance it could take an extra week but, beyond that, elements are defined and thought enough that there’s no reason it should drag on longer that that.

If there are any rabbit holes in the shaping such as technical unknowns, unsolved design problems, or misunderstood inter-dependencies, the project could take multiple times the original appetite to complete. The right tail stretches out.

We want to remove the unknowns and tricky problems from the project so that our probability is an thin-tailed as possible. That means a project with independent, well-understood parts that assemble together in known ways.

Look for rabbit holes

Deriving solution of elements is fast-moving process, It was more breath than depth. We slow down and look critically what we cam up with. Did we miss anything? Are we making technical assumption that aren’t fair?

One way could be to walk through a use case in slow motion. From start to end of the user journey/ Slowing down and playing it out can reveal gaps or missing pieces that we need to design.

Then we should also question the viability of each part we think we solved. We ask ourselves questions like:

• Does this require new technical work we’ve never done before?
• Are we making assumption about how the part fit together?
• Are we assuming a design solution exists that we couldn’t come up with ourselves?
• Is there a hard decision we should settle in advance so it doesn’t trip up the team?

Case Study: Patching a hole

Example of To-Do: When they defined the To-Do Groups project, we introduced the idea of dividers in the to-do list:

They liked the idea of the dividers, and the logic of loose vs grouped to-dos made sense to them. But when they looked closer they realized they didn’t address how to display completed items. Should they show it below each group or should they show all completed at the bottom (it was in existing system before divider) with the same divider pattern. Should they consider how they handle completed items entirely?

This was a hole in the concept. If they didn’t address it, it may pushing a deep design problem down to the team. They didn’t wanna give a team tangled knot of inter-dependencies and then ask them to untangle it within a short fixed time window.

Since the problem can leads to lots of complicated implications in user experience, they decided to include the solution in the shaped concept. They decided to append the group name at the end of the completed to-do, may looks a bit messy but justify the trade-off: it drastically simplified the problem and they could still show completed items from a group on the group’s detail page.

There can be a lot of questions on the decision but it’s important to identify the trade-offs and make the right decision. As shapers, They’re thinking less about the ultimate design and more about basic quality and risk. With the compromised concept they get to keep all the elements that made the project worth doing, the groups of incomplete items, and they get to cut off a big tail of risk.

Next when we write the pitch for this project, we’ll point out this specific “patch” as part of the concept. That way nobody down the line will get tripped up on it.

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 the cases you specifically aren’t supporting to keep the project well within the appetite.

For example: They worked on an idea for notifying groups of people in Basecamp. Rather than checking off five programmers one by one, you could just click “Programmers” and they’d be selected for notification. They gave a closer look at the product and realized this idea could be useful at many instances such as assigning a to-do, or mentioning people in the chat room.

They decided not to include this extra over-head to the appetite and market as “out of bounds” for having better focus on the win they wanted: a faster flow for posing messages.

Cut back

There may be part of the solution they got excited about during the sketching phase that aren’t really necessary. For example, When they designed the To-Do Groups feature, they thought it would be good to have color-code groups. Yes it would looks good on the interface but they cut down the idea and flag that as unnecessary. They could mention it nice-to-have, but everyone should start from the assumption that the feature is valuable without it.

Present to technical experts

Up to this point shaping has been a closed-door activity. Before you’re 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 understand the code better.

This is a good time to grab some technical experts and walk them through the idea. Communicate that this is just an idea. It’s something you’re shaping as a potential bet, not something that’s coming down the pipe yet.

Beware the simple question: “Is this possible?” In software everything is possible but nothing is free. We want to find out if it’s possible within the appetite we’re shaping for.

Talk through the technical constraints of how this is a good solution given the appetite, so the’re partners in keeping the project at the size you intend. It’s not just a “What do you think” conversation, they’re really hunting for time bombs that might low up the project once it’s committed to a team.

Invite them to a whiteboard and redraw the element as you worked them out earlier. Stick to the concept you already worked out to get feedback on the work you’ve already done. Once you’re done invite them to suggest revisions.

Depending on how the conversation goes, you may either have validated your approach or discovered some problems that send you back for another round of shaping.

De-risked and ready to write up

At the end of this stage, We have the elements of the solution, patches for potential rabbit holes and fences around areas we’ve declared out of bounds. We’ve gone from a roughly formed solution with potential risk in it to a solid idea that we now hope to bet on in the future.

Now we’ll write pitch. 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.

Write the Pitch

Now at this point, we’ve got the element of a solution now, and we’ve de-risked our concept to the point that we’re confident it’s good option to dive a team. Now we will put the concept into the form that other people will be able to understand, digest and respond to.

The purpose of the pitch is to present a good potential bet, It’s basically a presentation. The ingredients are all the things that we need to both capture the work done so far and present it in a form that will enable the people who schedule projects to make an informed bet.

There are five ingredients that we always want to includes in a pitch:

1. Problem: The raw idea, a use case, or something we’ve seen that motivates us to work on this
2. Appetite: How much time we want to spend and how that constrains the solution
3. Solution: The core elements we came up with, presented in a form that’s easy for people to immediately understand
4. Rabbit holes: Detail about the solution worth calling out to avoid problems
5. No-gos: Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable.

Ingredient 1: Problem

It’s critical to always present both a problem and a solution together. How often teams, our own included, jump to a solution with the assumption that it’s obvious why it’s a good idea to build this thing.

Diving straight into “what to build” - the solution is dangerous. You don’t establish any basis for discussing whether this solution is good or bad without a problem.

Establishing the problem also lets us have a clearer conversation alter when it’s time to pitch the idea or bet on it. The solution might be perfect, but what if the problem only happens to customers who are known to be poor fit to the product? We won’t be able to utilize six week effectively.We want to be able to separate out that discussion about the demand so we don’t spend time on a good solution that doesn’t benefit the right people.

How far you have to spell out the problem will depend on how much context you share with the people reading the write-up.

Ingredient 2: Appetite

You can think of appetite as another part of the problem definition. We don’t just want to solve the use case we want to come up with a way to solve it in six weeks, not three months.

Starting the appetite in the pitch prevents unproductive conversations. There’s always a better solution. The question is, if we only care enough to spend two weeks on this now, how does this specific solution look?

Anybody can suggest expensive and complicated solutions. It takes work and design insight to get the a simple idea to fit in a small time box. Starting the appetite and embracing it as a constraint turns everyone into a partner in that process.

Ingredient 3: Solution

Like solution with no problems, sometimes companies bet on problems with no solution. “We really need to make it easier to find things on the messages section. Customers are complaining about it”.

That’s not ready to pitch or bet on. A problem without a solution is unshaped work. Giving it to the team means pushing research and exploration down to the wrong level, where the skill-sets, time limit, and risk profile are all misaligned.

If the solution is not ready, someone should go back and do the shaping work on the shaping track. It’s only ready to bet on when problem, appetite and solution come together.

Help them see it

During the element phase, it was critical to sketch ideas at the right level of abstraction so we didn’t slow down or loose any of the ideas appearing at the corners of our brains and tips of our tongues.

We also need to draw at the right level of detail when we write the pitch. We need to balance the concreteness than when we worked alone or with a partner. People who read the pitch and look at the drawings without much context need to “get” the idea.

We need more concreteness, but we don’t want to over-specify the design with wireframes or high-fidelity mocks. It should not have anything to do with the actual shaping work we did (eg. fixed colors). Hand-written breadboards have a “you had to be there” quality to them.

We need some techniques to help people see the idea while still not going too far into irrelevant details.

Embedded sketches

Suppose your breadboard from the shaping session looked like this:

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 clearer:

But we’re still asking people to imagine too much, It’s worth the trade-off to go one step down into fat-market details here.

This makes it easier to see what the element are and evaluate how clearly the feature presents itself on the dashboard. The downside is we’ve gotten into some layout decisions that would have been nice to avoid. Designer should feel free to find different design than the box divided with a vertical line. We’d add a disclaimer here in the pitch that reminds designers of the latitude they should take.

This is a example of selectively getting into more visual detail because we need it to sell the concept.

Annotated fat marker sketches

Sometimes ideas are inherently visual or a little too complicated to express in a schematic breadboard. Fat marker sketches can be very effective in a pitch; you just need to take more care to label them cleanly.

We can use different colors to separate out material from the labels:

or You might add some call-outs to enable discussion of specific elements.

Ingredient 4: Rabbit holes

Sometimes addressing a rabbit hole just requires a few lines of text. For example, in the Payment project, the shapers wanted to call out a specific solution for how to create URLs. The URLs would never live on custom domains for v1 of the project. This is the kind of thing that’s not central to the concept, but spelling it out patches a potential rabbit hole.

Ingredient 5: No Gos

Lastly if there’s anything we’re not doing in this concept, it’s good to mention it here. For example, in the Payment Form Project, the team decided up front that they wouldn’t allow any kind of WYSIWYG editing of the form. It would be handled in the separate page. WYSIWYG might be better in some people’s eyes, but given the appetite it was important to mark this as no-go.

Examples

There are the two examples of real pitches. 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.

This pitch for changing how notifications work starts with two videos to demonstrate the problem. The black boxes toward the end are visualization of user behavior data that supports a decision in the pitch.

Ready to present

The next step will be to make the case that this pitch describes a bet worth making. This can happen in a couple ways.

At Basecamp they prefer asynchronous communication by default and escalate to real-time only when necessary. This gives everyone the maximum amount of time under their own control for doing real work. That means the first step for presenting a pitch is posting the write-up with all the ingredients above somewhere that stakeholders can read it on their own time.

How they do it in Basecamp

They post pitches as Message in Basecamp, They created a Message Category called Pitch so they can easily find them. Pitches are posted to a Team called Product Strategy that can be accessed by people on the betting table.

When they need to include a fat marker sketch in a pitch, they’ll draw it on an iPad and take a screenshot.

People comment on the pitch asynchronously. Not to say yes or no - that happens at the betting table - but to poke holes or contribute missing information.

Bets, Not Backlogs

Now that we’ve written a pitch, where does it go? It doesn’t go onto a backlog.

No Backlogs

Backlogs are a big weight we don’t need to carry. The growing pile gives us a feeling like we’re always behind even though we’re not. Just because somebody thought some idea was important a quarter ago doesn’t mean we need to keep looking at it again and again.

Backlogs are big time waters too. The time spent constantly reviewing, managing prevents everyone from moving forward on the timely projects that really matter right now.

A few potential bets

They hold a betting table where stakeholders decide what to do in the next cycle. At the betting table, they look at pitches from the last six weeks, or any pitches that somebody purposefully revived and lobbied for again.

Nothing else is on the table. There are just a few well-shaped, risk-reduced options to review. The pitches are potential bets.

With just a few options and six-week long cycle, these meetings are infrequent, short and intensely productive.

If they decide to bet on pitch, it goes into the next cycle to build, if they don’t they let it go. There’s nothing they need to track and manage. If pitch was great and time isn’t right then pitcher can independently keep track of it.

Decentralized lists

It’s not required to track backlogs centrally somewhere, everyone can still track pitches, bugs, requests or things 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 they hope to be able to shape in a future cycle. Programmers maintain a list of bugs they’d like to fix when they have some time. There’s no one backlog or central list and non of these lists are direct inputs to the better process.

Regular but infrequent one-on-ones between departments help to cross-pollinate ideas for what to do next. For example, Support can tell Product about top issues they are seeing. which Product can then track independently as potential project to shape.

This approach spreads out the responsibilities for prioritizing and tracking what to do and makes it manageable. People recommend whatever they think is important, that way conversations is always fresh. Anything brought back is brought back with context, by a person, with a purpose.

Important ideas come back

It’s easy to overvalue ideas, The truth is, ideas are cheap. They come up all the time and accumulate into big piles.

Really important ideas will come back to you. It’s less likely to forget a really great idea that is interesting. If you think once and never again it’s not that really important. if you keep hearing about it, you’ll be motivated to shape a solution and pitch betting time on it the next cycle.

The Betting Table

Now that we have some good potential bets in the form of pitches, it’s time to make decisions about which projects to schedule.

Six-week cycles

Committing time and people is difficult if we can’t easily determine who’s available and for how long. Working in cycles drastically simplifies this problem. A cycle gives us a standard project size both for shaping and scheduling.

Some companies use two-week cycles (aka “sprints”). At Basecamp they learned that two weeks is too short to get anything meaningful done. Worse than that, two-week cycles are extremely costly due to the planning overhead.

Since they didn’t find meaningful work being done in two weeks cycle, they tried longer cycles. They wanted a cycle that would be long enough to finish a whole project, start to end. At the same time, cycles need to be short enough to see the end from the beginning. People should feel the deadline to starting making trade-offs.

After years of experimentation, they arrived at six weeks. Six weeks is long enough to finish something meaningful and still short enough to see the end from the beginning.

Cool-down

If six-cycle keep running back to back, there won’t be anytime to breathe and think about what’s next. Therefore, after each six-weeks cycles, they schedule two weeks for cool-down. This is a period with no scheduled work where they can breathe, meet as needed and consider what to do next.

During cool-down, programmers and designers on project teams are free to work on whatever they want. They use it to fix bugs, explore new ideas, or try out new technical possibilities.

Team and project sizes

In addition to standardizing the length of our cycles, we also roughly standardize the types of projects and teams that they bet on.

Their project teams consist of either one designer and two programmers or one designer and one programmer. They’re joined by a QA person who does integration testing later in the cycle.

Teams will either work the entire cycle working on one project (big batch) or they’ll work on multiple small projects during the cycle (small batch - one to two weeks each).

Now that we have a standard way to think about capacity, we can talk about how we decide what to schedule.

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 pitches could be the last new shaped pitch or may be one or two older pitches but no backlog refinement or similar like that.

Their betting table at Basecamp consists of CEO (who in their case is the last word on product), CTO, a senior programmer, and a product strategist.

C-level time is only available in small slices, so there’s an atmosphere of “waste no time” and the call rarely goes longer than an hour or two. Everyone has had a chance to study pitches on their own time beforehand. Once the call starts, it’s all about looking at the options that made it to the table and making decisions.

The output of the call is cycle plan. Between everyone present…

• There’s knowledge of who’s available
• What the business priorities are
• What kind of work we’ve been doing lately All of this feeds into the decision-making process about what to do and who to schedule.

Since the highest people in the company are there, There’s no “step two” to validate the plan or get approval. The meeting is short, the options well-shape, and the headcount low. Combining all these, decision making becomes a bit easy.

The meaning of bet

It uses word “betting” instead of planning, because it sets different expectations.

• Bets have a payout. We’re not just filling a time box with tasks until it’s full. We’re not throwing two weeks toward a feature and hoping for incremental progress.The pitch defines a specific payout that makes the bet worth making.
• Bets are commitments, If we bet six weeks, that means we commit to giving the team the entire six weeks to work exclusively on that thing with no interruptions. Not micro-managing programmer’s time.
• A smart bet has a cap on the downside, If we bet six weeks on something, the most we can lose in six weeks. We’re preventing ourselves spending on something that isn’t worth that price.

Uninterrupted time

It’s not really a bet if we say we’re dedicating six weeks but then allow a team to get pulled away to work on something else.

When you make a bet, you honor it, making sure not to interrupt or pulled team away to do other things. If people interrupt team, that breaks commitments.

When you pull someone away for one day to fix a bug or help a different team, you don’t just lose a day. You lose the momentum they built up and the time it will take to gain it back. Losing the wrong hour can kill a day. Losing a day can kill a week.

What if something comes up during that six weeks? They still not interrupt the team and break the commitment. If the cycle passes and that thing is the still the most important thing to do, they can bet on it for that cycle. This is why it’s so important to only bet one cycle ahead.

The circuit breaker

They combine this uninterrupted time with a tough but extremely powerful policy. Teams have to ship the work within the amount of time that they bet. If they don’t finish, by default the project doesn’t get an extension. They intentionally create a risk that the project - as pitched - won’t happen. This sounds severe but it’s extremely helpful for everyone involved.

• It eliminate the risk of runaway projects. They defined their appetite at the start when the project was shaped and pitched. Very few projects are of the “at all costs” type and absolutely must happen now. They think of this like a circuit breaker that ensure one project doesn’t overload the system. Once project that’s taking too long will never freeze them or get in the way of new projects that could be more important.
• If the project doesn’t finish in the six weeks, it means they did something wrong in the shaping. Instead of investing more time in a bad approach, the circuit breaker pushes them to re-frame the problem. They might use next six weeks with a new or better approach that avoid rabbit hole they fell into on the first try.
• The circuit breaker motivates teams to take more ownership over their project. Teams are given full responsibility for executing projects. That includes making trade-offs about implementation details and choosing where to cut scope. You can’t ship without making decision of where to stop, what to compromise, and what to leave out. A hard deadline and the chance of not shipping motivates the team to regularly question how their design and implementation decision are affecting the scope.

What about bugs?

If the team aren’t interrupted in the six week cycle, how do the handle bugs that come up?

First they should step back and question their assumptions about bugs.

There is nothing special about bugs that makes them automatically more important than everything else. All software has bugs. The question is: how severe are they? If they’re in real crisis such as data is being lost, app is grinding to a halt, customer are seeing the wrong thing, then they’ll drop everything to fix it. But cries are rare. Most bugs can wait for six weeks.

Nobody likes bugs, They still want ways to deal with them, Three strategies have worked for them.

1. Use cool-down: Ask any programmer, if there are things they wish they could go back and fix and they’ll have a list of show you. The cool-down period between cycles gives them time to do exactly that.
2. Bring it to the betting table: If a bug is too big to fix during cool-down, it can compete for resources at the betting table. Suppose a back-end process is slowing the app down and a programmer wants to change it from a synchronous step to an asynchronous job. The programmer can make the case for fixing it and shape the solution in a pitch. The people at the betting table can make a deliberate decision.
3. Schedule a bug smash: Once a year - usually around the holidays, they’ll dedicate a whole cycle to fixing bugs. They call it a “bug smash”. The team can self-organize to pick off the most important bugs and solve long-standing issues in the front-end or back-end.

Keep the slate clean

The key to managing capacity is giving ourselves a clean slate with every cycle. That means only betting one cycle at a time and never carrying scraps of old work over without first shaping and considering them as a new potential bet.

Even if they have some kind of road map in our heads at the scale above cycles, they keep it in their heads and in their side-channel discussions. Each six weeks they learn what’s working and what isn’t, what’s important and what’s not.

What about projects that just can’t be done in one cycle? In that case they will only bet six weeks at a time. If everything goes as expected, they’ll feel good about betting the next six weeks the way they envisioned in their heads. But if it doesn’t go well, they could define a very different project. OR they could start working on urgent that camp up. The important thing is that they always shape what the end look like for that cycle and that they keep their options open to change course.

Place Your Bets

Look where you are

Depending on whether you’re improving an existing product or building a new product, we’re going to set different expectations about happens during the six-week cycle.

This invites us to reflect on where we are in the product’s development and bet accordingly.

Existing products

We follow the standard Shape Up process: shape the work, bet on it and give it to a team to build. All the existing code and design that isn’t going to change defines a kind of empty space that the new features will fit into.

Shaping and building is like crafting a piece of furniture for a house that is already built.

New Products

New products are different. It is like figuring out where the walls and the foundations should go so the building will stand.

They’ve noticed three phases of work when they build a new product from scratch. In each phase, the way that they shape and their expectations for how the team will work together during the cycle are different. These phases unfold over the course of multiple cycles, but they still only bet one cycle at a time.

R&D mode

At very earliest stage of the product, they don’t see the clear cut expectation from the product, they can’t reliably shape what they want in advance. They figure out what they want by building it.

They call this stage R&D mode and adjust for it in three ways

1. Instead of betting on a well-shaped pitch, they mainly bet the time on spiking some key pieces of the new product idea. They expect to learn by building.
2. Senior people make up rather than delegating it to building team. This is necessary for two reasons
   1. You can’t delegate to other people when you don’t know what you want yourself.
   2. The architectural decisions will determine what’s possible in the product’s future - they define the “holes” that future features fit into.
3. They don’t expect to ship anything at the end of an R&D cycle. The aim is to spike, not to ship. The goal is to learn what works so they can commit to some load-bearing structure: the main code and UI decisions that will define the form of the product going forward.

Based on how the R&D cycle goes they’ll decide cycle-by-cycle whether to continue spending informal time in R&D mode.

Production mode

They’ll eventually reach a point where the most important architectural things that define it, and the foundation is laid for the dozens of other things they’;; have to do before they can shop to customers.

With this structure in place, the senior team can bring in other people to contribute. This is flip to production mode, where they work in formal cycles. Production mode is like working on an existing product.

In production mode:

1. Shaping is deliberate again. The shaped work describes what we expect to see at the end of the cycle.
2. Building team is no longer limited to the senior group. It covers more ground.
3. Shipping is the goal, not spiking. But because the product isn’t publicly available to customers yet, they define ‘shipping’ differently. Shipping means merging into the main codebase and expecting not to touch it again.

Since they’re not shipping to customers at the end of each cycle, They maintain the option to remove features from the final cut before launch. This means they can still be experimental. They can’t predict what there will be in final product.

Cleanup mode

In the final phase before launching the new product, they throw all structure out the window. They call this cleanup mode. It’s free-for-all. Since they learn by building that there are always things they forget, things they miss, details that aren’t right.

Everything gets real with launch, Things they dismissed before pop out at them with new importance.

That’s why they reserve some capacity at the end for the unexpected. In cleanup mode:

1. There is no shaping. The cycle is closer in sprint to the “bug smash”. Leadership calling attention to what’s important and cutting away distractions.
2. There aren’t clear team boundaries. Everyone jumps in to help however they can.
3. Work is “shipped” (merged to the main codebase) continuously in as small bits as possible.

Discipline is still important. They need to make sure they are working on what’s important. Cleanup shouldn’t last longer than two cycles.Cleanup is also the phase where leadership makes those “final cut” decisions.

Examples

A new product: HEY

In 2020, after two years of development, They launched a new mail app and service called HEY. HEY was in R&D mode for first year of its development. Nearly a year of production mode cycles followed, where all of Basecamp’s teams fleshed out HEY’s feature set. They ended with two cycles of cleanup and significantly cut back the feature set to launch in July 2020.

Every bet on HEY was placed one at a time. They betting table didn’t know they would be working on HEY for two years during those first few R&D cycles.

An experimental feature: Hill Charts

When they built this feature they had no idea if it was going to work out or not. Basecamp was an existing product, and it felt too risky to bet on releasing this experimental feature to customers. So they framed the project more like a production mode bet on a new product. They shaped the first version that was just functional enough to use themselves. That was a risk: they bet one cycle, not two. But They ended up feeling confident after the first cycle.

Questions to Ask

Here are some common questions you might here when people at the betting table are debating which bets to place.

Does the problem matter?

Just like pitch write-ups, They always take care to separate problems and solution. The solution doesn’t matter if the problem isn’t worth solving.

Of course, any problem that affects customers matters. But we need to make trade-off because there are always more problems. So they weight problem against each other. Is this problem more important than that problem right now?

How the people at the table judge problems depends on their perspective, role and knowledge. For example, a problem might impact a small segment of customers but put a disproportionate burden on support. Depending on your exposure to support and which aspect of the business you’re focused on, you may weigh that differently.

Sometimes a solution that is too complicated raise questions against problems like do we really required these many changes in the app? May be there’s a way to narrow down so that they get 80% of the benefit from 20% of the change.

Is the appetite right?

It’s good when we have a solution shaped to a reasonable time frame, like two or six weeks. But we might still debate whether it’s worth the time. Suppose a stakeholder says they aren’t interested in spending six weeks on a given pitch. The negotiation could go a couple directions from there:

1. Maybe the problem wasn’t articulated well enough, and there’s knowledge that the shaper can add to the conversation right now to swing opinion.
2. Sometimes saying “no” to the time commitment is really saying no to something else. Maybe there’s something about the solution or the technical implementation they don’t like. Asking “How would you feel if we could do it in two weeks?” can uncover that it’s not so much about the time.
3. The shaper might just let the idea go if interest is too low.
4. The shaper might go back to the drawing table and either work on a smaller version or do more research if they believe the problem is compelling but they weren’t armed well enough to present it.

Is the solution attractive?

The problem may be important and the appetite fair, but there can be differences about the solution.

For example, If someone offers an immediate design solution, like “how about “ we move that button to an action menu instead, they might discuss that, but generally they avoid doing design work or discussion technical solution for longer than few moments at the betting table.

Is this the right time?

The kind of project they want to do next can depend on which project they’ve done recently. Maybe they’ve been building too many new features and feel overdue to fix some long-standing customer requests.

All reasons that they might pass on a project even though it’s perfectly well shaped and valuable. The project’s great; it’s just not the right time.

Are the right people available?

As part of the betting process. they choose who specifically will play which role on each team. That is, they’ll pair a project with a specific small team of a designer and one or two programmers. They have a “Core Product” team of designers and programmers and they select from that pool when planning teams for each cycle. The team will work with each other for the whole cycle and then the next cycle can be a different combination of people.

The type of work each person has been doing is another factor. Someone who’s done a long string of small batch projects might prefer to take on a big batch, or vice versa.

Post the kick-off message

After the bets are made, someone from the betting table will write a message that tells everyone which projects they’re betting on for the next cycle and who will be working on them.

Head Over Responsibility

We’ve made out bets and not it’s time to start the next cycle. How does the team get started?

Assign projects, not tasks

They don’t start by assigning tasks to anyone. Nobody plays the role of the “taskmaster” or the “architect” who splits the project up into pieces for other people to execute.

When project is broken into pieces. Everyone just gets disconnected pieces. They trust the team on the entire project and work within the boundaries of the pitch. The team is going to define their own tasks and their own approach to the work.

Teams love being give more freedom to implement an idea the way they think is best. Talented people don’t like being treated like “code monkey” or ticket takers. The designers and programmers doing the real work are in the best position to make changes and adjustments or spot missing pieces.

When teams are assigned individual tasks, each person can execute their little piece without feeling responsible for judging how all the pieces fit together.

They are giving teams absolute freedom to invent a solution from scratch. They’ve done the shaping. They’ve set the boundaries. Now they are going to trust the team to fill the outline from the pitch with real design decisions and implementation.

Done means deployed

At the end of cycle, the team will deploy their work. In the case of Small Batch team with a few small projects for the cycle, they’ll deploy each one as they see fit as long at it happens before the end of the cycle.

This constraints keep them true to their bets and respects the circuit breaker.

It also means any testing and QA needs to happen within the cycle. The team will accommodate that by scoping off the most essential aspects of the project, finishing them early and coordinating with QA.

Kick-off

They start the project by creating a new Basecamp project and adding the team to it. Then the first thing they’ll do is post the shaped concept to the Message Board. They’ll either post the original pitch or distilled version of it.

Since their teams are remote, they use the chat room in the Basecamp project to arrange a kick-off call.

The call gives team a chance to ask any important questions that aren’t clear from the write-up. Then, with a rough understanding of the project, they’re ready to get started.

Getting oriented

Work in the first few days doesn’t look like “work”. No one is checking off tasks. Nothing is getting deployed. Very less communication between the team in the first few days since each person has their head down trying to figure out how the existing system works and which starting point is best. Everyone is busy learning the lay of the land and getting oriented.

It’s important for managers to respect this phase, Teams can’t dive into code immediately. They need to think through pitch along side relevant code. Asking them status too early hurts the project. It takes away time that the team needs to find the best approach.

Imagined vs discovered tasks

Since the team was given the project and not tasks, they need to come up with the tasks themselves. Here they note an important difference between tasks they think they need to do at the start of a project and the tasks they discover they need to do in the course of doing real work.

The team get started with the imagined task, once they get their hands dirty, they discover all kind of other things that they didn’t know in advance.

Teams discover tasks by doing real work. For example, the designer adds a new button on the desktop interface but then notices there’s no obvious place for it on the mobile web-view version. They record a new task: figure out how to reveal the button on mobile.

Often a task will appear in the process of doing something unrelated. Suppose a programmer is working on a database migration. While looking at the model to understand the associations, They might run into a method that needs to be updated for a different part of the project later.They’re going to want to note a task to update that method later.

The way to really figure out what needs to be done is to start doing real work.

Get One Piece Done

As the team gets oriented, they start to discover and track the tasks they need to do to build the project. It’s important at this early phase that they don’t create a master plan of parts that should come together in the 11th hour. If the team completes a lot of tasks but there’s no “one thing” to click on and try out, it’s hard to feel progress. Lots of things are done but nothing is really done.

Instead they should aim to make something demoable early - in the first week or so.

Integrate one slice

We can think of project in two layers: front-end and back-end, design and code.

Suppose the project starts with a lot of design. The team could design a variety of screens and even implement them as templates or views. But until they’re wired to a backend, nothing does anything.

Same with the backend, A lot of tasks could be checked off, but without any UI - what can you do with it? How do you judge if the work of specific piece of business logic is really right without interacting with it?

What we want instead is to pick off one slice of the project to integrate. Then when that’s done, the team has something that they’ve proven to work. Anyone can click through the interaction and see if the feature does what it should and if what it does is what they want.

Case study: Clients in projects

They build a feature in Basecamp 3 that allowed service firms to invite clients to their projects and share chosen documents, messages, or to-do lists with them. The concept, defined in the pitch, had a variety of moving parts:

• Client Access: Before this feature, Basecamp’s access model was all or nothing. They needed a way to invite some people to see just some part of a project.
• Client Management: They needed a way to add clients to projects and the ability to manage clients separately from team members.
• Visibility Toggle: Each piece of content in a project should have a toggle to expose it to clients or not.

The team had one designer and one programmer. After they got oriented and familiar with how the existing code worked, the designer chose the visibility toggle as the best place to integrate first.

The designer didn’t make a pixel perfect mock-up. Instead, he experimented with different possibilities. Meanwhile, the programmer wan’t waiting around. He had enough guidance from the pitch to start spiking the access model.

As soon as designer felt confident in the basic direction of the User Interface, he pinged the programmer and ultimately programmer wired together to connect state, and save the state in database. Now it was appear on all the supported content types.

There was still more design work to do on the toggle, but the programmer didn’t need to be involved anymore. he can get back to his access model or whatever else was most important to tackle next.

About three days after the start of the project, the designer demoed the working toggle to a manager. Their conversation led to a few more tweaks and then they were able to call the toggle “done”. One important piece of project was designed, implemented, demoed, and settled.

Programmers don’t need to wait

Because the important moving parts were already defined in the shaping process, programmer don’t need to sit idle waiting for design when the project starts. Programmers can start working on foundational modeling decisions, while waiting for design.

Affordances before pixel-perfect screens

Programmers don’t need a pixel-perfect design to start implementing. All they need are endpoints: input elements, buttons, places where stored data should appear. These affordances are code of a user interface design.

The first interface a designer givers to a programmer can look very basic, like the example below. It’s more like breadboard than a visual design or a polished mock-up.

This screenshot if from a registration app form multi-day courses. The designer made it in HTML by hand. There’s barely any styles - just usable visual elements.

While the design looks simple, a lot of decisions are reflected in it.

• The decision to ask for arrival time but not departure time came from detailed discussion about the business logic and pricing model.
• The specific options in the arrival time pulldown correspond to rules that had to be worked out about when to charge for meals and overnight stays.
• The designer’s first sketches used a calendar-style date picker for the arrival and departure days. But led to UX problems.

Here’s another example. This is the first working piece of an app for capturing data from customer interviews.

At this early stage the project name (Basecamp) and interview subject (Jan) were hard-coded and most of the links didn’t go anywhere.

Look at how raw this design is. This design tests some important trade-offs. The designers chose to show as much data as possible above the fold so it would be easy to review interviews. Which prevented each section for UI to add, edit or remove data points. That led designer to create separate screens for adding and editing data per session.

This is the first design for adding and editing “pulls” - a type of data in this interview technique. Again, look at how raw it is. Bare minimum design to test functionality. Team can see if data is being accepted on the second screen or not. If it worked they can add additional styling later else they don’t waste a lot of time implementing a pixel-perfect design.

Beautiful alignment, colors and typography don’t matter on the first pass. At early stage the important thing is to understand if is it making sense, and how hard it will be to implement.

First make it work, then make it beautiful.

Program just enough for the next step

The same is true for back-end work. It doesn’t have to be all or nothing. The early back-end work can be strategically patchy. There might be a controller to render templates but no model. Screens that aren’t wired yet could at least be connected with routes for navigating between them.

When it was time to test the first piece of the interview app, the team knew there would be sensitive data from real interviews going into it. They needed to protect it with some kind of authentication. Rather than building full username and password support or even integrating a third-party solution, they just used plain HTTPAuth to hard-code a password.

This allowed the team to try adding data from real interviews very early in the cycle.

The point is create a back-and-forth between design and programming on the same piece of the product. Instead of one big hand-off, take turns layering in affordances, code, and visual styling. Step by step, click through the real working feature-in-progress to judge how it’s coming and what to do next.

Start in the middle

In the examples above, the team didn’t build login first. They didn’t build way to create an interview project and an interview subject before solving the problem of adding interview data. They jumped straight into the middle where the interesting problem was and stubbed everything else to get there.

To expand on this, here are three criteria to think about when choosing what to build first:

• It should be core. The visibility toggle was core to the Clients in Projects concept. In the interview app, recording interview data was more core - more in the middle - than setting up a new research project.
• It should be small. If the piece of work isn’t small enough, there isn’t much benefit to carving it off from the rest. The point is to finish something meaningful in a few days and build momentum.
• It should be novel. If two parts of the project are both core and small, prefer the thing that you’ve never done before. In Clients in Projects feature, the UI for adding client was mostly the same as UI for adding regular user. It could have moved the project forward but wouldn’t have taught the team anything.

Map the Scopes

Till now, we started the project by finishing one integrated slice early on. That practice belongs to a more general technique that the team can use throughout the project.

Organize by structure, not by person

When asked to organize tasks for a project, people often separate work by person or role: they’ll create a list for Designers and a list for Programmers. This can lead to problem when people complete tasks, but the tasks won’t add up to finished part of the project early enough.

In product development, the categories aren’t pre-cut for us. We usually build things we’ve never built before. We only identify what to slice a part by digging into the project, identifying inter-dependencies.

As we saw, the slices of work integrate front-end and back-end tasks. This allows us to finish one slice of the actual project and definitively move on.

They call these integrated slices of the project scopes. They break the overall scope of the project into separate scopes that can be finished independently. We will see how the team maps the project into scopes and tackles them one by one.

The scope map

Imagine an overhead view of the project. At the beginning, there’s just an outline from the shaping work that preceded the project. There aren’t any tasks or scopes yet.

When the team members take over the project, they start discovering tasks. Tasks are natural starting point because they’re concrete and granular. It’s enough at the start just to capture a variety of things that need to happen.

But we don’t want to stay with this picture for long. It’s too low-level. There’s nothing visible from high altitude.

As the team starts doing real work on the project, they learn how the tasks are related and what the structure of the project is really like. Then they become project into separate territories.

The scopes reflect the meaningful parts of the problem that can be completed independently and in a short period of time. They are bigger than tasks but much smaller than the overall project.

The map is mental image. In practice, they define and track the scopes as to-do list. Each scope corresponds to a list name. Then any tasks for that scope go in that list.

The language of the project

Scopes are more than just slices. They become the languages of the project at the macro level. When they were building the Clients in Projects feature, the team used the language of the scopes like this: “After Bucket Access if done we can implement Invite Clients. Then we’ll Update Recording Visibility when people on the firm flip the Visibility Toggle”.

At the time of reporting of the status, the team uses the languages of the scopes to explain what’s done and what’s not done. It’s good to have conversion at higher level instead of going down to individual outstanding tasks.

Case study: Message drafts

A designer are programmer were building a feature to create and save drafts of messages in a new app. After kick-off, they identified a bunch of tasks they would need to do at some point.

As the end of the first week, they had completed some of the tasks, but there wasn’t anything to show for their work. In the sprint of “get one piece done” they focused on one key interaction they could integrate: creating a new draft.

They called the new scope “Start New”, created a to-do list for it, and moved to-dos into it. There was only one design task left from them to consider this scope finished.

After finishing the one design task, the scope was complete.

The un-scoped tasks that are left don’t represent all the work that remains. More tasks are going to be discovered as they start working on each of those.

Taking a look at the tasks that were left, they decided to pull out tasks related to finding the drafts into a new scope called Locate and the task for deleting into a scope called Trash. The work that was left all seemed related to saving and editing the draft, so they called that Save/Edit.

In the Locate scope, there’s only one task there right now. But surely there will be more work to do than just designing the index. When there are implementation tasks to do, that’s where they’ll go.

The designer started some work on Locate while the programmer focused on Save/Edit. As Designer dug into it, they noticed they could carve off a couple pieces to make more visible progress. There were really three scopes in it.

First they factored out the work related to sending the drafted message. They called that Send.

Finally, some of the remaining Save/Edit tasks were about storing information and one other was actually unrelated - it was a special case for handling drafts when replying to another message. They broke these out into two new scopes: Store and Reply.

At this point the team suddenly felt like they could see the whole of the project at a high level.

Meanwhile, the designer had made progress on Locate. After a little wiring, they were able to mark that done. Tasks were getting done on Send and Store as well.

Once Send ans Store were finished, just a couple tasks remained for Trash and Reply.

And then the project was done.

Discovering scopes

Scope mapping isn’t planning, You need to walk the territory before you can draw the map. They reflect the real ground truth of what can be done independently.

Scopes arise from interdependencies. You don’t know what the work and interdependencies actually are in advance. As we saw imagined versus discovered tasks. The same principle applies to scopes. The scopes need to be discovered by doing the real work and seeing how things connect and don’t connect.

That’s why at the start of the project, we don’t expect to see accurate scopes. We’re more likely to see them at the end of week one or start of week two.

It’s also normal to see some shuffling in the scopes at first. The team might decide to move some scopes around and may be breaking down some as well.

How to know if the scopes are right

Well-made scopes show the anatomy of the project. When you feel a pain in your body, you don’t have to question whether it’s in your arms or your legs or your head. You know the parts and their names so you can explain where the pain is. In the same way, every project has a natural anatomy that arises from the design you want, the system you’re working within, and the interdependencies of the problems you have to solve.

Three signs indicate when the scopes are right:

1. You feel like you can see the whole project and nothing important that worries you is hidden down in the details.
2. Conversations about the project become more flowing because the scopes give you the right language.
3. When new tasks come up, you know where to put them, The scopes act like buckets that you can easily lob new tasks into.

On the other hand, these signs indicate the scope should be redrawn:

1. it’s hard to say “done” a scope is, often happens when the tasks or problems inside the scope are unrelated. Finishing one doesn’t get you closer to finishing the other. It’s good in this case to look for something you can factor out.
2. The name isn’t unique to the project like “front-end” or “bugs”. They call these “grab bags” and “junk drawers”. This suggests you aren’t integrating enough, so you’ll never get to mark a scope “done” independent of the rest. For example, with bugs, it’s better to file them under a specific scope so you can know whether, for example, “Send” is done or if you need to fix a couple bugs first before putting it out of mind.
3. It’s too big to finish soon. If a scope gets too big, with too many tasks, it becomes like its own project with all the faults of a long master to-do list. Better to break it up into pieces that can be solved in less time, so there are victories along the way and boundaries between the problems to solve.

Layer cakes

Most software projects requires some UI design and a thin layer of code below. Think of a database app where all you need to do is enter information, save it and display it back. Work like this looks like layer cake: You can judge the work by UI surface area because the back-end work is thin and evenly distributed.

This is a good default to most “information system” types apps.

Icebergs

But sometimes there is significantly more back-end work than UI work or vice versa. For example, a new feature that only requires submitting a form could require very complex business logic to return the right answer. This kind of work is like an iceberg.

For icebergs, it can help to factor out the UI as a separate scope of work. If the back-end is complex enough, you can split it into separate concerns and then turn those into scopes as well.

You can sometimes see upside-down icebergs, where there is a tons of UI complexity with less back-end complexity. For example, the data model for a calendar isn’t complicated, but the interaction for rendering a multiple-day event and wrapping across grid cell could take a lot of time and problem solving.

For both back-end and front-end icebergs, We always question them before accepting them as a fact. Do we really need that fancy UI? Is there a different way to build that back-end process so it has fewer interdependencies with rest of the system.

Chowder

There are always couple of things that don’t fit into a scope. We allow ourselves a “Chowder” list for loose tasks that don’t fit anywhere. If it’s longer than three to five items, something is fishy and there’s probably a scope to be drawn somewhere.

Mark nice-to-haves with ~

New tasks constantly come up as you get deeper into a problem. You’ll find code that could be cleaned up, edge cases to address and improvements to existing functionality. A good way to deal with all those stuff is to record them as tasks on the scope but mark them as a ~ in front. It differentiate must-have and nice-to-have.

In a world with no deadlines, we could improve everything forever. But in a fixed time box, we need to make trade-offs.

Show Progress

Good-hearted managers don’t like asking for status. Managers would rather be able to see the status themselves whenever they need to.

The tasks that aren’t there

Consider a list with a few completed items and no incomplete items left.

• This could mean that all the work is done. But it could also mean that the team knows there’s more work but hasn’t defined tasks yet.
• Sometimes, team will define a scope but yet to discover the task for the scope.
• Or think about doing some QA at the end of a scope. All the tasks are done but few more spawn up from testing process. This goes back to the notion of imagined versus discovered tasks. In our native notion of the list that’s planned up-front, somebody populates it with items that are gradually checked off. In real life, issues are discovered by getting involved in the problem. That means to-d- lists actually grow as the team makes progress.

If we tried to judge at t2 how far along the project is, we’d be misled. From an outsider’s perspective, there’s no way to know whether the number of outstanding tasks will go down or up.

Estimates don’t show uncertainty

Some teams try to attach estimates to their tasks or scopes to report status. The problem with estimate is they have a very different meaning depending on the nature of the work being estimated.

Suppose you have 2 tasks

• First task is something the team has done ten times in the past, you can be confident in the estimate.
• Second task is something the team have never done before. It could take four hours if all goes perfectly, but due to unknowns in it, it could stretch out to two to three days. It’s not meaningful to write “4 hours, or may be 3 days” as the estimate.

Recognizing this they came up with a way to see the status of the project without counting tasks and without numerical estimates. They do that by shifting the focus from what’s done or not done to what’s unknown and what’s solved. To enable this shift, they use metaphor of the hill.

Work is like a hill

Every piece of work has two phases.

• First there’s the uphill phase of figuring out what out approach is and what’s we’re going to do.
• Second is, once we can see all the work involved, there’s the downhill phase of execution.

Suppose you’re planning to host a dinner party, You’ve set the date, but it’s still couple of weeks ahead and you haven’t thought about what to cook yet. You’ve no idea about what type of mean will be or what dish to make. That would place you at the start of the hill on the bottom-left.

Next you think about who’s attending and note that couple of people are vegetarian. That eliminates some options but you still have couple of options left. You consider both Italian and Indian. You think Indian might be more fun to cook, with more interesting vegetarian options. So you decide to cook Indian Recipes.

At this point, if someone ask you to estimate, the answer would be: “I’ve done some work to figure out what kind of cuisine, but I haven’t narrowed down to a specific dish yet.”. We can represent that by putting you halfway up the “figuring it out” side of the hill.

Next you do some searching online and look through your recipe books. You want to find a recipe that will be interesting but doesn’t require ingredient that will be too hard to find. You settle on a recipe and prepare a shopping list.

Now you are in very different position than before. the feeling changes from “I’m still not sure what I’m doing” to “Now I know what to do.” You’re at the top of the hill.

From this vantage point, you can see of the steps that are left. It’s even fair to estimate how long all the work will take.

The day before the dinner party, you go to grocery store and buy the ingredients. This moves you downhill. You’re closer to finishing the task.

Next comes the work of prepping and cooking the meal.

After the mean if over, there’s just a little work left: the clean-up.

Note, how the hill shows how the work feels at different stages. The uphill phase is full of uncertainty, unknowns, and problem solving. The downhill phase is marked by certainty, confidence, seeing everything and knowing what to do.

Scopes on the hill

We can combine the hill with the concept of scopes from the last chapter. The scopes gives us the language for the project (“Locate”, “Reply” - from the last chapter) and the hill describes the status of each scope (“uphill”, “downhill”).

To see the status of the scopes, we can plot each one as different color on the hill.

This is a snapshot from a project to implement recurring events in Basecamp. Here “Future-applying edits” is a scope that is still being worked out, with significant unknowns to solve. The other two scopes have no meaningful unknowns left, and “Global recurring events” is closer to finished.

Status without asking

They build a feature exclusive to Basecamp for creating hill charts and updating them with a few clicks. The team members, who have the full context of where the work stands, drag the scopes into position, and save a new update that’s logged on the project.

From managers, the ability to compare past states is the killer feature. It shows not only where the work stands but how the work is moving.

Now, managers don’t need to ask question on status to any team member, they can see this report and identify the time it’s taking for scopes to move, moving from unknown to known to done, etc.

Nobody says “I don’t know”

Nobody wants to raise their hands to management and say “I don’t know how to solve this problem.” We don’t want to hide the unknowns, because they often leads to delay into the cycle.

The hill chart allows everybody to see that somebody might be stuck without them actually saying it. A do that doesn’t move is effectively a raised hand: “Something might be wrong here.”

Once it’s spotted, the language of uphill/downhill facilitates the conversation. It’s less about the person and more about the work. The question is: What can we solve to get that over the hill?

Prompts to refactor the scopes

Sometimes probing into a stuck scope reveals that it isn’t stuck at all. The problem is in how the lines of the scope were drawn.

Here’s case where the “Notify” scope was stuck on the hill for too long.

When they checked in with the team, It turned out the work was moving along just fine. The problem was that “Notify” wan’t a single thing. It was combination of multiple parts. The team mostly finished the one part of it. Due to few other parts it was not considered at the top of the hill.

The solution in a case like this is to break the scope apart into smaller scopes that can move independently.

Now the team can move each dot to accurately show where the work stands.

The benefit comes at the second order. With the scopes separated out, they can move independently over time. now the team can show more progress more frequently than before.

Build your way uphill

Some teams struggle with backsliding when they first try the hill chart. They consider a scope solved, move it the top of the hill, and later have to slide it back when they uncover an unexpected unknown.

When this happens, it’s often because somebody did the uphill work with their head instead of their hands. Coming up with an approach in your head is just the first step uphill. Reality may turns out to be more complicated.

Solve in the right sequence

In addition to seeing where the work stands, we can use the hill chart to sequence the work - which problems to solve in which order.

Some scopes are riskier than others. Imagine two scopes: One involves something that team has never done before. The other is something that teams has done multiple times. Both have unknowns and start at the bottom of the hill. But Team will be pretty confident about the second scope.

Work expands to fill time available. If the team starts with the email template first, they could easily spend weeks iterating on copy or creating the ultimate best-ever email design. But they don’t need to do that. There’s some version of an email template that could be worked out in a day during the final week and it would be sufficient. On the other hand (something that team has never done), might present novel problems that the team could struggle with for weeks. They don’t want that surprise to come at the end of the cycle.

Journalists have a concept called the “inverted pyramid”. The idea is their articles start with the most essential information at the top, then they add details and background information in decreasing order of importance. This allows print newspaper designer to get the crucial part of the story on the front page and cut the end as needed without losing anything essential.

Effective teams sequence their problem solving in the same way. They choose the most important problems first with the most unknowns, get them to the top of the hill, and leave the things that are most routine or least worrisome for last.

As the end of the cycle approaches, teams should have finished the important things and left a variety of “nice to haves” and “maybes” lingering around.

Decide When to Stop

Shipping on time means shipping something imperfect. There’s always something in the stomach as you look at your work and ask yourself: Is it good enough? Is this ready to release?

Compare to baseline

Designers and programmers always want to do their best work. Designer wants to have their best attention on a button center to the landing page or down to setting screen, and similarly for programmers, they wants to cover each edge case.

Pride in the work is important for quality and morale, but we need to direct it at the right target. How do we make the call to say what we have is good enough and move on?

It helps to shift the point of comparison. Instead of comparing up against the ideal, compare down to baseline - the current reality for customers. How do customers solve this problem today, without this feature? What’s the frustrating workaround that this feature eliminates? How much longer should customers put up with something that doesn’t work or wait for a solution because we aren’t sure if design A might be better than design B?

Seeing that our work is better than the current alternatives makes up feel better about the progress we’ve made. This motivates us to make call on the things that are slowing us down. It’s less about us and more about value for customer. We can say “Okay, this isn’t perfect, but it definitely works and customers will feel like this is a big improvement for them”.

Limits motivate trade-offs

If the work doesn’t get done, the project doesn’t happen (circuit-breaker - from past chapter).

This forces the team to make trade-offs. When somebody says “wouldn’t it be better if…” or finds another edge case, they should first ask themselves: Is there time for this? Without a deadline, it could easily delay the project for changes that don’t actually deserve the extra time.

We expect our teams to actively make trade-offs and question the scope instead of cramming and pushing to finish tasks. We create our own work for ourselves. We should question any new work that comes up before we accept it as necessary.

Scope grows like grass

Scope grows naturally. Scope creep isn’t the fault of bad clients, bad managers, or bad programmers. Projects opens up new details when you get down into the work.

Every project is full of scope, we don’t need. Every use case isn’t equally common, equally critical, or equally aligned with the market we’re trying to sell to.

This is how it is, Rather than trying to stop scope from growing, give teams the tools, authority and responsibility to constantly cut it down.

Cutting scope isn’t lowering quality

Picking and choosing which thing to execute and how far to execute on them doesn’t leave holes in the product. Making choices makes the product better.

Variable scope is not about sacrificing quality. They are extremely picky about the quality of our code, our visual design, the copy in our interfaces, and the performance of our interactions.

Scope hammering

People often talk about “cutting” scope. They use an even stronger work hammering to reflect the power and force it takes to repeatedly bang the scope so it fits in the time box.

As they come up with things to fix, add, improve or redesign during a project, they ask themselves:

• Is this a “must-have” for the new feature?
• Could we ship without this?
• What happens if we don’t do this?
• Is this a new problem or a pre-existing one that customers already live with?
• How likely is this case or condition to occur?
• When this case occurs, which customers see it? Is it core - used by everyone - or more of an edge case?
• What’s the actual impact of this case or condition in the event it does happen?
• When something doesn’t work well for a particular use case, how aligned is that use case with our intended audience?

The fixed deadline motivate them to ask these questions. Variable scope enables them to act on them. By hammering the scope down, they stay focused on just the things they need to do to ship something effective that they can be proud of at the end of the box.

Nice-to-haves are marked with tilde (~) in front. Those tasks are things to do if the team has extra time at the end.

QA is for the edges

QA can limit the attention to edge cases because the designers and programmers take responsibility for the basic quality of their work.

For years Basecamp didn’t have a QA role. Then after their user base grew to a certain size, they saw that small edge cases began to impact thousands of users in absolute numbers. That point they added just one QA.

That’s why they think of QA as a level up, not a gate or check-point that all work must go through.

At Basecamp the team can ship without waiting for code review. There’s no formal check-point. But code review makes things better, so if there’s time and it makes sense, someone senior may look at the code and give feedback.

When to extend a project

In very rare cases, they extend a project that runs past its deadline by a couple weeks. How do they decide when to extend a project and when to let the circuit breaker do its thing?

• The outstanding tasks must be true must-haves that withstood every attempt to scope hammer them.
• The outstanding work must be all downhill. No unsolved problems; no open questions. Any uphill work at the end of the cycle points to an oversight in the shaping or a hole in the concept.

Even if the conditions are met to consider extending the project, they still prefer to be disciplined and enforce the appetite for most projects. The two-week cool-down usually provides enough slack for a team with a few too many must-haves to ship before the next cycle starts.

Move On

Let the storm pass

Shipping can actually generate new work if you’re not careful. Feature releases produce feature requests. Customers say “Okay, that’s great, but what about that other things we’ve been asking for?” Bugs pop up.

The feedback can be especially intense if the feature you shipped changes existing workflows. Few customers might say “You ruined it! Change it back!”.

It’s important to stay cool and avoid knee-jerk reactions. Give it a few days and allow it to die down.

Stay debt-free

It can be tempting to commit to making changes in response to feedback, but then you no longer have a clean slate for the next cycle.

The thing you just shipped was a six-week bet. If this part of the product needs more time, then it requires a new bet. Let the requests or bugs that just up compete with everything else at the next betting table to be sure they’re strategically important.

Feedback needs to be shaped

Here we come full circle. The raw ideas that just come in from customer feedback aren’t actionable yet. They need to be shaped. They are the saw inputs that we saw in the shaping process (Set Boundaries).

If a request is truly important, you can make it your top priority on the shaping track of the next cycle. Bet on something else for the teams to build and use that time to properly shape the new idea. Then, when the six weeks are over, You can make the case at the betting table and schedule the shaped version of the project for the greatest change of success.