After the shaping work — and when a pitch is bet on — it’s time for the development team to take over the responsibility of delivering the solution within the appetite that has been established.

Here’s how we think about building at Differential.

Fixed time, variable scope

The concept of “fixed time, variable scope” is important to highlight here. The development team is handed the responsibility to deliver the solution within the appetite (fixed time), but the scope can mutate (variable scope).

We use the Hill Charts feature in Basecamp because it’s an excellent conceptual model for determining where work is based on “figuring things out” vs. “making it happen.” It provides insight into where the work really stands.

Choosing what to build first

While it may seem productive to build out the front-end UI with fake data and then later wire up the back-end, that wiring up is where all the problems occur. Instead, we should work to build a vertical slice where both the front-end and back-end work to fully complete a given piece of functionality.

Here are three criteria to think about when choosing what to build first:

1. Core → The functionality is core to the feature
2. Small → The piece should be small enough to make quick progress
3. Novel → Prefer the thing you’ve never done before

Map the scopes

The goal of mapping scopes is to build up a list of independent scopes of work that can be completed as vertical slices.

The scopes reflect the meaningful parts of the problem that can be completed independently and in a short period of time—a few days or less. They are bigger than tasks but much smaller than the overall project. — Shape Up: The scope map

I recommend reading the Case study: Message drafts in Shape Up to see a real-world example of how to map scopes.

Get it over the hill

By the end of the second week of the cycle, the feature team(s) should meet with the Product Lead (and key stakeholders) to talk through the unknowns — what is preventing you from getting the scope(s) to the top of the hill? What major questions are still unanswered? This is the place to come together and solve it.

With the initial scopes mapped, we can use their position on the Hill Chart as the conversation starter for figuring out why it's there, and what needs to be answered in order to get the dot(s) to the top of the hill.

This is also the perfect opportunity to consider refactoring the initial scopes. Maybe a part of one of the scopes is still on the left side of the hill, but another part is already solved — can it be split into two, separate scopes that can be shipped independently? Will that help determine the actual progress of the given scope? These are questions that can help drive towards clarity. It's really about having the conversation and asking the right questions.

Know when to stop

It’s easy to keep going and going when building a feature — adding enhancement and edge-case fixes left and right. But we also need to know when to stop and ship in order to get the feature done on time.

Instead of comparing up against the ideal, compare down to baseline —the current reality for customers. How do customers solve this problem today, without this feature? What’s the frustrating workaround that this feature eliminates? How much longer should customers put up with something that doesn’t work or wait for a solution because we aren’t sure if design A might be better than design B? — Shape Up: Compare to baseline

The goal is to have the feature fully integrated and shipped within the product by the end of the cycle/appetite. The huge caveat here is that all products are at different sizes, maturation levels, and release difficulties. Use this as a best-case scenario and adapt to your given product.

Output: Unlocked value

With the solution built and released, we now have unlocked value to measure / learn if our solution reaches the opportunity and solves the core problem identified during framing.