This is a repost from May 2020. I've moved on from this job, but the lessons still ring true.

Below is a summary (if you can call 2,600 words a "summary") of how my development team and I used some of the ideas from Basecamp's Shape Up to improve our process.

If you'd like a summary of all the techniques in Shape Up, here's a good one that I didn't write.

Better yet, just read Shape Up itself . It's free, written without a ton of jargon, in language meant for humans, and divided up nicely into easy to digest chunks. There's even a section in the appendix that gives suggestions about how to implement it at your company, so you could think of this post as a supplemental case study for that.

If you want the tl;dr for this post:

Think about what your team is struggling with, pick one thing from the book that resonates, and just start doing it.

A couple of caveats for anyone who, like my past self, was skeptical of adopting a process from a completely different company when I've already got so much process, documentation, and politics to deal with in my current job.

You don't have to:

blow everything up and do things the way Basecamp does it.
already work with people who would be comfortable working the way Basecamp works.
completely abandon the way your company does product development.
redo your (or your engineering team’s) roadmap.
convince anyone on your team to read Shape Up.
use Basecamp.*

*You can use Basecamp though. And this book should be a lesson to every product marketer out there. It is the epitome of the "soft sell." It provides so much value without requiring me to make a single purchase. The appendix at the end simply lets me know that if I want even more value, I can easily implement the processes using Basecamp.

What ended up helping me put the theory into practice was identifying the areas where our current process was falling down and plugging in the tools from Shape Up that seemed like they would help. Ryan Singer has pointed out that "the only way to change is if you're struggling."

For my team these are three things we were struggling with:

Clarity - We weren't all on the same page about what we were doing
Autonomy - Some people were "in charge" and were bottlenecks and others didn't feel like they had the ability to make calls. It didn't help that we were working in time zones 6 hours apart.
Flexibility - We didn't feel like we could do something, make a mistake, and learn from it.

Here's how we tackled each of them.

Clarity

The best explanation I've ever seen for "what is product?" is based on the diagram below.

The goal is to move from left to right. Product is how you do it.

Credit: Revision Lab

All too often we'd start building when we were still somewhere on the left side of this diagram and we'd wind up with confusion, buggy code, and scope creep. Getting clarity on what we're solving and why we’re solving it would radically transform the features we end up delivering.

The first thing I used from Shape Up to get some semblance of clarity was called "appetite."

An appetite is "a time budget for a standard team size." Basecamp treats it like a bet. We're willing to wager this many weeks of engineering time on this thing. It works like the flip side of the coin of "estimate," enabling progress, rather than stifling it.

When it came to estimates, we often found ourselves in what I imagine is a common double-bind. Business stakeholders say something like, "Can you give us an estimate so we can determine a priority?" and engineers say something like "Estimation is work, so can you give us a priority so we know what we should estimate?" Product winds up stuck in the middle coaxing priorities and estimates out of everyone or just making them up.

So instead of begging my engineers to give me something they couldn't really give (an estimate), I gave them something clear and concrete instead (an appetite).

It seems arbitrary (and in a way it is), but making this simple declaration - "this project will take six weeks," gave us all something to agree on, which gave us shared clarity, which unlocked a number of things:

It gave the engineers leverage to push back on my proposal. After all, I set the appetite for six weeks, so they could say "That's too much for six week, can we be a little more conservative?"
It told the engineers that I was not going to randomize them for that period of time so they could focus. I pledged to protect their time as well and could use that deadline to push back on any seemingly urgent new requests that might come up.
It forced us to think creatively. Having a constraint forced us to think outside of the box if our initial solution was too over-engineered
It gave stakeholders a clear timeline for when they were going to get the product.

As it says in Shape Up, "It takes work and design insight to get to a simple idea that fits in a small time box. Stating the appetite and embracing it as a constraint turns everyone into a partner in that process."

A second idea that dramatically helped the team achieve clarity is called "a pitch." Unlike a Product Requirements Document (or PRD for those who like acronyms), which seems designed to direct others with its "requirements." The purpose of a pitch is to persuade.

