How should a three-person growth-driven design pod be structured?

The method's continuous improvement cycle has four steps. The team plans around a focus metric and a prioritized set of work. It builds that work as a cross-functional team. It learns from the results, and it passes what it learned to marketing, sales and service.

Each step needs someone who is answerable for it. Planning needs a person who decides what the evidence says and what comes first. The build takes two decisions: what the change looks like and says, and how it's made to work on the live site. Learning depends on measurement that was set up before the change went out. For the fourth step, we'd have the strategist pass what was learned to the client's marketing, sales and service teams. Three people can cover those jobs when each knows which decisions are theirs.

The strategist decides what the pod works on. We'd give that decision to one person so a disagreement about priorities has a way to end. The designer and developer inform the ranking, since they know what each idea costs to make. The strategist makes the call and answers for it.

The designer decides how a change looks and reads. Copy sits here in our split because layout and words on a page are hard to settle apart. If your strategist is the stronger writer, move the copy there and say so. The developer decides how a change is built and confirms that its result can be measured before it ships.

Owning an area doesn't mean three people hold every skill a website needs. The skills depend on the work in front of the pod. A sprint that calls for a complex integration or a round of customer interviews is a reason to bring in a specialist for that sprint. The research itself can run deep, as we describe in how Jobs to Be Done and user research shape a growth-driven design strategy.

Every piece of work gets a second look from inside the pod before it goes to the client or the live site. The designer reads the brief and questions it. The developer checks the design against what the site can do. The strategist checks the finished change against the problem it was meant to solve.

The end-of-cycle review belongs to all three. The developer brings the numbers, and the designer adds what was learned in making the change. The strategist then records the decision and updates the ranked list.

Suppose a pod is working on a B2B software company's pricing page, and the focus metric is demo requests from that page. The strategist brings two pieces of evidence. Form data shows many visitors start the demo form and leave it unfinished. The sales team reports that buyers keep asking whether implementation is included in the price.

The strategist ranks two changes: add a line about implementation to each plan, and shorten the form from nine fields to five. The designer drafts the new plan copy and a shorter form. The developer reviews the form design and finds a problem. Four of the fields being removed feed the client's lead routing, and the sales operations manager wants them kept.

The form change is now waiting on a decision that nobody in the pod owns. The strategist owns the pod's priorities, but the form fields belong to the client's sales process. The method's launch process recommends naming one accountable stakeholder for each page, who can gather feedback from others. We'd carry that advice over to improvement work. The strategist takes the question to the client's named owner for the pricing page and sets out the trade-off: a shorter form against the routing data sales relies on. The strategist also asks for an answer by a set date.

The pod doesn't wait. The implementation copy has no dependency, so the designer finishes it and the developer ships it with tracking on demo requests. When the client's owner answers, the form change goes ahead, changes shape or is dropped. At the review, all three look at demo requests since the copy change, which may not show a clear difference yet, and decide what the next sprint starts with.

The method's site illustrates its cycle with 14-day sprints. Lean Labs' growth-driven design service runs 30-day sprints, and it draws on page behavior, form results, CRM lifecycle data and sales feedback to decide what goes into each one. Neither length is a rule, so the pod sets its own, and a sprint doesn't have to be long enough to show a result.

A change can ship in one sprint and be read in a later one, and some readings stay inconclusive. When work keeps spilling past the sprint, a longer sprint and smaller changes are two of the options. The three stages of growth-driven design covers where this ongoing work sits after strategy and launch.

A three-person pod describes how the work is divided. It doesn't say how many hours each person gives one client, or what the client pays.

Lean Labs, for example, describes its ongoing service as a fractional growth-driven design team on its page about the three stages. In an arrangement like that, the client buys part of a team's time. A pod can be three people who each spend part of their week on the account.

We'd keep roles, hours and price apart in the agreement. Roles describe who makes which decision, and they don't fix how many people fill them. Hours set how much capacity the client gets, and price is what that capacity costs. We go through the agency's arithmetic in how an agency should price growth-driven design, and the buyer's side in how much growth-driven design costs.

A queue that keeps forming behind one role is the signal to look at. If designs keep waiting on development, the pod can add build capacity or take on smaller changes. If the strategist spends the cycle coordinating and has no time left for research, the pod can narrow what it takes on or move the coordination to someone else.

A specialist needed in most sprints raises the same kind of question. That can mean a fourth role, or a standing arrangement with an outside partner. Either way, we'd name who owns that work so it doesn't fall between the three.