What are the three stages of growth-driven design, and what happens in each?

Growth-driven design runs in three stages: strategy, the launchpad website, and continuous improvement [1][5]. Strategy defines who the site is for and what it needs to say. The launchpad ships a smaller, sharper site quickly so real visitors start generating data. Continuous improvement then treats that live site as something you refine every sprint rather than rebuild every few years [4]. The sequence exists to fix the failure mode of traditional redesigns, where a team spends months and a large budget guessing at a finished site, launches it, and then leaves it untouched until it feels dated enough to justify starting over [4][5].

Each stage hands the next one something concrete. Strategy produces goals, buyer research, and a prioritized wishlist of ideas that becomes an implementation plan [2]. The launchpad takes the top slice of that wishlist and turns it into a working site built around the three to five pages that carry the most weight in a buyer's decision, usually live in 60 to 90 days instead of the 108 a traditional build averages [1][3]. Continuous improvement takes the behavior that live site records and feeds it back into short, time-boxed sprints, each aimed at one focus metric [4]. Growth-driven design combines Lean and Agile principles into that loop, so the website behaves like a product under active development rather than a one-time project [1]. The stages are not interchangeable, and skipping the first one is the most common way the model breaks: without strategy the launchpad has no basis for choosing which pages matter, and continuous improvement has no baseline to improve against.

The strategy stage defines who the website is for, what those people need to hear, and how the site should be structured to move them toward a decision [2][6]. It runs about 10 to 14 days and produces goals, buyer research, and a prioritized wishlist that becomes an implementation plan [1][2]. No traffic exists yet, so the work is about getting the plan right before anyone builds a page.

Set measurable goals

Strategy starts by naming the specific outcomes the site has to produce, so the rest of the work has something to aim at [2]. Clear objectives keep the build from stalling in endless revisions, because every later decision can be checked against them [2]. Practitioners typically frame these as SMART goals tied to leads, conversion, or revenue rather than raw traffic, since a page can gain visitors and still fail the business [7].

Interview customers, sales, and support

Research draws on the three groups closest to your buyers: customers, sales reps, and support staff, each of which sees the same buyer from a different angle [6]. Customers reveal why they actually bought and what nearly stopped them. Sales reps hear the objections that surface before a deal closes, while support staff know where people get stuck after they commit. The aim is an empathetic understanding of the audience's world and the problems the site can solve along their journey [2], and pulling from all three groups keeps that picture from being shaped by a single internal opinion.

Research the competitive field

Strategy also looks outward at the alternatives a buyer is weighing, because a website has to make the case for changing from whatever the buyer does today [6][7]. Understanding competitors and substitutes tells you which claims need proof and where your positioning is genuinely different, and that reading feeds straight into the problem statements and page priorities that follow [7].

Write problem statements

A problem statement lays out, for each core solution, why a buyer should listen, why they should change their current approach, how that change works, how your solution helps them make it, and what proof backs it up [6]. This is the spine of the messaging, and it forces the hard thinking to happen before design instead of after. Leaving it out is how sites end up describing features while buyers are still asking why they should care [6]. Pairing every claim with a proof point at this stage is what later separates a site visitors trust from one they merely visit.

Map the buyer journey

The buyer journey documents the path from first awareness to conversion, usually two to four steps per core solution, with each step answering the specific questions a buyer has at that point [6]. Growth-driven design frames this as moving someone from problem-aware to solution-aware to product-aware, and it maps separate paths for cold, warm, and hot audiences, because a stranger and a returning evaluator need different things from the same site [6]. Getting this right is what lets the launchpad decide which pages to build and in what order, since the journey is effectively the blueprint for the site's structure [2].

Build the wishlist

The stage ends with a wishlist: an organized backlog of every idea, feature, and page anyone thinks the site could use, commonly 50 to 200 items [5][7]. The wishlist is not a build list. Its job is to capture everything so nothing is lost, then rank each item by impact so the launchpad can take only the highest-value slice while the rest waits for continuous improvement [5][7]. Turning that ranked wishlist into an actionable implementation plan is the concrete handoff from strategy to build [2].

Why alignment, not traffic, is the success measure

Strategy succeeds when the plan reflects the real questions buyers ask, which is a judgment about alignment rather than a number on a dashboard [6]. There is no traffic to measure yet, so the useful test is whether the people closest to your buyers, the same customers, sales reps, and support staff you interviewed, recognize their real concerns in the goals, problem statements, and journey [2][6]. A plan that passes that test gives the launchpad a solid basis for its page choices. A plan that skips this validation tends to surface its gaps only after the site is live, when fixing them costs far more.

The launchpad stage builds and ships a real, working website fast, focused on the three to five pages that most influence a buyer's decision [3]. It looks and performs better than the site it replaces without being the final product, and it usually goes live in 60 to 90 days against a traditional average of 108 [1][3]. Its purpose is to stop guessing and start collecting real visitor behavior [3].

Select pages with the 80/20 rule

