Shaping has four main steps that we will cover in the next four chapters.

1. Set boudaries. First we figure out how much time the raw idea is worth and how to define the problem.

2. Rough out the elements. Then comes the creative work of sketching a solution. We do this at a higher level of abstraction than wireframes in order to move fast and explore a wide enough range of possibilities. The output of this step is an idea that solves the problem with 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 holes or unanswered questions that could trip up the team. We amend the solution, cut things out of it, or specify details at certain tricky spots to prevent the team from 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 a pitch. The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. The pitch goes to the betting table for consideration. If the project gets chosen, the pitch can be reused at kick off to explain the project to the team.

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. During any six week cycle, the teams are building work that's been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment has been made to bet on it.

That gives the shapers the option to put work in progress on the shelf or drop it when it's not working out.

Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There'll be rough diagrams in front of you that nobody outside the room would be able to interpret. 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.

It's 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?

Knowledge about how the system works will help you see opportunities or obstacles fro implementing your idea.

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 flows.

• what the feature does
• how it works
• where it fits into existing flows

When a project is defined in a few words, nobody knows what it means. "Build a calendar view" or "add group notifications" sound sensible, but what exactly do they entail?

Team membres don't have enough information to make trade-offs.

Principles of Shaping

When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes.

To manage this new capacity, we switched from ad-hoc project lengths to repeating cycles. (It took some experimentation to find the right cycle length: six weeks. More on that later.)

We formalized our pitching and betting processes.

My role shifted again, from design and product management to product strategy.

I needed new language, like the word "shaping", to describe the up-front design work we did to set boudaries and reduce risks on projects before we committed them to teams.

Don't think of this asa a book. Think of it as a flashlight. You and your team have fumbled in the dark long enough. Now you've got something bright and powerful to help you find a new way.

Founders ask themselves: "why can't we get features out the door like we used to in the early days?" 创始人问自己“为什么我们不能像早期那样把功能推出去？”

At the time I wasa a web designer with a focus on usability and user interfaces. I executed Json's design direction for key features of the app and collaborated with him to fill in details of the concept.

We knew we wouldn't get anywhere with those ten hours of programming unless we used them very deliberately. Our intense focus on "hammering" the scope to fit within a given time budget was born under these constraints.

I learned the techniques programmers use to tame complexity: things like factoring, levels of abstraction, and separation of concerns.

with one foot in the design world and one foot in the programming world, I wondered if we could apply these software development principles to the way we designed and managed the product.

I wore the designer and product manager hats on the project and prototyped the breadboarding and scope mapping techniques described in this book to manage the complexity.

...we redesigned Basecamp from scratch for version 2.0.

We needed language to describe what we were doing and more structure to keep doing it at our new scale.