Growth-Driven Design gets cited a lot as a concept and applied rarely as an actual methodology. The conference version involves diagrams with arrows and words like “continuous improvement.” The practical version is messier and more specific.
Here’s what it actually means when we run it on a brand or website sprint.
The methodology in one sentence
Launch the smallest strategically complete version of the site as fast as possible, then use real user behavior to decide what to build next.
That sentence contains three ideas that each push against the instinct of most clients and most designers.
Smallest strategically complete — not MVP in the “we’ll add the important stuff later” sense. Every page that launches has to do its strategic job. If the homepage can’t convert the buyer, it doesn’t ship. But you also don’t need 24 pages before you launch. You need the 10 that handle 80% of the conversion work.
As fast as possible — not recklessly, but the time pressure is real and intentional. Every week before launch is a week without data. The goal is to get the site in front of real users as quickly as the strategy allows.
Real user behavior — not surveys, not assumptions, not the CEO’s opinion about which headline is better. Scroll depth, click paths, conversion rate by source, form abandonment by field. The data decides the second sprint.
What the first sprint looks like
Eight weeks. Every week has a defined output.
Week one is strategy. Goals, buyers, conversion framework, competitive audit. We’re not designing anything yet. We’re deciding what the site needs to accomplish and who it’s talking to. This work is often the hardest part of the project — not technically, but politically. Stakeholders have opinions about what the company is and what the site should say. Those opinions don’t always agree with what the buyers need to see.
Weeks two through seven are architecture and design. IA before aesthetics. Content plan before visual design. Every design decision is traced back to a strategic reason. This discipline is the difference between a site that looks good and a site that works.
Week eight is handoff and launch prep. Dev-ready Figma, component specs, token documentation. If we’re managing development too, this week is QA and launch.
What the second sprint looks like
The second sprint (typically 60–90 days post-launch) is entirely data-driven. We look at what the analytics actually show, identify the three highest-impact improvement opportunities, and design against those specifically.
The improvements are usually not what the client expected. Common findings: the pricing page is the most-visited page on the site and it has the highest exit rate (the pricing isn’t working). The case study pages have long session times but no CTA clicks (the pages convince but don’t convert). Mobile users are dropping off at the contact form because there are too many fields.
None of those are visible before launch. That’s the point.
Why most clients resist it at first
The instinct is to design everything before launching anything. Clients want to feel like they’ve solved the website problem — and “we’ll keep improving it based on data” sounds like a hedge.
The reframe is to point out that the alternative — spending six months designing a site based on assumptions — is a much larger hedge. You’re betting six months of budget on what you think users will do instead of finding out what they actually do.
The GDD framing makes the process explicit: we’re going to learn. The question is whether we learn before or after we’ve committed the full budget.
Most clients, once they see the data from sprint two, become converts. The second sprint improvements are demonstrably better because they’re grounded in what the site actually showed them. That’s the proof case.
The tool connection
The SM pipeline exists partly because of GDD. The Lathe — the CX evaluator — is the tool we use to audit a site before the second sprint. You paste the URL, it scores the experience across five journey stages, and it returns prioritized recommendations. That’s the GDD loop: launch, measure, evaluate, prioritize, improve. The Lathe is the evaluate step made into a repeatable tool.
The methodology and the products are the same idea. Do the work. See what the data shows. Build what actually matters next.