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.