Bootstrappers.io

A site for bootstrappers the world over

Reading Notes: “Shape Up” Product Development by Basecamp

blog ·

What you see below are my personal notes from reading Shape Up, a book on product development written by the folks at Basecamp.

I want to emphasize that these are my personal takeaways from an initial reading, so they are colored by my own interpretation of the lessons that were taught by the original author(s).

If you are at all interested in the topic, I highly recommend that you also read the original source referenced below and form your own opinions about how these concepts may or may not benefit your business.

Happy reading!

Original Source: https://basecamp.com/shapeup/

Introduction

Six Week Cycles

  • Six weeks is long enough to build something meaningful from scratch, but short enough that team members feel the push of a looming deadline from the start
  • Zero micromanagement or near-field thinking. The focus is “If we ship this feature/project in six weeks, that will be a win. Time well spent.”

Shaping the Work

  • Senior group establishes the original direction with a focus on making things concrete enough to understand, but abstract enough to leave room for creative solutions
  • Focus less on estimates and more on appetite (Ex: How long will this take? Vs. How much time to we want to invest in this?)
  • Ultimate goal…address the problem by mapping out a solution that fits within the constraints of our appetite

Targeting Risk

  • Focus on targeting a single risk: Not shipping on time
  • Combat roadblocks, distractions, and overextensions
  • Strategies:
    • Complete the shaping process…don’t hand over a half-baked idea
    • Cap your investment…six week cycles eliminate the big loss
    • Collaborate early and often…integrate design/dev early to ensure alignment

Principles of Shaping

  • Wireframes and mock-ups are too specific. You can’t hand that off and still ask someone to think creatively.
  • Words alone are too abstract. Context is important to building the RIGHT solution
  • The key is to be more specific about the “words” (aka requirements/functionality) and less specific about the “structure”
  • A “back of the napkin” sketch is usually the right level of fidelity to hand off to your design/dev team
  • People need to know that it’s rough…they need to see the areas where their contributions will go
  • Despite being rough, it should also appear “solved.” It’s clear what this feature will do and what elements are required to make that happen
  • It’s also bounded. There are guardrails around what is “in play” and what is out of scope
  • Shaping is primarily design work, but if helps to have a certain level of technical literacy. A customer-centric perspective is a must and solid critical thinking skills
  • This is a closed door activity done with a very small group. While that “Shapers” are roughing out a new idea, the “builders” are working on something in parallel
  • At the end, you should also draft up a brief pitch that can be taken to the “betting table” and later used during the kick-off meeting if the idea gets a green light

Set Boundaries

  • It is important to temper excitement about a new idea. Think critically about how valuable the idea really is for the business and our customers
  • Step 1 is to determine our “appetite” for how much we are willing to invest in this idea, based on the scope and value
    • Small batch = < 3 people working for 1-2 weeks (these get batched together to fill a six-week cycle)
    • Big batch = < 3 people working for a full 6 weeks
  • Follow a principle called “fixed time, variable scope.” A firm deadline forces you to consider tradeoffs in order to avoid missing your ship date
  • “Good” and “best” are relative. There is always something that can be done better, but if it never sees the light of day then what’s the point? DONE is better than PERFECT.
  • Default response to new ideas is “Interesting. Maybe some day.” They don’t even keep a backlog, but let ideas continue to bubble up organically until they HAVE to be addressed

Find the Elements

  • There are two elements to moving at the right speed in this stage:
    • Having the right people—or nobody—in the room. We need people who have the same background knowledge, can be frank about opinions, and understand each other in shorthand.
    • Second, we need to avoid jumping straight to concrete solutions (Ex: wireframes). We should explore as broadly as we need to and narrow down.
    • Start with elements, not layouts:
      • Places: things you can navigate to like screens or pop-ups
      • Affordances: things you can act on like buttons or fields
      • Connection Lines: illustrations of how affordances take you to places
    • Example of their design process. Start with words, not graphics. Places are underlined, with affordances underneath each place and lines to indicate connections.

    •  “Fat marker sketches” are for problems that require a 3D assessment. Using a fat-tipped Sharpie prevents you from getting caught up in the details and encourages big picture thinking
    • Page elements are the output, not the starting point. Once you determine the required affordances you can start mapping graphical elements to them
    • The end result of this process is still vague enough that a designer doesn’t experience much bias or influence when you hand it off
    • The end product is often still indecipherable to anyone who wasn’t in the room when it was produced

Risks and Rabbit Holes

  • We should do everything we can to poke holes in our proposal BEFORE it ever reaches the builders. Otherwise, we risk losing valuable time or abandoning the project altogether.
  • Ask yourself if you are missing anything? Did you make any technical assumptions that aren’t reasonable or fair?
  • One strategy is to walk through a single use case in slow motion
    • Does this require new technical work we’ve never done before?
    • Are we making assumptions about how the parts 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?
  • It is natural for team members to explore all kinds of use cases and consider it necessary to address each one – don’t give in easily!
  • It is always important to call out use cases you ARE NOT supporting with this project in order to keep it within the scope and appetite that was outlined
  • As you put specific components through the ringer, set aside the “nice-to-haves” as a list of things that could possibly be incorporated if time and scope allow
  • This is the point where it is okay to bring in a trusted technical advisor and walk them through the concept to help you scrutinize the proposal
  • It is important to remember that pretty much anything is possible to do with technology. The better question to ask is “Is this possible to do in a 6-week project?”

