Shipping starter templates from practitioner workflows
An empty product asks a new user to design their own system before they get anything back. The structures they would have designed are already on screen in the videos where practitioners show their setup.
The short answer: find the structures that several unrelated practitioners build by hand in the same way, ship the most common one as your default and the next three or four as templates, and fill them with realistic sample data that can be cleared in one action. The goal is for a new user’s first act to be editing, never inventing.
Every flexible product has the same weak moment. A new user signs up, lands on an empty workspace and is asked, in effect, to decide how they want to work. Most have never thought about it in those terms. They close the tab and go back to the spreadsheet, which at least already has columns.
The fix is well known and unevenly applied. Templates are often written by the product team from imagination, which produces structures that look tidy and match nobody’s actual practice. The alternative is to take them from people who already do the work.
Where the structures are visible
Practitioners show their setups constantly, usually without intending to teach structure. Certain kinds of video are especially rich.
Setup tours. “Here is how I organise my client work” videos show the whole structure at once: the stages, the fields, the views.
Build-alongs. A creator constructing a tracker from scratch in a spreadsheet or a general-purpose tool reveals which fields they consider essential, in the order they think of them.
Template giveaways. When creators offer their own template to viewers, the existence of the offer is itself evidence that the audience struggles with a blank page. Note what the template contains at the level of structure, and do not copy it.
Workflow walkthroughs. Watching a process run from start to finish shows the stages a record passes through, which become the statuses in a template.
Many of these structures are workarounds built in tools that were never designed for the job, and reading them as product requirements is the subject of spotting manual workarounds in creator content.
Recurrence separates templates from preferences
One creator’s setup is a personal preference. The same setup in five unrelated videos is a convention of the field. Only conventions make good templates, because a template has to feel familiar to people who have never seen that particular creator.
| What recurs across sources | What it becomes in the product | Evidence threshold |
|---|---|---|
| The same stages in the same order | Default statuses or pipeline | Most sources agree |
| The same handful of fields on every record | Default fields, pre-created | Most sources agree |
| Two or three distinct ways of organising the same work | Separate templates, one per approach | Each seen in several sources |
| A recurring checklist for a repeated task | Reusable checklist template | Several sources, similar items |
| An unusual structure from one articulate creator | Nothing yet | Not met; note and wait |
The field-level detail overlaps with data modelling. If practitioners consistently track the same attributes under the same names, those names belong in your schema as well as your templates — the connection is drawn in designing your data model from domain vocabulary.
Choosing what to ship
A first version needs one default and a small gallery. The default is the single most common structure, applied automatically so that a user who chooses nothing still lands somewhere sensible. The gallery is the next three or four, each named for the situation it fits rather than for a feature.
- ✗A gallery of thirty near-identical options
- ✗Names like 'Basic', 'Advanced' and 'Pro'
- ✗Placeholder rows reading 'Item 1', 'Item 2'
- ✗Structures invented in a planning meeting
- ✓Three to five clearly different starting points
- ✓Names describing a situation the user recognises
- ✓Realistic sample records showing what good looks like
- ✓Structures seen repeatedly in real practitioner setups
Naming matters more than it appears to. A template called “Monthly retainer clients” tells a user immediately whether it is for them. One called “Template B” requires them to open it and work it out. The names should come from the language practitioners use for their own situations, the same source used in naming your product from research vocabulary.
Borrowing patterns without copying people
There is a clear line here and it is worth stating plainly. A general pattern that appears across a field — a pipeline with a few common stages, a tracker with the usual fields — is shared practice. A specific creator’s named system, their exact wording, their layout or a template they sell is their work.
Build templates from what many independent sources have in common, expressed in your own structure and words. Never reproduce one creator’s template, and never use a creator’s name to label one without their agreement. The research records sources so that you can check each template rests on a pattern and not on a person.
The wider habits of attribution when research draws on creators’ work are covered in citing creators properly.
Sample data that teaches
A template with empty rows is only half a template. Sample records show how the structure is meant to be used: what a filled-in entry looks like, how much detail is normal, what a record looks like at each stage. They also make the first screen look like a working product rather than a form.
Three rules keep sample data useful. It should be realistic enough that a practitioner recognises the scenario. It should cover each stage, so every part of the structure is demonstrated. And it must be removable in one obvious action, because data a user has to delete row by row turns from help into a chore.
Checking that templates work
Templates are an onboarding intervention and should be judged as one. The question is whether users who start from a template reach the activation event more often, or sooner, than those who start blank. Choosing that event in the first place is covered in picking your activation metric from research.
Two secondary signals are worth watching. If almost everyone picks the same template, it should probably be the default and the gallery can shrink. If users pick a template and immediately delete most of it, the structure is wrong for them, which is a prompt to go back to the corpus and look for the variant you missed. The onboarding context these templates sit inside is described in designing onboarding from where people stall.
Templates outside the product
The same research has a second use. A well-made template is something people search for, share and link to, and a public version can bring in exactly the users who have the problem your product solves. A downloadable spreadsheet version of your default structure, offered freely, is a credible introduction to the product that does the same job with less effort. Where to put such an asset so that it is found is part of choosing where to launch from distribution signals.
What this costs
Setup tours and build-alongs are plentiful in most fields, so a template corpus of 20 to 30 videos is easy to assemble. As of October 2026, Hobby is $19 a month with 25 videos and 2 projects, Pro is $59 with 80 videos and 8 projects, and Studio is $199 with 250 videos, 20 projects and 3 seats, each with a 7-day free trial — see the pricing page.
Synthesise setup tours and build-alongs to see which structures recur across independent creators, with sources attached. 7-day free trial.
Closing thought
Nobody arrives at a new tool wanting to design a system. They arrive wanting their work to be easier by this afternoon. A good template is the product admitting that it already knows roughly how the work goes.
Frequently asked
Why do starter templates matter so much for a new SaaS?
Because an empty product asks a new user to do design work before they receive any value. A template that mirrors how practitioners already structure their work lets someone start by editing rather than inventing, which is a far smaller ask in the first five minutes.
How do I know which templates to build first?
Look for structures that several independent practitioners build by hand in broadly the same way: the same columns, the same stages, the same checklist. Repetition across unrelated sources is the signal. A structure only one creator uses is a preference, not a template.
Is it acceptable to base a template on someone's video?
Base it on the pattern shared across many sources, in your own words and layout, rather than reproducing one creator's work. Generic structures such as a pipeline with common stages are not anyone's property, but copying a specific creator's named system, wording or paid template is neither fair nor wise.
How many templates should a first version ship with?
Three to five, each clearly different. A long gallery pushes the choice back onto the user and recreates the blank-page problem one level up. Add more only when support questions or usage show a gap.
Should templates include sample data?
Usually yes, provided it is realistic and easy to clear. Sample rows show what good looks like and make the first screen legible. Obvious placeholder text teaches nothing, and sample data that cannot be removed in one action becomes clutter.
What is the difference between a template and a default?
A default is what the product does when the user has made no choice. A template is a chosen starting structure. Research informs both: the most common setup across practitioners is a good default, and the next few most common are the template gallery.
What does this research cost?
As of October 2026, Hobby is $19 a month for 25 videos and 2 projects, Pro is $59 for 80 videos and 8 projects, and Studio is $199 for 250 videos, 20 projects and 3 seats, with a 7-day free trial on every plan.