Which templates, checklists, and worksheets help teams run growth-driven design?

Growth-driven design runs on a small set of reusable documents, and the method's creators publish them free on growthdrivendesign.com so teams do not have to build the paperwork from scratch [1]. The documents sort into the three stages of the method. Strategy uses a goals document, a persona template, a fundamental assumptions template, and a journey mapping template, all editable files that capture what a team believes before it builds anything [1]. Research uses the rainbow spreadsheet, a tracker for consolidating usability observations across participants [1]. Continuous improvement uses an action item document and the GDD dashboard, which the official tool guide describes as the place to track performance, set the quarterly theme and sprint focus, and manage and prioritize the wish list [1][5]. A prioritization layer sits across all three stages: the GDD hierarchy cheat sheet orders improvement work from audience building through personalization, and independent guides describe the same website hierarchy as the roadmap for deciding what to work on next [1][4].

The templates are only half of the official toolkit. HubSpot Academy publishes a free Growth-Driven Design certification course that teaches the method the documents support, from strategy and the launchpad through the continuous improvement cycles, plus a companion Growth-Driven Design Agency course for teams that deliver the work as a service [2][3]. That pairing matters, because a filled-in template is only as useful as the thinking behind it. A persona sheet with no research is a guess in a nicer font, and a wish list with no scoring rule is a backlog nobody can act on. The rest of this page walks each document in turn: what it is, the stage it serves, and how experienced teams use it well rather than mechanically.

The strategy worksheets capture what a team believes about its users and goals before a single page gets designed, and there are four of them [1].

The goals document

The goals document records the measurable outcomes the website is accountable for, such as leads, demo requests, or revenue, before any layout decisions get made [1]. Use it to force agreement on a small number of primary metrics rather than a long list of nice-to-haves. Its value is that every later prioritization call can be checked against it: an idea either moves a stated goal or it waits.

The persona template

The persona template documents who the site serves, what they are trying to accomplish, and the questions, concerns, and objections they carry into a buying decision [1]. Use it as an interview output, not an imagination exercise. Personas built from real conversations with customers, sales, and support hold up under testing, while personas invented in a conference room tend to describe the buyer a team wishes it had.

The fundamental assumptions template

The fundamental assumptions template records what a team currently believes about its users and why, so those beliefs can be tested rather than assumed [1]. Use it to separate fact from hypothesis at the start of a build. Its real payoff arrives later: when the data comes in, the team has a written before-and-after that keeps the learn step honest instead of letting hindsight quietly rewrite what everyone thought.

The journey mapping template

The journey mapping template lays out how a buyer moves from first contact toward a decision, and it feeds directly into page architecture [1]. Use it to decide which pages exist and in what order, not just to illustrate a funnel. A journey map that ends at a form is incomplete; the strongest versions carry the buyer through the questions they ask at each step and name the page that answers each one.

The wish list is the running backlog of every improvement idea a team could make to the site, gathered from analytics, user research, sales feedback, and stakeholder requests [1]. The prioritization sheet ranks that backlog so the team always knows the next highest-value move. During continuous improvement the ranked wish list lives inside the official GDD dashboard, which the tool guide describes as the place to manage and prioritize the wish list alongside performance tracking [5].

To use it well, score ideas against a stated rule rather than gut feel. Many teams order the list with the website hierarchy, which ranks work across eight elements from audience building up through personalization, so foundational fixes come before advanced personalization that would only sit on a weak base [4]. Keep the list alive between sprints. A wish list that gets opened only during planning turns stale; the teams that get the most from it add to it continuously as new data and requests arrive, then re-rank at each sprint boundary [1]. The sheet does two jobs at once here. It is the intake for every idea so nothing gets lost, and it is the ranked queue that decides what the next sprint actually builds, which is why the ranking method matters as much as the list [4][5].

The launchpad scope checklist is the filter that turns a long wish list into a short build plan, and its governing rule is to start with only the highest-impact ideas rather than the whole list [8]. In practice that resolves to 3 to 5 highest-impact pages instead of a full site, so the new site can launch quickly and start collecting real user data in a fraction of the time a traditional redesign takes [8].

Use the checklist to make scope decisions explicit and defensible. Each candidate page or feature earns its place by moving a stated goal from the goals document, not by being someone's preference. Items that do not make the first cut are not deleted; they move back to the wish list to be funded later by the performance the launchpad earns. The discipline the checklist enforces is restraint. A launchpad is meant to be a strong, publishable starting point rather than a finished site, and the pull to add just one more page is exactly what the highest-impact-only rule exists to resist [8]. A useful test for each line on the checklist: if this page were missing at launch, would a real buyer be unable to make a decision? If the answer is no, it belongs in a later sprint.

The continuous-improvement tracker is the GDD dashboard, the document that carries performance metrics, the running experiment backlog, and the plan for each sprint from one cycle to the next [5]. The official tool guide describes it as the single place to track performance, set the quarterly theme and sprint focus, and manage and prioritize the wish list [5]. The action item document works alongside it, capturing the specific tasks each sprint commits to [1].

Use the two together on a fixed rhythm. Practitioners describe a cadence of short sprint cycles on individual improvements, punctuated by quarterly summits that review what shipped and set the next quarter's focus, and the dashboard is what carries context between those two rhythms so no sprint starts from a blank page [7]. Record the result of every experiment, not just the ones that win. A backlog that logs both the changes that moved a metric and the ones that did not is what keeps a team from re-testing the same idea a year later, and it is the raw material for the quarterly review [7]. The continuous improvement stage has no end date, which is why the tracker is a living document rather than a project artifact you close out and archive [7].

The official resources come from two places. growthdrivendesign.com hosts the resource center with the working documents, the hierarchy cheat sheet, methodology graphics, a what-is-GDD slide deck for internal pitching, and links to the GDD Slack community [1]. HubSpot Academy hosts the training: a free Growth-Driven Design certification course that teaches the full method the documents support, and a separate Growth-Driven Design Agency course for teams that sell the work as a service, including how to package ongoing improvement retainers [2][3].

Use the certification to build shared vocabulary before a team fills in a single template, because the course explains why each artifact exists: what a fundamental assumption is, how a journey map feeds page architecture, and how the wish list gets prioritized into sprints [2]. HubSpot's Academy course frames the payoff of the method as launching a site with less risk and then improving it continuously with real user data rather than guesses, which is the case most teams make internally to get the program approved [2]. Both sets of resources are free, which removes cost as a reason to skip the setup work the method depends on [1][2].

The templates encode the method's minimum, not its ceiling, so the main risk is treating a completed document as finished thinking [1].

A filled-in template is not a validated strategy

A completed worksheet feels like progress, but a persona or assumptions sheet written without research is a hypothesis, not a finding [1]. Use the documents to structure interviews with customers, sales, and support, then revise the sheets against what those conversations reveal.

The wish list needs a scoring rule

A backlog with no ranking method turns into a list of everyone's preferences, which is why the hierarchy and a scoring model matter as much as the list itself [4]. Pick one prioritization rule and apply it consistently so the order of work stays defensible rather than political.

The templates are a starting point you will outgrow

Mature teams typically extend the official documents with their own scoring models and research formats rather than abandoning them [7]. Treat the free templates as the shared baseline, then adapt the fields to the questions your market actually asks.

The dashboard only helps if it stays current

A tracker that is updated once a quarter cannot guide a sprint, and the continuous improvement stage has no end date, so the dashboard has to be maintained as a living document [7]. Update metrics and log experiment results every cycle, not only at the quarterly review.