How does growth-driven design work for B2B websites?

The method's strategy stage has a team understand its customers, set objectives and turn an organized wishlist of ideas into an implementation plan. A B2B firm with a sales team has a direct source for that understanding, because its reps hear buyers' questions on calls.

Suppose a firm sells inventory software to distributors. Its sales team reports that prospects keep asking the same thing partway through the first call: does the software connect to the accounting system they already run. The current site has one sentence on the subject. The team sets a goal of more qualified demo requests and writes down its assumption that buyers who can't confirm the connection early are leaving before they ask.

That assumption puts an integrations page that names each supported accounting system at the top of the wishlist, along with a demo form that asks which system the buyer uses. We cover how to test a starting belief like this one in validating the assumptions behind a growth-driven design strategy.

The method describes the launchpad as a foundation for collecting user data and improving the site, and it's clear that the first release isn't the final product. For the inventory firm, that first release has the home page, the product page, the new integrations page, which carries the demo form, and the demo request page. Case studies for each industry it serves stay on the wishlist until the team knows which industries its visitors come from.

The method sets a goal of 60 to 90 days for a launchpad, and Lean Labs' growth-driven design program plans the same range after a strategy phase of 10 to 14 days. Both are stated targets for a first release of limited scope. This firm's launchpad also needs its demo form to write the buyer's answers into the CRM, because the team plans to review its changes against that record.

After launch, the method's improvement cycle repeats four steps: plan around a focus metric, build, learn from the results and transfer what was learned to marketing, sales and service. Suppose the firm's first focus metric is demo requests from the integrations page. The team moves the list of supported systems above the form and publishes the change. Three records then describe what followed, and each one says something different.

More demo requests is a good first sign, and it leaves the main question open. Suppose requests rise by a third after the change, and sales finds that most of the new requests come from companies too small to need the product. The page is producing more forms and more wasted calls. The form count alone would have recorded that cycle as a success.

The reverse can happen as well. Requests can hold steady while a larger share of them qualify. That would happen if the list of systems let buyers on an unsupported system rule themselves out while more buyers on a supported one asked. A team watching only the form would see no change, and it would miss that the same number of calls was going to better-fit buyers.

So the CRM records belong in each cycle's review. Lean Labs describes choosing its improvement work from page behavior, form results, CRM lifecycle data and sales feedback. It ranks candidate changes by expected pipeline impact, by buyer relevance and confidence, and by effort, and its program includes lead routing as well as page work. In the example, the form's question about the buyer's accounting system tells the team which integrations visitors care about. If the firm adds a routing rule for that field, the CRM can also send the lead to a rep who knows that system. We go further into the reporting side in what metrics to track in growth-driven design.

Lean Labs runs its improvement sprints over 30 days, and the method's overview models 14. Suppose the inventory firm's deals take about four months from demo to signature. On that assumption, a sprint ends before most deals that started from its change have closed.

The team still has to choose what to do next. It can keep the change, drop it or leave the question open while more leads come in, and it makes that call on the requests and on the early word from sales about quality. It records the reason and the date. When deals from that period close, it goes back to the record and looks at how the leads from the changed page turned out.

Revenue is also the hardest of the three records to tie to a page. A deal that closes in month four passed through calls, a quote and often other pages. The CRM can show which customers have the changed page recorded as their source. That record isn't the whole history of the deal, and it doesn't show that the page won it.

Suppose the firm's market is narrow and the integrations page gets modest traffic. A split test shows two versions of a page to visitors over the same period, and it needs enough of them to tell the versions apart. On this page, that can take longer than a sprint, and sometimes longer than the team is willing to wait.

Lower traffic doesn't stop the method. The team can interview recent buyers, watch a few of them use the page and ask sales what prospects said on calls that week. Those sources can suggest reasons for what buyers do, which a split test doesn't supply. The team should be plain about which kind of evidence it has. A before-and-after comparison shows whether a number moved, and it leaves the cause open. We cover the planning of these tests in turning user insights into hypotheses and experiments.

Lean Labs' account of its redesign for Integrate describes related practices on a B2B site. The agency says it clarified Integrate's value proposition, tested messages and calls to action, simplified the site's menu and offered a preview of the platform. It reports that the rate of visits becoming contacts rose 271% within 60 days of launch.

That figure is a rate. It sits closest to the demo-request count in the example, though it measures the share of visits that became contacts and gives no count of them. Read by itself, it doesn't tell you how many of those contacts were qualified or what they were worth. A before-and-after figure also doesn't separate the redesign from anything else that changed in the same period, which is the limit we keep in view in growth-driven design case studies.