Three Sales Funnel Automations SMBs Must Fix First for Real ROI
September 7, 2026
Growth-driven design (GDD) is an agile method for redesigning a website in small, data-tested steps instead of one long build. It launches a working foundation in weeks, then improves it every 14 days based on real visitor behaviour. The payoff: faster time-to-value, lower financial risk, and a site that keeps earning its keep instead of ageing quietly for three years until the next redesign.
TL;DR:
- Growth-driven design requires ongoing investment and a dedicated owner to maintain momentum beyond the initial launch.
- Traffic levels influence whether GDD is suitable, with low-traffic sites needing qualitative feedback instead of final A/B test results.
- A structured process involves a short strategy phase, focused launchpad, and 14-day sprint cycles for continuous improvements.
- Tools with analytics, behavior tracking, and no-code experiment builders support quick, data-backed optimizations.
- The biggest risks are neglecting budget continuity, lacking backlog ownership, and expecting conclusive results from limited traffic.
Table of Contents
- What is growth-driven design and how does it differ from a traditional redesign?
- What are the three stages of growth-driven design?
- How does the continuous improvement cycle actually work?
- What results and metrics should you expect from GDD?
- When does growth-driven design make sense, and when doesn’t it?
- How do you start a growth-driven design project in 90 days?
- What does GDD look like in practice at Done.lu?
- What usually goes wrong with growth-driven design, and how do you fix it?
- What tools support a growth-driven design process?
- What does a successful growth-driven design project actually look like?
- Lessons from running growth-driven design projects
- How can Done.lu help you run a growth-driven design project?
- Sources
What is growth-driven design and how does it differ from a traditional redesign?
Traditional redesigns guess. A team spends months debating colours, copy, and layout in a boardroom, launches once, and finds out what actually works only after the invoice is paid. Growth-driven design flips that order: launch something focused and functional fast, then let real visitor data decide what to change next.
GDD borrows its rhythm from agile and SCRUM. The website stops being a one-off project and becomes a product with a backlog, sprints, and an owner. Every design decision traces back to analytics, heatmaps, or user feedback rather than internal opinion, which is exactly the discipline behind growth-driven design as a smarter redesign process.
For an SMB, that shift usually means:
- A live site within weeks, not months, so marketing campaigns aren’t stalled waiting for launch
- Continuous small wins instead of one big bet that might not land
- A paper trail of evidence for every layout or copy change, useful when stakeholders ask “why did we do that?”
What are the three stages of growth-driven design?
GDD runs in three distinct stages, each with its own timeline and job to do. Skipping one, especially strategy, is the most common reason a GDD project drifts back into a traditional redesign with a GDD label stuck on it.
- Strategy. The team interviews stakeholders and buyers, audits existing analytics, and builds a wishlist of every page and feature the business thinks it needs. This stage exists to separate assumption from evidence before anyone touches a design tool.
- Launchpad. The highest-impact portion of that wishlist gets built and shipped. This is the working foundation, not the finished product, and its job is to start generating real data immediately, a point Growth-Driven Design itself makes clear about the method’s own sequencing.
- Continuous improvement (ongoing, 14-day sprints). Once live, the site enters a permanent cycle of testing and refining based on what visitors actually do, not what the strategy stage predicted they’d do.
Together, these three stages replace the old “redesign every three years” cadence with something closer to a living product.
How does the continuous improvement cycle actually work?
Every sprint in the continuous improvement stage follows the same four-step loop: Plan, Build, Learn, Transfer. It repeats every 14 days, which keeps the team small, focused, and accountable to a short deadline rather than a vague quarterly goal.
Planning starts with a backlog of experiment ideas, scored using a simple framework like ICE (Impact, Confidence, Ease), so the team builds what’s likely to move the needle rather than whatever the loudest voice in the room prefers. Building is deliberately scoped to what fits in two weeks. Learning means checking the analytics against the hypothesis, not just the outcome. Transfer means writing down what was learned so it informs the next sprint, or gets applied elsewhere on the site.
A typical early experiment: shortening a contact form from nine fields to four and measuring the change in submission rate over the following two weeks, an approach that mirrors the conversion testing Connect Labs describes in its GDD framework. If it works, the same principle (remove friction, retest) gets applied to the checkout page or the newsletter sign-up next.
- Score every idea on Impact, Confidence, and Ease before building anything
- Run one experiment at a time per page so you know what actually caused the change
- Document the result even when the experiment fails; a null result still saves the next sprint from repeating it
Pro Tip: Keep a shared “experiment log” from day one. After six months it becomes the single most valuable document in the project, because it stops the same debates resurfacing every quarter.
What results and metrics should you expect from GDD?
Set expectations around four core numbers: visits, leads, conversion rate, and revenue that can be traced back to a specific site change. Anything vaguer than that turns reporting into guesswork.
Some practitioner case reports cite uplifts around 16.9% more leads and 11.2% more revenue after adopting a growth-driven design process, according to Heyflow’s guide to growth-driven design. Treat those figures as case-level outcomes, not a guaranteed average. Your site’s starting traffic, industry, and sprint discipline all affect the real number.
Budget-wise, GDD works best as an operating expense, a monthly retainer, rather than a capital project. That matches how the work actually happens: small, recurring sprints rather than one large invoice. It also means the finance conversation shifts from “how much did the redesign cost” to “what did this month’s sprint return”, which is a healthier question for a marketing-driven business to be answering.
When does growth-driven design make sense, and when doesn’t it?
GDD needs enough traffic to generate statistically useful data quickly. If a site gets a handful of visits a day, an A/B test can take months to produce a meaningful result. In that situation, qualitative signals, sales calls, support tickets, and short user interviews can substitute for split testing in the early rounds.
Beyond traffic, three organisational things need to be in place before GDD makes sense:
- Someone internally who owns the backlog and can make quick calls between sprints
- Access to analytics data and the willingness to actually look at it every fortnight
- A monthly budget that survives past the launchpad, since GDD without ongoing investment simply becomes a traditional redesign with extra jargon attached
For a small local business with a stable, simple offer and low website traffic, a well-built brochure site refreshed every couple of years can still be the right call. GDD earns its cost when the site is a genuine growth lever, not a digital business card.
How do you start a growth-driven design project in 90 days?
Most SMBs overcomplicate the start. The strategy stage should be short and sharp, not a month-long workshop series.
- Days 1 to 10: strategy. Interview five to eight stakeholders and a handful of real customers, audit existing analytics for drop-off points, and build a full wishlist of pages and features.
- Days 10 to 14: prioritise. Apply the 80/20 rule: identify the 20% of pages or features that will carry most of the value, a method Leanlabs outlines in its breakdown of the three GDD stages, and push everything else into the continuous improvement backlog.
- Days 14 to 75: build the launchpad. Ship the prioritised pages with clean analytics tracking already installed, not bolted on afterwards.
- Days 75 to 90: first two sprints. Run one structural experiment (form length, navigation) and one content experiment (headline, CTA wording), then report the results honestly.
Your measurement stack doesn’t need to be elaborate: analytics, a heatmap tool, and a basic A/B testing or no-code experiment builder cover most SMB needs without locking you into an expensive platform.
Pro Tip: Pick your three launchpad pages based on where visitors already spend time or drop off, not where the business wants them to spend time. Data beats internal wishlists every time.
What does GDD look like in practice at Done.lu?
We’ve run growth-driven design engagements as part of over 350 client projects since founding Done.lu in Luxembourg in 2014. In our experience, the sites that keep improving are the ones where a client actually reviews the sprint report every fortnight, not the ones with the biggest launchpad budget.
A typical Done.lu engagement includes:
- A strategy phase covering stakeholder interviews, analytics audit, and a prioritised wishlist
- A launchpad build on our website-as-a-service model, so ongoing sprints are already priced into the relationship rather than negotiated project by project
- Continuous improvement sprints with GDPR-compliant analytics tracking, relevant for clients in regulated sectors such as finance or healthcare
- Monthly reporting tied to visits, leads, and conversion rate rather than vanity metrics
The full growth-driven design workflow we follow with clients maps closely onto the strategy, launchpad, and continuous improvement structure described above.
What usually goes wrong with growth-driven design, and how do you fix it?
The single biggest failure mode isn’t technical. It’s budget. GDD depends on ongoing monthly investment, and once that budget lapses, the continuous improvement pipeline collapses and the project quietly reverts to a traditional, one-off redesign with a GDD label still attached to it. The fix is contractual, not creative: agree the monthly retainer and the minimum sprint commitment before the launchpad even launches, not after.
The second problem is ownership drift. Without one person accountable for the backlog, sprints get reprioritised by whoever spoke last in a meeting, and the ICE-scored plan gets abandoned within a month. Assign a single product owner, internal or agency-side, before day one of the strategy stage.
Third, teams launch the launchpad and then treat it as finished. That undermines the entire premise. The launchpad is a data-gathering foundation, not a finished product, built specifically to validate assumptions quickly rather than to look complete. Treating it as the final deliverable means the continuous improvement stage never properly starts.
Finally, low-traffic sites sometimes force statistical A/B tests too early and get inconclusive results for months. When traffic is thin, lean on qualitative inputs, sales conversations, support tickets, short customer interviews, until the sample size supports real testing. None of these pitfalls are exotic. They are organisational habits, and every one of them is fixable with a clear owner, a signed budget, and patience with the launchpad’s real purpose.
What tools support a growth-driven design process?
The tooling stack for GDD is deliberately modest. Four categories cover most of what an SMB needs, and none of them require locking into an expensive enterprise platform.
Analytics comes first, since every GDD decision traces back to it. Understanding how to read that data matters more than the specific tool, and analytics best practice in digital marketing applies just as much to a GDD sprint backlog as to a paid campaign.
Behaviour tools, heatmaps and session recordings, show where visitors actually click, scroll, and abandon a page, filling in the gaps analytics numbers alone can’t explain.
Testing tools, A/B or no-code experiment builders, let a team run and measure a structural or content change without waiting on a developer for every tweak. That speed is the entire point of a 14-day sprint; a change that needs three weeks of development defeats the cadence before it starts, a tension larger organisations navigate when scaling GDD, as Huble notes in its overview of growth-driven design for enterprises.
Project management ties the backlog, sprint board, and reporting together so the “Transfer” step of the CI loop actually happens instead of living in someone’s memory.
Resist the temptation to buy the biggest suite available. A lean stack that the team actually uses every fortnight beats an expensive one that gets opened once a quarter.
What does a successful growth-driven design project actually look like?
The pattern across successful GDD projects is consistent regardless of industry: a tight launchpad, disciplined sprints, and a team that treats the experiment log as seriously as the sales pipeline.
A B2B services firm might launch a launchpad built around three pages, home, one core service, and a contact form, and spend the first three sprints purely on conversion friction: form length, page load speed, and the clarity of the main call to action. E-commerce businesses often see the fastest movement in the checkout and product pages, since small friction reductions there compound directly into revenue. A practical guide to boosting website conversions walks through the kind of testing that fits neatly into these early sprints.
What separates a genuinely successful GDD project from a stalled one isn’t the size of the launchpad. It’s whether the sprint cadence survives past month three. Projects that keep the 14-day rhythm alive for six months or more tend to accumulate a long list of small, compounding wins, several high-impact, low-effort fixes applied one at a time rather than one dramatic relaunch. The ones that stall usually did so because the budget or the ownership disappeared, not because the method failed.
Lessons from running growth-driven design projects
The core lesson is simple: GDD only works if someone keeps showing up to the sprint review. The method itself is sound. The failure point is almost always human.
Three pitfalls recur more than any others: agreeing a launchpad without securing the monthly budget that follows it, launching without a named backlog owner, and expecting A/B-test-grade certainty from a site that gets thirty visits a day. Fix those three and the method mostly takes care of itself.
If there’s one takeaway worth acting on this week, it’s this: before you build anything, agree who owns the backlog and how the continuous improvement budget gets approved every month. Everything else in GDD is negotiable. That isn’t.
— Thomas
How can Done.lu help you run a growth-driven design project?
Done.lu builds websites on a website-as-a-service model, so continuous improvement isn’t a separate negotiation after launch. It’s built into the relationship from day one, with no setup fees and a transparent monthly structure that matches how GDD sprints actually run.
A typical engagement starts with a short strategy phase, stakeholder interviews and an analytics audit, followed by a launchpad build covering your highest-value pages, then fortnightly sprints reporting on visits, leads, and conversion rate. For businesses in regulated sectors, GDPR-compliant tracking is part of that setup from the start, not bolted on later. If you’re weighing up web development options for a redesign, or want to understand why investing properly in web development pays off over a longer horizon than a single project, that’s the conversation worth having before you commit to either a traditional rebuild or a growth-driven one. Get in touch through Done to scope a strategy phase and see what a launchpad would look like for your site.
Sources
For readers who want to verify the framework or go deeper on specific stages:
