Fundamentally shaping is a design strategy for the business that must answer a series of difficult essential questions about the work that we will undertake.
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?
What’s not working?
In what context are there too many steps?
What parts of the existing design can stay the same and what parts need to change?
There are 4 clear steps to shaping work. The first step is to set boundaries to figure out how much time and effort we are willing to bet to solve a problem. From there we can rough out the elements of the work with workflow breadboards and simple fat marker sketches. During shaping we will also address risks and rabbit holes for discussion that we use to amend the solution. Finally we write the pitch in a more concrete way that summarizes the problem, solution, rabbit holes, limitations, and appetite that will be presented to the team for execution.
Set boundaries. First we figure out how much time the raw idea is worth and how to define the problem. This gives us the basic boundaries to shape into.
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. Once we think we’ve shaped it enough to potentially bet on, we package it with a formal write-up called a pitch . The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. The pitch goes to the betting table for consideration. If the project gets chosen, the pitch can be re-used at kick-o' to explain the project to the team.
We have a fixed time and a variable scope that depends on our appetite to solve the problem.
Is it the full cycle? Is it 2 weeks? Our appetite is what we are willing to bet and serves as a constraint for the scope of the solution. We aren't aiming for the best solution that can possibly be achieved, but rather the best solution that we are willing to bet on with our given appetite.
This depends on our Appetite to bet on a particular Solution to a Problem creates a fixed time limit that we are willing to Bet.
The Appetite serves as a constraint for the Solution. The goal is not to reach "the best" solution, but the best solution within the constraints of our Appetite and willingness to Bet on a Solution to our Problem
It is critical that only well-shaped work is handed off to the production teams for execution. No bullshit, half-baked, casually put together pitches will be accepted at the betting table. How the work is produced is up to the team. The pitch is not defining how the work will be executed. It is not dictating technical or design implementation details.