Write The Pitch

  • The purpose of the pitch is to present something that is a “good potential bet”
  • The five ingredients of a good pitch:
    • Problem: The reason we’re working on this idea in the first place
    • Appetite: How much time we want to spend and how it constrains the solution
    • Solution: The core elements we’ve produced through scoping and de-risking
    • Rabbit Holes: Details worth calling out to avoid delays or implosions
    • No-Gos: Anything specifically excluded from the concept like features, functionality, or edge cases
  • It’s always critical to present a problem and a solution together. You’d be surprised how many teams just jump straight into the solution
  • Stating the appetite prevents unproductive conversations about how things could be better
  • We should present the solution (graphically) in a little more concrete manner than we did before. It should still be high level, but people who read the pitch should “get” the idea quickly
  • They prefer asynchronous work, so pitching starts with posting the pitch somewhere publicly available where folks can review on their own time
  • People comment on the pitch, not with a “yes” or “no,” but to poke holes in the concept or contribute missing information

Bets, Not Backlogs

  • Backlogs are a huge weight to carry and often leave us feeling behind, overwhelmed, and ineffective
  • Instead, prior to each six-week cycle they hold a “betting table,” where stakeholders come together to decide what to do in the next cycle
  • The group reviews pitches from the last six weeks and assess the “potential bets” for viability
  • Whatever is not chosen is simply let go. If the original proposer wants to bring it back around during the next cycle, they can track that independently
  • It’s easy to overvalue ideas, but the truth is…they are cheap.
  • The best ideas will come back to you on their own…usually through incessant customer complaints or feature requests

Bet Six Weeks

  • Attempting to commit time and attention when people are spread across multiple overlapping projects usually results in “calendar tetris,” which is why they focus on cycles
  • After each six-week cycle, they schedule two weeks for “cool down.” This lets people breathe, meet as needed, and evaluate what to do next
  • Cool down periods are for team members to work on whatever they want, which is often bug fixes, exploring new ideas, or experimenting with new technologies
  • Teams for BC usually consist of one designer and 1-2 programmers as well as a QA person to help with testing later in the cycle
  • The “betting table” at Basecamp includes the CEO, CTO, a senior programmer, and a product strategist
    • The outcome of the conversation is a cycle plan with projects, timelines, and resource allocations
    • There is no “step two” for validation/approval and there is nobody who can step in afterward to interfere or de-rail work
  • Uninterrupted time is critical. It’s not a good bet if we let a team get pulled away to work on something else.
  • “Just a few hours” or “just one day” are misleading and often lead to bigger commitments
  • At the same time, teams MUST ship the work within the amount of time allotted. If they don’t, the project does not receive an extension and is usually trashed.
    • “Don’t throw good money at a bad problem.” 
    • This policy ensures that we don’t overinvest in areas where we did a poor job shaping the solution or managing attention
  • Bugs are very seldom urgent enough to require routing attention away from the current cycle. Bugs are for cool-down periods and an annual “bug smash” that usually takes place around the holidays
  • If a project is too big for a six-week cycle, break it down into a tangible milestone that can be achieved in six weeks and save the rest for another cycle
  • Questions to ask yourself:
    • Does this problem TRULY matter?
    • Is the appetite right? Just because we CAN doesn’t mean we SHOULD.
    • Is the solution attractive?
    • Is this the right time?
    • Are the right people available?
  • When finished, make an announcement to the entire team about what the focus is for this cycle

Hand Over Responsibility

  • Assign projects, not tasks. Breaking a project down into minutiae loses the big picture context and important. Things start to feel disjointed pretty quickly.
  • Instead, they let the team define their own tasks based on the pitch that was presented and the deadline that has been established.
  • “What works on paper almost never works exactly as designed in practice.”
  • Done means DEPLOYED. The project has to be out in the wild by the end of the cycle to be a success. This includes testing and QA.
  • Things like help documentation, marketing updates, and customer announcements usually ARE NOT included in the cycle deadline

Get One Piece Done

  • During the early stages of the cycle, it is important that the team doesn’t create a master plan of numerous disparate parts that need to be assembled at the 11th hour
  • If there is no “one thing” to click on and test, then it is hard to feel like progress is being made
  • Momentum is important, so creating something tangible in the first week or so should be a high priority
  • Three criteria for choosing where to start:
    • It should be core. Choose something with a big impact.
    • Is should be small. Choose something you can finish in a few days.
    • It should be novel. If the first two criteria are satisfied, choose something you’ve never done before. The goal is to eliminate uncertainty and build confidence.

