What happens during the continuous improvement stage and harvest period?

Lear's article on how growth-driven design goes wrong warns that teams can go straight to the wishlist after launch. The site is live, everyone is excited, and the pages and features that didn't make the first release are waiting.

The trouble with that is timing. The wishlist was written before launch. Some of its items rest on research from the strategy stage, and others are opinions nobody has checked. Live behavior can confirm an item, move it down the list or take it off. A team that builds first and looks later gives up that chance to reorder the work.

So the first job is to record where things stand. The team notes where visitors arrive and leave, and how many of them fill in a form. Those figures become the baseline that later changes are measured against.

Confirmed defects are one kind of quick win, such as a broken link or a form that fails to submit. Other findings are signals. A form that people start and abandon, or a page with a high exit rate, tells the team where to look. It takes more investigation to learn what's wrong there.

That distinction also settles what waits and what doesn't. A confirmed defect gets fixed as soon as it's found. The larger wishlist work waits for evidence, and evidence here includes the visitor data, the research already done in strategy and what sales is hearing.

The term is also used more broadly. Digital Media Stream's guide to growth-driven design calls the whole third stage the harvest period and puts the full improvement cycle inside it. If the phrase appears in a plan, ask which meaning the writer intends. One is an opening phase, and the other is the ongoing stage.

After that first look at the data, the stage settles into a cycle. The method's continuous improvement page describes four steps, and each pass through them is a sprint. The site the cycle works on is the launchpad, which we explain in what a launchpad website is.

The focus metric gives the sprint a target. With one number in view, such as demo requests from the pricing page, the team has a way to choose between ideas and a way to judge the result. A sprint that mixes changes aimed at different results is harder to assess, because no single measure covers all of them. We go into choosing that number in what metrics to track in growth-driven design.

The learn step is how one sprint informs the next. The method's page says that finding out what doesn't work also feeds the next plan. The results record what the team observed, and that's all they record. A test with no clear winner doesn't establish that the change had no effect, and it doesn't identify a cause. The record is still worth keeping. Digital Media Stream's guide recommends documenting findings so the team can spot trends from one cycle to the next.

Lear describes a habit seen in this stage. Teams put their ideas and resources into new pages and modules, on the theory that more material brings better results. In Lear's view the quickest wins often come from improving existing items, because the team already has data on them. The recommendation is a mix of new work and improvements to what's there. We cover ranking the two against each other in how teams organize a growth-driven design roadmap.

The team works from two kinds of evidence, and they answer different questions. Behavior data shows what visitors did. Interviews and sales conversations help the team investigate the reasons. A high exit rate on a page tells you people are leaving it. A question about pricing that sales hears again and again is a lead, and the next step is to check it against what the pricing page says.

A controlled test compares two versions directly. HubSpot's page A/B test, which is part of Content Hub Professional and Enterprise, shows one version of a page to half the visitors and a second version to the rest. HubSpot recommends testing one variable at a time. That suits a headline or a call to action. Some changes don't need a test. Repairing a form that fails on phones is an improvement whether or not anyone tests it.

A test also runs on its own clock. A sprint is a work schedule. How long a test needs depends on the page's traffic, how often visitors convert and how large a difference the team is looking for, among other things. So a test started in one sprint can still be running when the next one begins.

Lean Labs' growth-driven design program shows how these pieces fit together in a published service. It works in 30-day sprints on HubSpot. It looks for friction in four places: page performance, form behavior, CRM lifecycle stages and sales feedback. Then it ranks the opportunities by their expected effect on pipeline, their relevance to the buyer, the team's confidence and the effort required. The page includes an illustrative sprint board. It lists a pricing page change as shipped, a homepage test as still running, a form fix as in progress and a comparison page as planned. The example makes a useful point about the stage, which is that work in a sprint sits at several steps of the cycle at once.

Sales feedback gets its own routine. Lean Labs' post on the three stages recommends a brief weekly or biweekly meeting where sales shares the questions and objections it's hearing. Those go on the same backlog as everything else and get scored the same way. This is the transfer step running in both directions, since the web team passes its findings to sales and sales passes its calls back.

Continuous improvement is an ongoing way of working, so the method gives the stage no finish line. That describes the method. It doesn't describe the length of any agreement with an agency, which has its own terms.

What a team should expect at each checkpoint is a plain account of the changes made and what happened to the focus metric afterward. Lean Labs' service page describes a report like that at the end of each quarter, with the next priorities attached. If changes keep shipping and the number stands still, the next plan should question the ideas being chosen before it adds more of them.