I made my way through Shape Up last month and really enjoyed it. Shape Up is a methodology for product development teams put together by Ryan Singer and the folks at Basecamp. The focus is on language and techniques to help better define projects, address unknowns, and increase collaboration and engagement on your team. These are my notes and takeaways.

This book is about the risk of getting stuck, the risk of getting bogged down with last quarter’s work, wasting time on unexpected problems, and not being free to do what you want to do tomorrow.

Shaping

Shaping is the pre-work we do on projects before we consider them ready to schedule. This work needs to be at the right level of abstraction. Not too vague and not too concrete.

  • Wireframes are too concrete and words are too abstract. Live in the middle of those extremes.
  • Something is shaped when it's rough, but solved and bounded.
  • Shaping is a combination of strategy and design. You'll either need a generalist that can do both or a collaboration between PM + Design for this phase.
  • Part of shaping is setting boundaries. Narrow down the problem and define the appetite. This is how much time and attention the subject deserves.
  • From a tactics standpoint, use breadboarding and fat marker sketches to help visualize, at the right level of fidelity, how you propose to solve the problem.
  • Remove unknowns and tricky problems from the project so that you can be confident it the team's ability to deliver in the set time.
  • Once the project is de-risked and defined, write up a pitch to present to others.
  • This pitch should include problem definition, appetite, your solution, calling out rabbit holes, and explicit non-goals.

Betting

Once the work is adequately shaped, you need to figure out where to place your bets. When resources are constrained, and they always seem to be on product teams, prioritization is key.

  • Don't keep a huge backlog. Review a small batch of ideas every 6 weeks and decide which you should prioritize. If an idea is good then it will come back up.
  • Use 6-week cycles. They are long enough to finish something meaningful and still short enough to see the end from the beginning.
  • After each six-week cycle, schedule two weeks for cool-down. This is a period with no scheduled work where we can breathe, meet as needed, and consider what to do next. Developers and designers can work on whatever they please during this time.
  • Keep team sizes small and "betting table" meeting attendees even smaller.
  • We use the term "betting" because that means there's a payout and a commitment.
  • Handle bugs using the cooldown period or scheduled bug smashes.
  • It's important to give yourself a clean slate every cycle. That means only betting one cycle at a time and never carrying work over from the previous cycle.
  • Questions to ask at the betting table: Does the problem matter? Is the appetite right? Is the solution attractive? Is this the right time? Are the right people available?

Building

Now that the work is shaped and you have chosen your bets for the upcoming cycle, it's time to get to building. For product people, this phase is about the expectations we place on teams and the practices for execution.

  • Assign projects, not tasks. Trust the team to define their own tasks and approach to the work. Give them full autonomy to execute the spec best they can.
  • Teams must test and deploy their work within the cycle. Anything that doesn't get finished doesn't automatically get carried over to the next cycle.
  • Empower teammates to be able to say “I’m still figuring out how to start” so they don’t have to hide or disguise this legitimate work.
  • Pick off one slice (frontend + backend) of a project to integrate and show tangible progress as early on as possible.
  • Organizing a project into these slices early on helps your team move faster and with more confidence.
  • Scopes are in-danger of being inaccurate if it's hard to determine progress or if the name isn't unique to the project e.g. "frontend" or "bugs"
  • Programmers shouldn't need to sit and wait for design if there's enough direction in the pitch for them to start with backend problems.
  • Differentiate between must haves and nice-to-haves when breaking out a pitch into specific tasks or slices.
  • Work has two phases. First is the uphill phases of figuring out what our approach is and what's we're going to do. Then, once we can see the work ahead, there's the execution phase.
  • It’s better to get a few critical scopes over the hill early in the project and leave the screw-tightening for later.
  • Instead of comparing up against the ideal, compare down a baseline of the current reality for customers.
  • Take customer feedback and use it as raw inputs for the next shaping process.

Thanks for reading! If you enjoyed this post, you can subscribe in the form below to get future ones like it delivered straight to your inbox. If Twitter is more your speed, you can follow me there as well. 🔥