Map The Scopes

  • Delegating work by person or by role can be problematic. Instead, organize your assignments by structure – things that can be finished independently.
  • For example, a fundraising event might be broken down into food menu, venue setup, and award ceremony scripting instead of disparate tasks for Jim, Sue, and Peter
  • Basecamp starts with a single “project scope.” As team members discover implied tasks, they can begin to identify dependencies and relationships that will then be grouped together into smaller “scopes.”
  • Scopes reflect meaningful parts of the problem that can be completed independently in a relatively short period of time.
  • When done correctly, you should hear your team speaking in “scope language.” Example: “After Bucket Access is done we can implement Invite Clients. Then we’ll Update Recording Visibility when people on the firm flip the Visibility Toggle.”
  • Scopes are hard to define up front. They usually require digging in and doing the work for about a week before relationships start to solidify.
  • Well-done scoping serves as the anatomy of a project. When you have a pain, you don’t have to question whether it is in your arm or your stomach or your head. You know the individual parts and their names, so you can quickly explain where the pain is.
    • Similarly, when scoping has been done right, the different components of a project have names and identities, so it’s easy to communicate where roadblocks or sticking points are
  • Red flags that indicate scoping could be improved:
    • It’s hard to say how “done” a scope is. 
    • The name isn’t unique to the project, like “front-end” or “bugs.” We call these “grab bags” and “junk drawers.” 
    • It’s too big to finish soon. If a scope gets too big, with too many tasks, it becomes like its own project with all the faults of a long master to-do list. 

Show Progress

  • Good managers hate asking for status updates. It’s better if they can just see the status whenever they need to.
  • Counting tasks and asking for estimates is an imperfect solutions. To-do lists actually tend to GROW as a project progress and estimates are often off by a significant margin, especially on things we’ve never done before.
  • Basecamp describes project status more like a hill. There is usually a lot of difficult work on the front end as we try to understand the problem and work our way toward a solution. Then, at some point there is a moment of clarity where we know exactly what needs to be done to get to the finish line and how long that might take.
  • They recommend layering the concept of “scopes” with the concept of the “hill.” When you place scopes on the hill, it’s easy to see where we are at with each scope and how close we might be to getting it over the finish line
  • With an exclusive “hill” feature in Basecamp, managers can see how the location of scopes changes over time and instantly know where progress is being made and where teams are getting stuck
  • Nobody likes to raise their hand and say “I don’t know how to do this” or “I’m stuck and I need help.” The “hill” tool allows managers to see these things proactively and reach out with assistance without making team members feel guilty.
  • Be careful…if you try to do the “uphill work” with your head instead of your hands, you often end up having to bring the scope status back down in a process known as “backsliding.”

Decide When To Stop

  • Designers and programmers always want to do their best work, so you should expect to fight some hesitation around shipping something “sub-optimal”
  • Having pride in your work is important, but we need to direct it at the right target
  • Advice: Instead of comparing UP to the ideal, compare DOWN to the current baseline
    • What is the current reality for customers?
    • How are they solving the problem today without this feature, if at all?
    • How does our solution compare to the current state?
    • The ideal outcome is “Okay, this isn’t perfect, but it definitely solves the problem and it’s a big improvement over what customers are doing today.”
  • Scope grows naturally, but having non-negotiable cycle deadlines forces team members to make tradeoffs and prioritize what is most important, or they risk scrapping the project
  • Cutting scope doesn’t mean we have to lower quality. In fact it means we focus on the most important things and table other “nice-to-haves”
  • Scope hammering questions to ask:
    • 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?
  • In very rare cases, Basecamp will extend a project two weeks when all of the remaining work is downhill and in the “must-have” category

Move On

  • Shipping can actually generate new work, because feature releases tend to generate feature requests.
  • It’s important to stay cool and avoid knee-jerk reactions. Give it a few days to settle down and then re-evaluate the situation.
  • It can be tempting to commit to making changes/fixes based on the initial reaction you get from customers, but then you will no longer have a clean slate for the next cycle
  • Saying “yes” to these right away takes away your freedom, whereas a gentle “not right now” leaves the door open to addressing the concern in the future
  • We have come full circle…these customer demands are raw ideas and will need to be evaluated, shaped, and scoped before they can hope to make it into a future cycle

What Teams Do During A Cycle

  • Kick-Off
    • Someone from the betting table informs the team members about the project and gives them the shaped pitch.
  • Orient
    • The team familiarizes themselves with the pitch and the existing system. They think of imagined tasks and start capturing discovered tasks by spiking experiments with real code and design.
  • Scope
    • After getting oriented, the team defines a single scope—the one thing to design, build, and wire together first. Later, after they’ve started building and discovered more tasks, they come back and map the work into more scopes to track, build and finish independently.
  • Build Vertically
    • With some scope defined, the teams build just enough UI and code to integrate and get that one thing working.
  • Report
    • When they feel due to show progress, team members plot the progress of scopes on the hill chart to show which still contain unknowns and which are fully solved.
  • Ship
    • The team uses the scope hammer at every step to separate the must-haves from the maybes. They prioritize the most important scopes and solve the biggest unknowns first. Hammering the scope like this allows them to cut unimportant enhancements or nice-to-haves at the end of the project and ship on time.