Shape up! @basecamp

A colleague of mine recently took the initiative to run an one-off book club wherein he invited our team to read Shape Up and then discuss it. Setting a hard deadline for when to finish the book was super useful and - although the discussion hasn't taken place at the time I'm writing this - I made sure to highlight and write down notes as I slowly completed the book.

In summary, I think it's a book worth reading, as is The Mom Test if you're doing any kind of product research. Hell, as I don't have a lot of notes for that one, here's some bonus content:

In-line super-brief review of The Mom Test

We risk biasing people by asking heavy-handed questions like “do you think it’s a good idea“.

“It’s not anyone else’s responsibility to show us the truth. It is our responsibility to find it. We do that by asking good questions.“

“Doing it wrong is worse than doing it doing nothing at all. When you know you’re clueless, you tend to be careful. But collecting a fist full of false positives it’s like convincing a drunk he’s sober: not an improvement.“

“Until we get specific, it always seems like a good idea.“

“We find out if people care about what we’re doing but I never mention it. Instead, we talk about them and their lives.“

1. talk about their life instead of your idea

2. ask about specifics in the past instead of generics or opinions about the future

3. talk less and less and listen more

“learned through their actions instead of their opinions.“

OK, back to Shape up!

The technique described in the book was developed in isolation over nearly 15 years of constant trial and error, taking note, iterating, honing in, and polishing up. "We’ve shaped our own way." writes the author, telling us what they learned as they "grew from four people to over fifty".

"Basecamp started off in 2003 as a tool we built for ourselves." And throughout its creation they also "created the well-known web framework Ruby on Rails as a by-product".

"everyone worked remotely. That made it hard to pass on our intuitions. We needed language to describe what we were doing and more structure to keep doing it at our new scale."

They landed on 6 week cycles; separate team shaping up projects for cycle teams:

"When shaping, we focus less on estimates and more on our appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite."

Reducing risk

"reduce risk in the shaping process by solving open questions before we commit the project to a time box. We don’t give a project to a team that still has rabbit holes or tangled interdependencies."

"reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first."

"reduce risk in the building process by integrating design and programming early."

Shaping

I’ll give a wireframe to my designer, and then I’m saying to her: “I know you’re looking at this, but that’s not what I want you to design. I want you to re-think it!” It’s hard to do that when you’re giving them this concrete thing.

When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth.

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?

You’re solving a problem with no context. You have to be a mind reader. It’s like: “we’ll know it when we see it.”

Past versions of Basecamp had calendars, and only about 10% of customers used them. That’s why we didn’t have the appetite for spending six months on a calendar.

You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building.

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.

Responding to raw ideas

It’s important to keep a cool manner and a bit of a poker face. We don’t want to shut down an idea that we don’t understand. New information might come in tomorrow that makes us see it differently. On the other hand, showing too much enthusiasm right away can set expectations that this thing is going to happen. We may not be able to commit to it once we’ve put it into context with everything else we want to do.

Dig deeper: We once had a customer ask us for more complex permission rules. It could easily have taken six weeks to build the change she wanted. Instead of taking the request at face value, we dug deeper. It turned out that someone had archived a file without knowing the file would disappear for everyone else using the system. Instead of creating a rule to prevent some people from archiving, we realized we could put a warning on the archive action itself that explains the impact. That’s a one-day change instead of a six-week project.

we flip from asking “What could we build?” to “What’s really going wrong?”

Try out the Shape UX slowly to make sure it make sense.

is X possible in 6-weeks?”

keep the clay wet. Rather than writing up a document or creating a slideshow, invite them to a whiteboard and redraw the elements as you worked them out earlier, building up the concept from the beginning

Problem =diagnosis

Appetite =time constraint

Rabbit hole=possible risk and mitigation

The End

The end of a cycle is the worst time to meet and plan because everybody is too busy finishing projects and making last-minute decisions in order to ship on time.

Therefore, after each six-week cycle, we 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.

When people ask for “just a few hours” or “just one day,” don’t be fooled. Momentum and progress are second-order things, like growth or acceleration.

Bugs

There is nothing special about bugs that makes them automatically more important than everything else. The question is: how severe are they? If we’re in a real crisis—data is being lost, the app is grinding to a halt, or a huge swath of customers are seeing the wrong thing—then we’ll drop everything to fix it. But crises are rare.

Tasks & getting started

Nobody plays the role of the “taskmaster” or the “architect” who splits the project up into pieces for other people to execute. Talented people don’t like being treated like “code monkeys” or ticket takers. Projects also turn out better when the team is given responsibility to look after the whole.

Work in the first few days doesn’t look like “work”. There can be an odd kind of radio silence. Everyone is busy learning the lay of the land and getting oriented.

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

Disposability

Create Throwaway parts: e.g. implementing fake HTTP auth first, test the flow on real customers and then implement a more robust OAuth.

Breaking things down

novel. If two parts of the project are both core and small, prefer the thing that you’ve never done before.

break the overall scope (singular) of the project into separate scopes (plural) that can be finished independently of each other

Identify tasks. Group tasks into independently deliverable scopes. Discover more tasks as you go along

They seem to work independently in an asynchronous fashion, collaborating through boots on base camp

Cakes & icebergs

Layer cake: same effort in backend and front end

(Upside down) icebergs - one layer Require significantly more work than the other. Minimize these by refactoring .

issues are discovered by getting involved in the problem. That means to-do lists actually grow as the team makes progress.

Hills

What can we solve to get that over the hill?

think of the first third uphill as “I’ve thought about this,” the second third as “I’ve validated my approach,” and the final third to the top as “I’m far enough with what I’ve built that I don’t believe there are other unknowns.”

If we were out of time at the end of the cycle, which of these could we easily whip together—despite the unknowns—and which might prove to be harder than we think? push the scariest work uphill first.

Feedback

It’s important to stay cool and avoid knee-jerk reactions. Give it a few days and allow it to die down. Be firm and remember why you made the change in the first place and who the change is helping.

The raw ideas that just came in from customer feedback aren’t actionable yet. They need to be shaped.