How should teams organize the hierarchy and roadmap for growth-driven design improvements?

In growth-driven design, every improvement plan starts with a focus metric, and that metric is the top of the hierarchy. Suppose a B2B software company chooses qualified demo requests. A proposed improvement below it should say how it would move that number.

The second level holds suspected obstacles. Each one pairs something the team has observed with its best explanation of how that keeps buyers from requesting a demo. In the example, the sales team reports that prospects keep asking how long setup takes, and session recordings show visitors abandoning the demo form partway through. The pricing page also has a high exit rate, and that number goes on the list with a caution. An exit rate says where people left. It doesn't say why, so it's a reason to look closer before anyone proposes a fix. The other two are still suspicions as well, until a change tests them.

Proposed changes form the third level, and each one sits under the obstacle it's meant to remove. The fourth level is the small set of changes the team has committed to build in the current cycle.

The structure helps when someone brings an idea with nothing above it. In this example, a request to redesign the homepage arrives with no observation behind it. It can stay on the list, and the empty level tells everyone what would move it up: evidence of a buyer problem the redesign would solve.

The method names the focus metric and a repeating cycle of planning, building, learning and sharing what was learned. The four levels are our recommendation for organizing the list inside that cycle. If you're still working out the outcome itself, start with how to create a growth-driven design strategy.

If the team has more proposed changes than it can build, it needs an order.

Lean Labs' growth-driven design program ranks candidate changes by expected pipeline impact, by buyer relevance and confidence, and by effort. The agency draws its evidence from page behavior, form results, CRM lifecycle data and what the sales team hears.

One way to turn judgments like those into an order is ICE scoring. In ProductPlan's description of the model, the team scores each idea from 1 to 10 for impact, confidence and ease, then multiplies the three numbers. Because the scores are multiplied, a low number on any one factor pulls the whole total down.

Suppose the software company scores four of its ideas this way. The numbers in the table are the team's own assumptions.

The setup timeline comes out first. The sales feedback gives the team confidence in it, and it's a few hours of work. The pricing calculator has the highest impact score and still lands last, because weak evidence and a heavy build multiply against it.

That result shows the model's bias as well as its use. The scores are opinions, and multiplying by ease can favor cheap work. A team that follows the multiplication alone can keep choosing easier work over the calculator for a long time. So use the score as a first ordering, and then decide on purpose whether part of a cycle should go to a larger bet.

A score also isn't a forecast. The 384 doesn't predict revenue or a conversion rate. It records that this team, with this evidence, thinks the timeline is a better next step than the form.

The 80/20 rule gets used at the same point, as a question about which few items on the list account for most of the value. It's a useful prompt to cut the list down. The two numbers are a rule of thumb, not a measurement of your list.

Scores compare ideas one at a time, and real work is connected. The form change scored second. But suppose two of the fields it removes feed the lead-routing rules in the company's CRM. The routing rules have to change with the form, either ahead of it or in one coordinated release, and that work belongs to sales operations. The form can't ship on its own, whatever its score.

Some work shouldn't be scored at all. A form that has stopped submitting needs a response right away, and an integration with an expiry date needs its fix before that date. Schedule work like this by urgency. Running it through impact and confidence only spends the meeting on a decision that was never open.

It's tempting to settle the order with a standing rule, such as fixing entry pages before offer pages, or holding all design work until the copy is final. The observed obstacles should set the order instead. If the evidence points at the demo form, starting with the homepage because a rule says so spends a cycle away from the problem.

A roadmap built this way has three horizons: what the team is building now, what comes next, and what waits. We'd put dates on the current cycle and on work with a fixed deadline, such as the expiring integration. The rest is an order, and it's expected to change.

Cycle length is a choice. The method's own site models improvement in 14-day sprints, and Lean Labs runs its program in 30-day cycles. Pick a length that suits how long your changes take to build and review.

In the example, the current cycle holds the setup timeline and the routing work the form depends on. The shorter form follows once routing is ready. The calculator and the homepage hero wait, with the missing evidence noted beside each. If the team tests the timeline against the current page, that test runs until the rule the team set for it is met, or until the team stops it as inconclusive. Either can happen after the cycle closes. We explain why in turning user insights into hypotheses and experiments.

The cycle's last two steps are learning from the result and passing it to marketing, sales and service. Those steps are also where the roadmap gets its next order.

Suppose the timeline ships, demo requests rise, and the setup question fades from sales calls. Without a controlled test, those observations fit the team's explanation and don't prove the timeline caused them. Meanwhile a new question takes the old one's place: prospects want to estimate their own cost before they talk to anyone. That is fresh evidence for the pricing calculator. Its confidence score goes up, and it moves up the list. The new question also goes onto the second level as an obstacle, where other proposed changes can attach to it.

A well-supported result that shows no movement reorders the list too. It lowers confidence in the explanation behind the change, and in the other ideas that rest on the same explanation. A test that stopped without enough data to tell is different. It leaves the question open, so it gives no reason to change the scores.

To make that reordering possible, each item should carry its obstacle, the evidence, the metric it's meant to move, its scores and any dependency. With those attached, someone who missed the planning meeting can see why the order is what it is.