Adapted from a post on John’s website.
Below is a summary of how my development team and I used some of the ideas from Basecamp’s Shape Up to improve our process, deliver quality features consistently, and have deeper discussions about what we were building.
The thing that helped me put the theories into practice was focusing on the areas where our current process was struggling and trying the tools from Shape Up that seemed like they would help.
For my team there were two 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. 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.
Here’s how we tackled both of them.
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.
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.
The first thing we used from Shape Up to get some semblance of clarity was a concept called “appetite.”
An appetite is “a time budget for a standard team size.” Basecamp treats it like a bet: i.e “We’re willing to wager this many weeks of engineering time on this thing.”
In practice, 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 it is), but making this simple declaration — “this project will take six weeks,” gave us all something to agree on 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 weeks, 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.
- Having a constraint forced us to think creatively if our initial solution was over-engineered.
- It gave stakeholders a clear timeline for when they were going to get the product.
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 that few people read the whole thing)
- Readable (no jargon, no acronyms)
- High level (since you’re still persuading others, 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)
Below are the five basic elements of a pitch. I copied them (including the definitions) into a document and made each element its own section:
- 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 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.
Discussion of the rough draft with a small group of trusted colleagues led to a 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.
By the end of the back and forth, there was still a lot to figure out, but we had drawn clear boundaries around the project. Now the team could get to work.
Once we got over that first hurdle, we ran full speed, face-first into a second one. 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. 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 the suggestions I was giving 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, but I found a surprisingly simple 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: “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 as “hard walls, soft middle” and draws it out like this:
I took responsibility for enforcing the hard walls defined in the pitch, but working within those constraints, gave the engineers focus and 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, but a UI mockup is too much.
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.
For my team, a breadboard just looks like a bunch of boxes connecting pages and functions.
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.
Be patient and flexible
Even with the best of intentions, it’s tough to introduce a new process into your existing one. The new process has all sorts of habits and cultural expectations built-in.
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 a more integrated way.
But it can be done. Trust me. Just treat the process like another product.