Product

Product Process: Shaping the Solution (Phase 2)

We begin our product process by setting the boundaries of the solution. This is the motivation behind the work we need to do — what is the problem and why is it important to solve it? This is what framing provides us. Shaping turns that upfront work into a specific...

We begin our product process by setting the boundaries of the solution. This is the motivation behind the work we need to do — what is the problem and why is it important to solve it? This is what framing provides us. Shaping turns that upfront work into a specific and actionable plan for addressing the problem.

Here’s how we think about shaping at Differential.

Appetite

The framing work gives us clarity around the problem and the priority in solving the problem, but the constraint we must set is established here.

An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design. We use the appetite as a creative constraint on the design process. — Shape Up: Set Boundaries

So the appetite is us saying: this is how much time we’re willing to spend.


Appetites can be set in any amount up to 6 weeks, which is the largest. Shape Up refers to the different sizes as “Big Batch” and “Small Batch”:

  • Big Batch: One project that occupies a team for a whole cycle and ships at the end.
  • Small Batch: A set of one-two week projects that a single team ships by the end of a six-week cycle.

You can use this designation for determining appetite sizes, but I’ve found more flexibility in using all the appetite sizes to find the right combination for a given feature, cycle, and resourcing constraints.

Rough out elements

Once the appetite is established, it’s time to rough out the elements. The word rough is intentionally used here because it leaves room for the team to fill in the details when the actual work begins.

Regardless of what you say, any specific mock-ups are going to bias what other people do after you—especially if you’re in a higher position than them. They’ll take every detail in the initial mock-ups as direction even though you didn’t intend it. — Shape Up: Room for designers

The focus is on using words, rough sketches, and breadboards to communicate the solution without boxing the team in around a given solution. Wireframes are too concrete and words are too abstract, so the shaped solution is about lower-fidelity methods that communicate the solution with the appropriate guardrails.

Address risks and rabbit holes

While the shaped pitch is presented from a user-facing perspective, it’s important to address technical risks and rabbit holes to de-risk the solution. We should ask questions like:

  • Does this require new technical work we’ve never done before?
  • Are we making assumptions about how the parts fit together?
  • Is there a hard technical decision we should settle in advance?

If members of the shaping team cannot perform this work, it’s advisable to bring in a technical expert to collaboratively walk through the pitch and consider how the pieces would fit together technically.

Write the pitch

With the boundaries, rough elements, and risks/rabbit holes addressed, you can then put together all the pieces in a pitch, which is a formalized document that you can use at the Betting Table and is the source of truth for the team who will be building the solution.

The order in which you write the pitch may vary from pitch to pitch. Sometimes I start with sketching; Sometimes I start with words; Sometimes I start with mind-maps and other methods. Use whatever process works for you to get to the bounded solution.

Output: Bounded solution

The output of the shaping work is a bounded solution in the form of a pitch document that you can bet on at the Betting Table.

The elements of a pitch

Within the pitch document, you want to detail:

  • The problem: What is the problem? Why is it important to solve the problem? Who are we solving the problem for? How do we plan to solve the problem? What would success look like if we solve the problem?
  • The solution: Key features of the solution (with sketches and breadboards!), items / work explicitly being left out (no-gos), technical considerations, design considerations, key flows, and additional design assets.
Share this post