Page selection follows the 80/20 rule: build the roughly 20% of pages that create about 80% of the impact, and defer the rest [5]. Growth-driven design narrows this to the three to five pages that carry the most weight in a buyer's decision, with the remaining pages handled as straightforward migrations rather than redesigns [3]. Every page added to the launchpad lengthens the timeline and dilutes focus, so the discipline lives in what you leave out, not what you include [6].

Why roughly 10 pages carry a 50 to 100 page site

On a typical 50 to 100 page site, about 10 pages do nearly all the work of turning visitors into buyers [6]. The homepage, the core solution or product pages, and the primary conversion pages absorb most of the meaningful traffic and almost all of the decisions, while the long tail of sub-pages rarely changes an outcome [6]. That is why launching a focused site is not a compromise: rebuilding the pages that matter and migrating the ones that do not captures most of the available gain in a fraction of the time a full redesign would take [3].

Build fast and ship before it is perfect

The launchpad ships the moment the new site clearly beats what is live today, even if some polish is still missing [3]. This is deliberate, not sloppy: the standard is a site that performs better than the current one, not a finished showcase, because months spent perfecting graphics are months of visitor behavior you never get to measure [3][5]. Built with an agile, Scrum-style process, the launchpad treats launch as the start of the work rather than the finish line [5]. Waiting for perfect is the exact habit growth-driven design is built to break.

The baseline metrics the launchpad produces

Once live, the launchpad produces the baseline data every later decision depends on, centered on three metrics [3][6]. Bounce rate shows whether visitors find what they expected on the page they landed on. Exit rate shows where people leave a flow they had started, which points to a broken next step, and conversion rate is the bottom line, the share of visitors who take the action the page exists to drive [6]. Real case results show what this foundation makes possible: a launchpad drove a 32% increase in monthly conversions within three months for one organization, tripled the conversion rate within 30 days for another, and produced a 271% lift in visitor-to-lead conversion for a third [3]. None of those numbers is reachable until a real site is live and measured, which is the whole reason the launchpad ships early.

Continuous improvement treats the live site as something you refine every sprint, using real data instead of opinion [4]. Work runs in short, time-boxed sprints, commonly two weeks, and never reaches a fixed end date [1][4]. This is the stage that separates growth-driven design from a smaller, faster version of a traditional redesign [4].

Start every sprint with a focus metric

Every improvement plan starts with a single focus metric that the sprint is meant to move [4]. Anchoring to one metric keeps a sprint from becoming a grab bag of unrelated tweaks and makes it obvious afterward whether the work succeeded [4]. The metric is usually one of the launchpad baselines, a bounce rate on an entrance page, an exit rate mid-funnel, or a conversion rate on an offer page, so the site's own data sets the agenda [6].

Plan, build, learn, and transfer

Each cycle moves through four steps: plan, build, learn, and transfer [4]. Planning prioritizes the highest-impact ideas for the focus metric into a time-boxed sprint. Building executes them, often with a cross-functional team. Learning reviews the experiments and analyzes the data to extract what it says about the audience. Transfer then shares those findings with marketing, sales, and service so the whole company benefits from what the website discovered, not just the web team [4]. That last step is what turns website optimization into organizational learning.

Prioritize with ICE

Ideas compete for a place in each sprint through ICE scoring: impact, confidence, and ease [6]. Each candidate change is scored 1 to 10 on all three, and the scores are multiplied, so a high total requires an idea to be worth doing, likely to work, and cheap to try at the same time [6]. Scoring this way settles debates with a shared number instead of the loudest opinion, and it keeps easy but low-value busywork from crowding out the changes that would actually move the focus metric [6].

The first 90 days are a harvest window, then a quarterly cadence

The first roughly 90 days after launch are the richest window for improvement, when a fresh site generates the most new data and the biggest, most obvious wins are still on the table [6]. Teams run their most intensive sprints in that window, then settle into a quarterly cadence once the easy gains are captured and the work shifts to steadier, more incremental changes [6]. Peak performance comes from this accumulation of data-driven changes over time, not from launch day, which is why the stage is designed to continue indefinitely [4].

Why continuous improvement removes the reason sites get rebuilt

A site under continuous improvement rarely needs a ground-up rebuild, because the problems that normally force one get fixed while they are still small [5]. Traditional sites get rebuilt once they drift far enough from current performance to feel obsolete, and that drift only happens when no one is watching the metrics [4]. Reviewing and optimizing the site month over month keeps it current and heads off the slow decay that makes a full redesign feel necessary [5]. The site stops being a periodic capital project and becomes a continuously maintained asset.

The three stages form a single loop, not a checklist you finish [4]. Strategy decides what matters and why, the launchpad turns the highest-priority slice of that thinking into a live site that generates data, and continuous improvement feeds that data back into the next round of changes [2][3][4]. Each stage is only as good as the one before it: a launchpad built without strategy optimizes the wrong pages, and continuous improvement without a launchpad baseline has nothing to measure against [3][4]. Run in order and kept running, the loop is what lets a website keep getting better for years instead of being scrapped and started over [5].