In order to persuade people, things need to be understandable. So a pitch is, by necessity:

Short (I've written a PRD that ran to 35 pages. I'm proud of the work that went into it, but I know no one read it)
Readable (no jargon, no acronyms - but if you use acronyms, spell out what they mean somewhere)
High level (since you're persuading, you can't assume the work is going to happen, no need to get into the details yet)
Structured (like a story has a beginning, a middle, and an end - there needs to be a structure to the pitch that captures the whole proposal)

I copied these elements (including the definitions) of the pitch into a document and made each element its own section, copying the simple explanations from Shape Up:

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

After writing my first draft, I quickly shared it with my designers and engineering architects. No waiting to get the document "just right." As they give feedback (in conversation or comments on the doc), I added or subtracted from the pitch. Some of my proposals were controversial and would lead to disagreement. Disagreements were great!

Discussion of the rough draft with a small group of trusted colleagues led to refinement of the idea. Maybe I had a wrong assumption about the architecture. Maybe I wasn't being clear enough. This meant when I shared the pitch with the larger team, the boundaries of the project were much clearer.

Direct quotes from customers would go in the problem section. Any time we'd start getting into the weeds about an implementation detail, I'd note it in the rabbit holes section. If we encountered something that would blow up the amount of work required, I'd note it (with an explanation) in the no-gos section. By the end of the back and forth, I handed the pitch over to the team. There was still a lot to figure out, but we had drawn crystal clear boundaries around the project. Now the team could get to work.

Autonomy

Once we got over that first hurdle, we ran full speed, face-first into a second hurdle. Even though the outline of the feature was clear and understood, the team didn't feel empowered to make many of the day-to-day decisions on their own. Combined with the fact that there was a 6 hour time difference between me and my engineering team, every small decision that needed confirmation risked extending the work by a full day. I took my advice from a completely different place, an article from the New York Times about how a parent can effectively talk to their teenager. I realized my suggestions were doing more harm than good:

As hard as it is for parents to stop ourselves, rushing in with suggestions carries the risk that you’ll be communicating the idea, “You can’t fix this, but I can.” This might strike our teenagers as a vote of no confidence when they are mainly seeking our reassurance that they can handle whatever life throws at them.

So I made a radical decision. I would set the boundaries for the project, but all the decisions within those boundaries were up to the team.

There was initially some hesitation and resistance to this conscious abdication, but I found a surprisingly simple, useful tool for countering the attempts to place the decision-making responsibility back on my shoulders. Instead of offering my opinion when asked (which tends to be my default), I asked a simple: "What do you think we should do?"

This did two things:

