How does growth-driven design support marketing, SEO, B2B, and SaaS websites?

The method's continuous improvement cycle has four steps. The team plans around a focus metric, builds the change, learns from the experiments and the data, and transfers what it learned to marketing, sales and service. The cycle doesn't say which metric to choose. That choice comes from what the business needs from the site right now.

Marketing, SEO, B2B and SaaS aren't four separate kinds of site. A B2B software company can run campaigns, depend on search and sell through a sales team and a self-service signup at once. The cycle suits a site like that because it asks for one focus at a time. The team works on the constraint that matters most this cycle and takes up another one afterward. For a fuller description of the stages, see how growth-driven design works from strategy through continuous improvement.

Marketing sends people to the site through campaigns, email and ads, and wants them to respond when they arrive. The site's part is the page they land on and the form or offer on it.

Any team can edit a landing page between redesigns. What the cycle adds is a scheduled place for that work, a metric chosen in advance, and a review of what happened. Suppose a webinar campaign brings plenty of visits and few registrations. The team makes a shorter form this cycle's change and registration rate its focus metric. If the campaign sends enough visitors, the review gives the team something to act on before the next campaign. If it doesn't, the team has a recorded change and a question to carry into the next one.

The transfer step sends learning the other way. If visitors respond to a headline about saving audit time and ignore one about features, the email and ad teams have something to try in their own channels. Treat that as a lead for them to test, since a message that worked on a web page hasn't yet been shown to work in an inbox.

Where a B2B company sells through a sales team, a form fill is the start of a sales process, so the count of leads says little alone. The business wants inquiries that sales accepts and that become pipeline. Measuring that means following a lead past the form. A CRM is a practical way to do it, and the team also needs to hear from sales.

Lean Labs' growth-driven design program is built around that connection. The agency reviews page behavior and form results alongside CRM lifecycle data and feedback from the client's sales team. It ranks possible changes by expected effect on pipeline, by buyer relevance and confidence, and by effort. The work it lists covers messaging, forms, calls to action, personalization and lead routing.

Sales feedback can become a page change in a few steps. Suppose sales reports that half of last month's demo requests came from companies too small to buy. The page data shows most of those requests started on a pricing page that never says who the product is for. The team adds a line naming the company size each plan suits and puts a company-size field on the form. The focus metric for the cycle is demo requests that sales accepts, read from the CRM.

Suppose total requests then fall while accepted requests hold steady. Sales now has fewer requests to screen for the same number it accepts. That can save screening time if rejected requests required manual review. It isn't proof that the page change caused the shift, because the mix of visitors could have changed in the same weeks. The team records the result, keeps the change, and watches another cycle. We cover the B2B case at more length in how growth-driven design works for B2B websites.

On a SaaS site with a free trial or self-service signup, the visitor can go from a web page into the product with no salesperson between them. What the site says about the product helps shape what new users expect.

That opens up focus metrics at the signup and beyond it. Trial starts are one. Another is trials where the user completes setup, which tells you how many got started. Reading that number means joining site data to product data, in the same way the B2B example joined form data to the CRM.

It also adds a source of insight. Support tickets and onboarding calls show what new users expected the product to do. Suppose several tickets in a month come from users who expected an integration the product doesn't have. The team checks the feature page those users came through. If the page implies the integration exists, rewriting it is a candidate for the next cycle, with completed setups among visitors to that page as the measure. If the page is accurate, the team checks whether it's easy to misread, and then looks at ads, reviews and sales conversations.

Software products change, and the site has to describe the current one. An improvement cycle gives pricing and feature updates a regular place to be scheduled, provided the team keeps hours in each cycle for them. For a young company with a small team, growth-driven design for startups covers how to scale the method down.

Growth-driven design is a way of organizing work. It has no ranking mechanism of its own, and running it doesn't make pages rank. What it gives search work is a regular slot in which to do the things search depends on, and a habit of checking results afterward.

The launch is the first place this matters. In the method, a site begins with a first version called a launchpad. If that launch changes, merges or removes URLs, Google's guidance on site moves with URL changes applies. It recommends mapping each old URL to its corresponding new one and using permanent server-side redirects that point straight at the final destination. It also recommends updating internal links, canonical tags and sitemaps, and generally keeping the redirects in place for at least a year.

The same guidance covers pages that are being dropped. A page folded into a broader one can redirect to it. A page with no replacement can return a 404 or 410. Redirecting many unrelated pages to one destination risks having them treated as soft 404s. Google also says rankings can fluctuate while it recrawls a moved site, so careful redirects reduce the risk without removing it. Before you cut a page for getting no search clicks, check whether it earns links or supports sales conversations, because clicks are only one of the things a page can be doing.

After launch, a cycle can take on a search task: rewriting a page that ranks for a term and doesn't answer the question behind it, or fixing a slow template. Google's page experience documentation says Core Web Vitals are used by its ranking systems and that good scores don't guarantee top rankings. So a speed fix is worth doing for visitors, and any effect on rankings is something to observe afterward.

Reading a search result takes care, because rankings move for reasons that have nothing to do with your edit. Keep a dated log of what was changed. The log won't tell you why a ranking moved. It tells you which changes came before the movement and which came after, which is where an investigation starts.

The cycle learns from what visitors do, so it needs a way to tell what happened to them, and enough visitors for the method of learning the team chooses. Whether a page can support a split test depends on its traffic, its conversion rate and the size of difference you're looking for. When it can't, interviews, sales conversations and usability sessions are evidence too. They show how buyers think and where they get stuck, and they don't measure how far a number moved. We explain how to work with both in turning user insights into hypotheses and experiments.

It also needs someone with the authority and the hours to keep going. A team learns a good deal from the strategy work and the launch. The learning the method is built around comes from the cycles afterward, so a company that plans to stop at the launchpad should weigh that against a conventional redesign, a decision we go through in who should invest in growth-driven design and when it's the wrong fit.