Cyclical weeks. A week is long enough to build something meaningful start-to-finish and short to use it wisely and not squander.

Shaping the work. Define the key elements of a project/problem and the solution before taking it on. Concrete enough that teams know what to do, yet abstract enough to allow individual creativity.

Integrated design and programming. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat.

The shaped work should be at the right level of abstraction: not too vague and not too concrete. It should tell you what the finished product work will look like when it's done.

Shaping is primarily design work. The shaped concept is an interaction design viewed from the user’s perspective. It defines what the feature does, how it works, and where it fits into existing flows.

It’s also strategic work. Setting the appetite and coming up with a solution requires you to be critical about the problem. What are we trying to solve? Why does it matter? What counts as success? Which customers are affected? What is the cost of doing this instead of something else?

Set boundaries. Figure out how to define the problem and how much time you are going to spend on it.

Sometimes an idea gets us excited right away. Temper the excitement by checking whether this is really something you’re going to be able to invest time in or not.

If we don’t stop to think about how valuable the idea is, we can all jump too quickly to either committing resources or having long discussions about potential solutions that go nowhere.

Don't estimate, have an appetite. Estimates start with a design and end with a number. Appetites start with a number and with a design. Have fixed time but variable scope.  

Rough out the elements. Then comes the creative work of sketching a solution. We do this at a higher level of abstraction than wireframes in order to move fast and explore a wide enough range of possibilities. The output of this step is an idea that solves the problem within the appetite but without all the fine details worked out.

Address risks and rabbit holes. Once we think we have a solution, we take a hard look at it to find holes or unanswered questions that could trip up the team. We amend the solution, cut things out of it, or specify details at certain tricky spots to prevent the team from getting stuck or wasting time.

Write the pitch. A formal write-up. The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. 

It’s critical to always present both a problem and a solution together. It sounds like an obvious point but it’s surprising how often teams, our own included, jump to a solution with the assumption that it’s obvious why it’s a good idea to build this thing.

Diving straight into “what to build”—the solution—is dangerous. You don’t establish any basis for discussing whether this solution is good or bad without a problem.