This book is a guide to how 37signals (creators of Basecamp and HEY) does product development. It’s also a toolbox full of techniques that you can apply in your own way to your own process and projects.
What I most like from the book is the fact that it's not written by some project management consultants or architecture astronauts, but real practitioners who've consistently shipped successful software (both commercial and technical) over the past two decades and have built real businesses. Like Ruby on Rails, a web framework derived from the real, working applications, Shape Up is distilled from the real project management practices that 37signals have used over many years.
I first read this book as soon as it was published a few years ago, and have been using some form of it on my personal projects ever since. However, I recently started working on a software project that uses Shape Up practices, and felt it was time for a re-read to refresh my memory. So here it goes. Whether you’re a founder, CTO, product manager, designer, or developer, I’m sure you’ll find valuable advice to manage your projects better.
Note: What follows are not my thoughts, opinions and interpretations, but just a copy + paste of my notes and highlights taken straight from the book. Hence, it won't follow a logical structure and you may even find my writing scattered. But it's just to give you a taste of the big ideas, and anyway, you should read the whole book. It's free.
Shape-Up Principles
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 do not squander.
Shape 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.
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. At the end of the cycle, there’s something meaningful finished.
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.
Shape Your Work
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.
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. Despite being rough and unfinished, shaped work has been thought through. It’s solved. There are no major unknowns.
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?
Steps to Shaping
- Set boundaries. Output: The problem definition and the appetite (how much time do you want to devote to this?)
- Rough out the elements. Output: An idea that solves the problem within the appetite at a higher level of abstraction.
- Address risks and unknowns: Output: Refined solution after taking a hard look at it, to find holes or unanswered questions.
- Write the pitch: Output: A formal write-up summarizing the problem, constraints, solution and unknowns.
Set Boundaries
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. Start with a raw idea. But don’t jump head-first into discussing the solutions.
- Set an appetite. Explicitly define how much of our time and attention the subject deserves. This is your appetite: a time budget. Appetite acts as a creative constraint on the design process. You start with the deadline and adjust the scope. This principle, called “fixed time, variable scope” is key to successfully defining and shipping projects. When you have a deadline, all of a sudden you have to make decisions.
- Narrow down the problem. If the scope of the idea is so big that a fixed cycle isn’t possible, try to hammer it down by narrowing the problem definition. If you can’t shrink the scope, break off a meaningful part of the project that you can shape to your appetite.
Estimates start with a design and end with a number. Appetites start with a number and end with a design.
Find the Elements
Be concrete enough to make progress on a specific solution without getting dragged down into fine details. Ask questions like:
- 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?
After this step, you’ve gone from a cloudy idea to a specific approach and a handful of concrete elements. We’ve landed on an approach for how to solve the problem. There may still be some significant unknowns or things we need to address before we jump into implementation.
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.
Address Risks and Unknowns
In this step, you look critically at the elements. Did you miss anything? Are your assumptions correct? 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.
Remember that you’re shaping work for a fixed cycle. All it takes is one hairy unknown to derail your project. Before we consider it, a shaped project should be as free of holes as possible. Remove as many unknowns and tricky problems from the project as possible. Trade-offs are difficult to make when you’re working on the project under pressure. However, at the design phase, they are much easier to make.
Walk through a use case in slow motion. Given the solution you sketched, how exactly one would get from the starting point to the end? Slowing down and playing it out can reveal gaps or missing pieces that you need to redesign.
When you write the pitch for the project, point out the risks and unknowns along with the trade-offs and solutions.
Declare what you won’t work on. What’s out of bounds. Call out use cases you aren’t supporting to keep the project well within the appetite. There may be parts of the soultion you got excited about during sketching that aren’t really necessary. Cut them out to fit the project within the scope.
Get the review from the technical experts or the implementers. Verify the technical assumptions. You want to find out if the project is feasible technically, within the appetite. Instead of asking “is it possible to do X” ask “is X possible to build within 2-weeks?”. Explain them the concept from the beginning.
After this step, you’ve gone from a roughly formed solution with potential risks to a solid idea that you can bet on in the future.
Write the Pitch
Spell out the solution and communicate the boundaries so that people with less context can understand and evaluate it. There are five ingredients you want to include in a pitch:
- Problem - The raw idea, a use case for the feature
- 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 understand
- Risks and Unknowns - Solution details worth calling out to avoid problems
- No-gos - Anything related but specifically excluded from the solution to narrow the scope of the project
Problem: Diving straight into the solution is dangerous. Without a specific problem, there is not test of fitness to judge whether one solution is better than the other. The best problem definition consists of a single specific story that shows why the current status quo doesn’t work. This gives you a baseline to test the new state against. You can judge whether or not that story has a better outcome with the new solution.
Appetite: Not only do we want to solve this use case, but we want to come up with a solution that fits within our cycle. Stating the appetite prevents unproductive conversations or bike shedding. Anybody can suggest expensive and complicated solutions. It takes work and design insight to get to a simple idea that fits in a small time box.
Solution: A problem without a solution is unshaped work. Directly starting the implementation means pushing research and exploration down to the wrong level, where skillsets, timeframes, and risks are all misaligned. If the solution isn’t figured out, someone should go back and do the shaping work. It’s only ready to bet on when problems, appetites, and the solution come together.
Risks and Unknowns: Address the unknowns. Call out potential solutions and trade-offs. Spell them out in detail. What could go wrong?
No-Gos: Mention if there’s anything we’re not doing in this concept.
Building - 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.
In product development, the categories aren’t pre-cut for us. We usually build things we’ve never built before. Each project is a wild territory that we have to walk through before we can draw a map. By digging into the work, we figure out where the interdependencies are, how things are connected, and what we can slice apart.
Assign projects, not tasks. We want the project to stay “whole” through the entire process so we never lose sight of the bigger picture.
Done means deployed. At the end of the cycle, the team will deploy their work. This constraint keeps us true to our bets and respects the circuit breaker. The project needs to be done within the time we budgeted; otherwise, our appetite and budget don’t mean anything. That 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.
Get one piece done.
It’s important at this early phase that you 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. You can do a lot of work but feel insecure because you 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.
Beautiful alignment, colors, and typography don’t matter on the first pass. Visual styling is important in the end product, not in the early stages. The biggest uncertainties are about whether it will work, whether it will make sense, and how hard it will be to implement. After the elements are wired up, they can be rearranged, restyled, and repainted to improve the work that’s already done. First make it work, then make it beautiful.
Program just enough for the next step. The point is to 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. Jump straight into the middle where the interesting problem is and stub everything else to get there. Follow three criteria to think about when choosing what to build first:
- It should be core. Without it, the other work wouldn’t mean anything.
- It should be small. The point is to finish something meaningful in a few days and build momentum.
- It should be novel. Prefer the thing that you’ve never done before, to eliminate uncertainty and to prove that the new idea is going to work.
Organize by structure / feature, not by person. Create lists based on features, the things that can be worked on and finished independently of each other. Then you can easily see which areas are done and which areas have outstanding work. Call these integrated slices of the project ‘scopes’. Break off the overall scope of the project into separate scopes that can be finished independently of each other and in a short period of time. They are bigger than tasks but much smaller than the overall project.
Scopes let you to have the conversation at a high level nad point to finished features, instead of going down into the weeds showing each task.
Solve in the right sequence. Some scopes are riskier than others. Ask yourself: If you’re out of time at the end of the cycle, which problem could you solve easily, and which might prove to be harder than you think? It’s better to get a few critical scopes over the top early in the project and leave the screw-tightening for later.
AS the end of the cycle approaches, you should have finished the important things and left a variety of “nice to haves” and “maybes” lingering around.
Decide when to stop.
Instead of comparing up against the ideal, the best design, the best programs, 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?
Scope Hammering
- As we come up with things to fix, add, improve, or redesign during a project, we ask ourselves:
- 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?
Seeing that our work so far is better than the current alternatives makes us feel better about the progress we’ve made. This motivates us to make calls on the things that are slowing us down. It’s less about us and more about value for the customer. It’s the difference between “never good enough” and “better than what they have now.” We can say “Okay, this isn’t perfect, but it definitely works and customers will feel like this is a big improvement for them.”
If you enjoyed this small taste of the book so far, I highly recommend you read the full book, as it contains many examples from real projects, from idea to a finished feature. Also, pair the book with this recent Rails World talk from Ryan Singer, author of Shape Up.
That's a wrap. I hope you found this article helpful and you learned something new.
As always, if you have any questions or feedback, didn't understand something, or found a mistake, please leave a comment below or send me an email. I reply to all emails I get from developers, and I look forward to hearing from you.
If you'd like to receive future articles directly in your email, please subscribe to my blog. Your email is respected, never shared, rented, sold or spammed. If you're already a subscriber, thank you.
