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

The method's overview models strategy at 10 to 14 days, the launchpad at 60 to 90 days and improvement in 14-day sprints. Lean Labs' growth-driven design service publishes the same windows for the first two stages and runs improvement in 30-day sprints.

These are planning figures. Providers set them differently, and the scope of a given site moves them. We go through what changes the schedule in how long it takes to launch a growth-driven design site.

The method's page on strategy connects three things to an implementation plan: what the audience needs, what the business wants from the site, and a wishlist of ideas.

Suppose a company sells inventory software to regional distributors. Its site has about sixty pages, added over several years. It brings in demo requests, and sales says many of them come from companies too small to buy.

The work starts with research. Lean Labs' article on the three stages recommends talking with customers, sales reps and support staff, because each hears about the purchase from a different position.

Suppose the vendor's customers say they started looking after a stock count went badly wrong. Sales adds that prospects ask early whether the product works with their accounting system. From support, the team hears that new customers are surprised by how long the data import takes.

The team sets an objective, which is more demo requests from distributors of the right size. It collects every idea anyone has for the site into a wishlist. Then it picks the first release: the homepage, two product pages, an integrations page and the demo request page. Everything else stays on the list.

That choice, with the reasons written down, is what strategy produces. The reasons are beliefs about buyers that haven't been tested on a live site yet. We cover how to check them in how to identify and validate the fundamental assumptions behind a strategy, and the planning work in how to create a growth-driven design strategy.

The method's page on the launchpad describes it as a foundation for collecting user data and improving, and says it isn't the final product. The work it lists runs from page plans and content prototypes through design, development and migration. The page also says speed shouldn't come at the cost of value to users.

In our example, five pages get rebuilt around what the research found. The homepage opens with stock counts going wrong, and the product pages state near the top that the product connects to accounting software. The other pages are carried into the new design without being rewritten.

Carrying them over is real work, because the release has to be usable on the day it goes live. Existing customers still need the login link and the help articles. A prospect who arrives from search on an old blog post still needs to land on a working page. The launchpad narrows what gets redesigned. It doesn't permit breaking the tasks people already complete on the site.

HubSpot's content staging, on Content Hub Professional and Enterprise, lets a team prepare replacement pages on a staging domain and swap them for the live ones. When a replaced page's URL changes, HubSpot creates a permanent redirect.

The launchpad also sets up what comes after it. Lean Labs' article describes the design work as building a set of reusable components, so a page added in a later cycle can be assembled from parts that already match the rest of the site. We describe the build in more detail in what a launchpad website is and how to build one.

The method's improvement cycle has four steps. The team plans around a focus metric and a prioritized set of work, builds it, learns from the data, and passes what it learned to marketing, sales and service.

Suppose the vendor's first cycle focuses on demo requests from the two product pages. Recordings show visitors reaching the line about accounting software and leaving. The team's explanation is that buyers can't tell whether their accounting system is supported, so the cycle adds the names of the supported systems to both pages.

The change is planned to ship within the sprint. Reading its result is a separate matter. A sprint is a planned period of work. The evidence depends on the pages' traffic and on how visitors behave, and it can take longer to accumulate than the sprint that shipped the change. Whether the new requests come from distributors of the right size shows up later still, once sales has spoken with them.

Suppose that's the case here. The team ships in one cycle and reads the result in a later one, while the next piece of work goes ahead. Lean Labs' service is an example of what feeds that reading. It names page behavior, form and conversion behavior, CRM lifecycle stages and sales feedback as its inputs.

This stage is also where the rest of the wishlist gets built. Lean Labs' article says the pages left out of the launchpad are built during continuous improvement, with the site's performance data informing them. For the vendor, the resource pages and the remaining product pages come up for work here, in an order set by what the first cycles showed. What metrics to track in growth-driven design covers the measures, and how to turn user insights into hypotheses and experiments covers the changes themselves.

Strategy and the launchpad happen once for a given build. Improvement repeats, and each cycle returns to the beliefs strategy wrote down. If better-fit requests follow, that is consistent with the belief about accounting systems. It doesn't show why those buyers asked for a demo, so the belief stays provisional. If the requests don't change, the team goes back to what customers and sales reported and reconsiders what the product pages should answer first.