Solicited the team's opinions which gave useful perspective on the problem that I didn't (and couldn't) have
Emphasized that their opinions and perspective mattered and that as long as they understood the boundaries of the project, they had the freedom to own all the decisions that worked within those boundaries.

Ryan Singer refers to this concept "hard walls, soft middle" and draws it out like this:

View fullsize

Source: Ryan Singer Twitter

Ironically, working within the constraints (the hard walls), gave them freedom to create in the soft middle.

The next problem became how to communicate those hard walls effectively. Sometimes words (written or spoken) aren't enough. Even if you're not a "visual person," seeing a mockup can communicate so more information, more effectively than a detailed description. A picture is worth a thousand words, right?

On the other hand, the whole idea is to give the team autonomy in the "soft middle" by leaving a lot of the decisions up to them. I don't want to give them too much information. It’s counterproductive and a waste of everyone's time to create a detailed UI mockup and then say "this is just a suggestion."

Shape Up provides a great tool for this: “the breadboard.”

A breadboard is a concept borrowed from electrical engineering. It's just the basic parts, hooked up for the purpose of proving the circuit works. A battery connected to a button connected to an LED light. That's it. No decisions about the color of the light or the casing.

Since I'm a visual person, here's a breadboard of a traffic light vs. the different designs that it can take:

Breadboard

Final Design

In Shape Up, a breadboard just looks like a bunch of boxes connecting pages and functions.

Part of a breadboard for a feature the team worked on: search and view for a data dictionary

The beauty of the breadboard is it communicates what the feature or product should do, without making decisions about how. It communicates function without making decisions about form. Which is exactly how it should be, after all: "form follows function."

This gives engineers the autonomy to make design and implementation decisions free from conscious or unconscious influence. As Nicholas C. Zakas points out in a great piece called The care and feeding of software engineers (or, why engineers are grumpy):

Engineers are chefs not short-order cooks. They should be treated as such.

By explicitly leaving problems for engineers to solve and room for them to create, they ended up surprising me with designs that were better than I could have created and even surprised me with some great features I didn't even think of.

Once we established who was responsible and when (product for the shaping, engineering for the building), the next question arose: if we're making a switch in who is leading, when does that switch happen?

There's a clue in the title of Shape Up:

That dotted line in the middle is telling you something… 🤔

Once the feature was shaped and everyone got it, I switched from "in charge of the process" to "in support of the process." I'd clarify and offer suggestions, but always reluctantly. It's hard to let go of something I worked hard on, but if another team is going to pick something up, I can't still be holding onto it. Wherever you decide to make this handoff, make it clear and clean.

Flexibility

While attempting to make all these changes to our process, the best thing we did was stay flexible. In Shape Up, Ryan Singer talks about using 6-week sprints to create a "circuit breaker" which prevents scope from creeping up and up. Elsewhere, he refers to this as "acting with a capped downside."

At the start, there were way more questions than answers. At times it was overwhelming how much we didn't know about how the changes to our process would affect how we worked:

What about customer profiles?
What about user stories?
Should we measure velocity?
What about backlog grooming sessions?
What about engineering architecture documents?
Should product attend standups?
Should every feature have a pitch?
Should we switch to 6 week sprints?
What about a betting circle?
Should engineers integrate one slice if they've never worked that way before?

We instinctively started picking out the questions that we had the least idea of an answer to. What Basecamp calls "unknown attacking". And we set a time period to try out a hypothesis - 2 weeks. That meant if the idea was a total failure, we only spent 2 weeks doing something that didn't work and stopped doing it. Worst case scenario: we learned something!

Sometimes I would just start or stop doing (small) things to see if it would improve the process. Do we really need user stories? What if I only wrote them if the team needs one for clarification?

When others on the team started offering suggestions, I'd always say yes. Even if I didn't agree. Worst case scenario: we learn something. "Acting with a capped downside"

Is it working? Keep it.

Is it not working? Get rid of it*

*Unless it's required for architectural stability, privacy reasons, government regulation etc. Those processes exist for a reason...

Just be patient

Even with the best of intentions, it can be tricky introducing a new process into your existing process. The new process has all sorts of habits and cultural expectations built in.

It's almost like doing an organ transplant. There's a very real chance that the recipient will reject the transplant, attacking it like it's a foreign invader. This is especially true in large organizations (like Groupon). Ryan Singer describes the process of process modularization in The Place of UX (big quote incoming):

For example, programmers program something according to some kind of requirement. The requirement is set according to some understanding of the problem. The person who’s responsible for understanding the problem is looking at it from the demand side, while the person who’s responsible for finding a solution to that problem is looking at it from the supply side. Or the same person may be doing both by alternating their perspective from demand side to supply side…

This distinction describes the organization of the people who provide the supply to fit the demand. Some teams are small and intensely collaborative. They talk directly to the customer and then sit around the table together to architect the solution. In that case the boundary between requirement setting and programming is integrated…

Often when a company grows beyond a certain point the boundary modularizes. This means there’s a formal interface (aka handoff) at the boundary with some procedure for how information from the demand side is communicated to the supply side.

If your company is already built around a modularized process, it can be difficult to communicate across that boundary. If product has been trained to "have the ideas and prioritize them" and engineering has been trained to "build stuff" and stakeholders have been trained to "accept what's been built for them," it can be tricky to adopt techniques that expect you to work in more integrated way.

But it can be done. Trust me. Just treat the process like another product.

Shape it.

Implementing Shape Up

Clarity

Autonomy

Flexibility

Just be patient