This book is a guide to how 37signals does product development. It’s also a toolbox full of techniques that you can apply in your own way to your own process.
Don’t think of this as a book. Think of it as a flashlight. You and your team have fumbled around in the dark long enough. Now you’ve got something bright and powerful to help you find a new way.
- Jason Fried
Principles of Shaping
The shaped work should be at the right level of abstraction: not too vague and not too concrete. It should tell you what the finished product work will look like when it’s done.
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.
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?
Work in six-week cycles. Long enough to build something meaningful start-to-finish and short enough to feel the deadline, use it wisely and not squander.
Ship something meaningful at the end. Outcome at the end of the cycle: one complete, coherent piece of work. Instead of building lots of disconnected parts and hoping they’ll fit together in the end, build one meaningful piece of the work end-to-end early on and then repeat. Integrate as soon as possible.
Shaping the work. Define the key elements of a project/problem and the solution before taking it on. Concrete enough that teams know what to do, yet abstract enough to allow individual creativity.
Integrated design and programming. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat.
At the end of the cycle, there’s something meaningful finished.
Shape the work before you start working on it, at the start of the cycle. This is where you narrow down the problem and design the outline of a solution that fits within the constraints of your appetite.
- Define the key elements of the solution
- Concrete enough to know what to do, yet abstract enough to have creativity
- Focus on your appetite. How much time do you want to spend?
- Write the pitch. The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations.
Steps to shaping
Set boundaries. Figure out how to define the problem and how much time you are going to spend on it.
Sometimes an idea gets us excited right away. Temper the excitement by checking whether this is really something you’re going to be able to invest time in or not.
If we don’t stop to think about how valuable the idea is, we can all jump too quickly to either committing resources or having long discussions about potential solutions that go nowhere.
Don’t estimate, have an appetite. Estimates start with a design and end with a number. Appetites start with a number and with a design. Have fixed time but variable scope.
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.
It’s critical to always present both a problem and a solution together. It sounds like an obvious point but it’s surprising 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.
Fixed Time, Variable Scope
Estimates start with a design and end with a number. Appetites start with a number and end with a design.
This principle, called “fixed time, variable scope” is key to successfully defining and shipping projects. Take this book for an example. It’s hard to ship a book when you can always add more, explain more, or improve what’s already there.
When you have a deadline, all of a sudden you have to make decisions. With one week left, I can choose between fixing typos or adding a new section to a chapter. That’s the tension between time, quality, and scope. I don’t want to release a book with embarrassing typos, so I’ll choose to reduce the scope by leaving out the extra section.
Without the pressure of the fixed deadline, I wouldn’t make the trade-off. If the scope wasn’t variable, I’d have to include the extra section. Then there’d be no time to fix the quality issues.
Find the Elements
Be concrete enough to make progress on a specific solution without getting dragged down into fine details.
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 within the appetite but without all the fine details worked out.
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?
Write a Pitch
A pitch is a formal write-up that summarizes the problem, constraints, solution, rabbit holes, and limitations.
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 and do the work to make an informed bet.
There are five ingredients that we always want to include in a pitch:
- Problem — The raw idea, a use case, or something we’ve seen that motivates us to work on this
- Appetite — How much time we want to spend and how that constrains the solution
- Solution — The core elements we came up with, presented in a form that’s easy for people to immediately understand
- Rabbit holes — Details about the solution worth calling out to avoid problems
- 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
Doing the Work
The way to really figure out what needs to be done is to start doing real work. That doesn’t mean the teams start by building just anything. They need to pick something meaningful to build first. Something that is central to the project while still small enough to be done end-to-end—with working UI and working code—in a few days.
Get one piece done. You can do a lot of work but feel insecure because they don’t have anything real to show for it yet. Lots of things are done but nothing is really done.
Instead you should aim to make something tangible and demoable early—in the first week or so. That requires integrating vertically on one small piece of the project instead of chipping away at the horizontal layers.