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

A growth-driven design roadmap is a prioritized backlog of website improvements that stays open and gets re-ordered as data comes in, not a fixed timeline signed off at the start of a project. Its hierarchy has four levels that each narrow the work: a wishlist of every idea the team has for the site, an 80/20 cut that separates the launchpad from the post-launch backlog, a scoring model such as ICE that ranks what survives the cut, and a single focus metric per sprint that decides which top-ranked items get built next [1][3][5]. Traditional redesigns invert this order. They front-load an exhaustive scope, build it over roughly 108 days, and launch once, with no structured mechanism for deciding what to improve afterward [4].

The practical effect of the GDD structure is that the roadmap keeps producing decisions instead of going stale. Because the wishlist never closes and every learning cycle adds new ideas and re-scores old ones, the team always has a defensible answer to the question of what to work on next and why [5]. That ranking is what separates a roadmap from a to-do list. A to-do list treats every item as eventually necessary; a GDD roadmap treats most items as hypotheses that have to earn their place near the top by scoring well on expected impact and by surviving contact with real visitor behavior. The sections below walk each layer of that hierarchy in order: where the wishlist comes from, how the 80/20 filter sets the first cut, how ICE scoring ranks the rest, how sprint cadence and a focus metric turn the ranking into shipped work, and how each cycle's data re-ranks the whole list.

The roadmap begins as the wishlist assembled during the strategy phase: a structured brainstorm of every idea the team has for the site, typically 50 to 150 or more items spanning pages, features, tools, content, and experiments [1]. Collecting ideas this widely captures demand from every source before any filtering happens, so that sales, support, marketing, and leadership all see their inputs on one list rather than lobbying for pet projects later. The GDD strategy stage exists specifically to take that organized wishlist of ideas and turn it into an actionable implementation plan, which is the step where an unordered pile becomes a roadmap [2].

The wishlist never closes. Each learn step in the continuous improvement cycle generates new items as data reveals how visitors actually behave, and those feed straight back into planning [5]. Treating the wishlist as a permanent, living backlog rather than a scope document that gets signed and frozen is the structural difference between a GDD roadmap and a traditional redesign plan [4]. Teams keep the wishlist in whatever tool already holds the rest of their work, a spreadsheet, a HubSpot project, or a dedicated backlog tool, with enough detail on each item to score it later: the page or system it affects, the metric it is meant to move, and the assumption behind it. An item with no target metric attached is a warning sign, because it cannot be ranked by expected impact and usually reflects a preference rather than a hypothesis.

The first layer of hierarchy is the 80/20 filter, which asks a single question of the wishlist: of the items on this list, which 20 percent will produce 80 percent of the impact and value for site users [1]. The items that pass become the launchpad website, the first version that goes live; everything else stays on the wishlist as the post-launch roadmap. This is a cut, not a deletion. Nothing is thrown away, it is sequenced, which is what makes the filter easy to apply without an argument about whether a good idea is being lost.

The 80/20 cut is what lets a launchpad ship in roughly 60 to 90 days instead of stalling on completeness [1][4]. A launchpad focuses on prioritized improvements so it can launch sooner and start producing behavior data faster, and that data is worth more than the polish the deferred items would have added [4]. The discipline the filter enforces is refusing to promote an item past the cut because a stakeholder is attached to it. An idea that serves internal preference but not measurable user impact belongs lower on the list, and phrasing the filter as an impact question lets the team make that case on the roadmap's behalf rather than as a personal disagreement. A useful test for each candidate is whether you can name the visitor problem it solves and the metric it should move. Items that survive that test tend to be the same 20 percent the filter is trying to surface.

Cadence converts the ranking into shipped work by pulling top-scored items into fixed, time-boxed sprints. The core GDD model runs continuous improvement in 14-day sprints; IMPACT's variant runs a monthly cycle, and either interval works as long as it is fixed and repeating [1][4]. Each cycle moves through four steps: plan, build, learn, and transfer [5]. Planning is where the roadmap and the calendar meet, because that is when the team selects which items to build from the top of the ranked list.

The single most important decision in each sprint is the focus metric, and it sits at the top of the hierarchy above any individual item. Every cycle starts by choosing one metric to improve, then pulls only the highest-scoring wishlist items that plausibly move that metric into the sprint [5]. A sprint aimed at improving everything improves nothing you can measure, while a sprint aimed at demo requests from the pricing page produces a result you can judge and learn from. The focus metric is also what makes ICE's impact scores meaningful, since impact is always estimated against the metric currently in focus. The cycle closes with the transfer step, which hands what the team learned to marketing, sales, and service so the roadmap's value reaches past the website itself, and those learnings become inputs to the next planning session [5].

Because sprints are short and fixed, the roadmap is never more than a couple of weeks from its next decision point, which is what keeps low-value items from lingering. An item that does not earn its way into a sprint after several cycles is usually telling you its real priority.

The roadmap is re-ranked every cycle from what the previous sprint's data shows, which is the mechanism that keeps the hierarchy honest over time. In the learn step, the team studies how the changes performed against the focus metric, and what it finds informs the ideas generated in the next planning step [5]. A change that worked raises confidence in related items and often spawns new wishlist entries; a change that failed lowers confidence in the assumption behind it and pushes similar ideas down the list. Nothing about the ranking is permanent, because the confidence factor in particular is a moving estimate that each experiment updates [3][5].

Two forces drive the re-rank. The first is evidence: an idea that was a hunch last cycle can become a high-confidence bet once a related test succeeds, or lose its place once a test fails. The second is where results actually concentrate. Improvements to high-traffic entrance pages and primary conversion pages compound, because raising the sample size and the stakes on those pages increases the value of every experiment that runs downstream of them, so the roadmap tends to re-sort toward wherever traffic and revenue cluster [5]. Over enough cycles this feedback loop is what lets a site keep improving on the same foundation for years rather than aging into another full redesign, since the roadmap is continuously repricing its own items against reality instead of committing to a plan written before any data existed [4].