What content should I create to help prospects understand a new category?

Start with the decision the buyer already understands

Category content should help a buyer compare ways to accomplish a job and decide whether your product fits. Begin with the current workflow and its limitations before asking the buyer to adopt a new label.

For a post-seed startup, the immediate problem may be that prospects cannot place the product in a familiar purchasing decision. More articles about the future of the category may not resolve that. A buyer needs to know what changes, what remains their responsibility and how the choice compares with doing nothing.

Treat category creation as one positioning option. April Dunford’s positioning method connects alternatives, differentiated capabilities, value, target customers and market category. It is a practitioner’s method for establishing useful context, not evidence that every startup should create a category.

If the underlying distinction is still unclear, start with positioning in a crowded market. The explanation pack should express a defensible position rather than compensate for an unresolved one.

Map the current alternative in the buyer’s words

The relevant alternative is what the buyer would actually do without the product. That may be a familiar tool, an internal process, a spreadsheet or leaving the problem unresolved.

Dunford’s discussion of competition explicitly includes the status quo and manual alternatives. Ask buyers about those choices before constructing a comparison with the competitors your team happens to watch.

Capture the job, current steps, owner, frustration and consequence. Preserve the buyer’s language separately from your interpretation. A complaint does not automatically imply readiness to replace the process. Ask what still works and why the current alternative remains acceptable.

The GOV.UK user-needs guidance recommends researching current behavior and treating unsupported suggestions as assumptions. Applying that to commercial content means keeping unverified buyer problems out of declarative claims.

Use the resulting language in the homepage message for a seed startup. A category explanation and homepage should describe the same buyer and practical change.

Choose the least unfamiliar frame that explains the value

An existing category can supply useful context; a new category can express a different approach while increasing the burden of explanation. Compare those options against actual misunderstanding rather than choosing the most ambitious label.

Framing option	When to consider it	What the content must clarify	Main downside
Familiar category	Buyers recognize the job and purchase route	Why this product fits a particular situation	Buyers may assume features it lacks
Familiar category with a qualifier	The workflow is known but the approach differs	What the qualifier changes in practice	The qualifier can become vague decoration
Comparison with a current alternative	Buyers understand the workaround better than the market label	What changes and what remains	Can inherit the alternative’s assumptions
New category explanation	Familiar frames create a consequential misunderstanding	Job, boundaries, value, implementation and comparison	Requires more teaching before evaluation

Test a simpler frame first. If buyers understand the practical difference but reject the fit, a more novel category name may only hide useful feedback. Keep the option to describe the product plainly without making the buyer learn a new market vocabulary.

Read also: deciding which technical terms to remove, define or keep in a product explanation.

Build a compact champion’s explanation pack

A champion needs material they can share with colleagues who missed the founder’s explanation. Build a connected pack that answers practical questions without requiring the champion to invent the missing details.

Use six components:

1. A plain-language category page. State the job, familiar alternative, practical difference and fit boundary.
2. A worked workflow example. Show input, steps, responsibilities, output and an exception.
3. A fit and non-fit comparison. Explain the conditions under which the product is useful or premature.
4. An implementation note. Identify required access, data, people, dependencies and ongoing work.
5. An evidence page or section. Separate demonstrated capability from an untested benefit or planned feature.
6. A decision brief. Summarize the choice, open questions and next evaluation step for another stakeholder.

These can be sections of one page at first. Separate documents become worthwhile when different readers need different depth. The goal is useful explanation, not a publishing quota.

Connect the pack to content that supports outbound. A prospect following an outreach link should find a coherent explanation of the same claim, including limitations.

Show a worked example without inventing customer results

A worked example should make the mechanism inspectable without presenting imagined outcomes as evidence. Label a hypothetical workflow clearly and show which capabilities would need verification in the actual product.

Consider this schematic example for a product that proposes to coordinate an approval process. It is an explanation design, not a customer case or a statement that a particular product has these features.

Part of the explanation	Current workflow to investigate	Proposed workflow to demonstrate
Input	A request arrives in a shared inbox	The request enters a defined intake
Context	A person searches for missing information	Required context is shown or requested
Decision	An owner decides whether it can proceed	The same owner sees a structured proposal
Action	An approved instruction is copied to another tool	The approved version moves through a tested connection
Exception	An ambiguous request is handled manually	The ambiguity stays in a visible review queue
Evidence	The team reconstructs what happened	The demonstration shows source, approval and resulting action

The explanation must then state what the real product actually supports. If a step is manual, say so. If an integration is planned, do not draw it as an available automatic connection. Do not add a time-saving percentage or customer outcome without evidence.

Show one failure path as well as the ideal path. A buyer learns more about implementation from what happens when required context is absent than from another broad claim about transformation.

State fit, non-fit and implementation effort together

A buyer should be able to rule the product out from the explanation. Put prerequisites and ongoing responsibilities near the value claim so suitability can be assessed before a sales process expands.

Record who owns the workflow, which systems must connect, what information is required and which decisions remain human. Explain who reviews exceptions, maintains access and handles changes after launch.

Use specific non-fit conditions. A proposed coordination product may be premature when there is no repeatable process or no owner who can approve the result. Another product may be unsuitable when the required source data cannot be accessed. Use the actual product’s limits rather than generic warnings.

Avoid presenting implementation as a detail to discuss only after a meeting. A buyer may agree with the value while lacking the people or process to realize it. Helping that buyer choose a simpler alternative preserves a clearer understanding of what your product is for.

Keep this aligned with the startup’s first go-to-market strategy. The category should support the chosen beachhead instead of expanding the audience beyond what the product can serve.

Test whether another stakeholder can explain the choice

An explanation test observes whether a likely buyer can use the material to make sense of a decision. Ask for tasks and a retelling rather than agreement with the founder’s preferred language.

GOV.UK’s moderated usability guidance recommends observing relevant users attempting tasks and thinking aloud. The following buyer exercise applies that approach to explanation content:

1. Give a likely buyer the material without a live product pitch.
2. Ask what job the product addresses and what they would use instead.
3. Ask them to describe the workflow change and the responsibilities that remain.
4. Ask them to identify a suitable situation and an unsuitable one.
5. Ask what they would need to verify before recommending evaluation internally.
6. Give the same pack to a second stakeholder who did not help write it.
7. Compare both explanations with the actual product boundary and revise misleading passages.

Do not reveal the desired answer inside the task. If the participant needs a founder explanation, record the missing content before helping. Their confusion is useful evidence about the page.

Keep a decision brief and a claim record

A decision brief should let the champion summarize why evaluation is worth doing and what remains unresolved. A claim record keeps that brief consistent when the product or evidence changes.

Decision brief field	Content to preserve
Job and current alternative	The buyer’s task and present route
Proposed change	The capability that changes a specific step
Expected value	The consequence, with evidence status
Fit boundary	Who benefits and who should choose another route
Implementation	Required systems, people and ongoing work
Open questions	What the buyer and seller still need to establish
Evaluation step	A bounded demonstration or investigation with an owner

For each claim, record the source, approver and pages where it appears. A product change should trigger review of affected explanations. If evidence weakens, revise the claim instead of keeping an attractive sentence because it is already distributed.

Publish enough to support the next decision

Broad category publishing is premature when buyers cannot explain the product’s immediate value. First make the core explanation useful, then expand around questions that actually arise during evaluation.

Use the retelling exercise as a publication checklist. Resolve a misunderstanding in the core pack before distributing the affected explanation more widely:

Retelling check	Revise before wider publication if
Job and current alternative	The reader cannot name the job or compares against an alternative buyers do not use
Workflow change	The reader invents an available capability or treats a planned integration as working
Fit and non-fit	The reader cannot identify a suitable and an unsuitable situation
Implementation	Required access, people or ongoing work disappears from the retelling
Evidence and next decision	An untested benefit becomes a fact, or the reader cannot say what to verify next

Publish the core pack when readers can explain these boundaries without a founder rescue. Expand with the questions that remain during evaluation. A glossary or manifesto cannot substitute for that understanding.

Measure comprehension, useful questions, appropriate evaluations and later realization of value. Treat page views as reach. There is no verified rule here that one content format produces buying consensus fastest.

Use the resulting learning to support traction becoming a repeatable GTM motion. The next buyer should understand the value more readily because the explanation improved, rather than because the founder repeated a longer pitch.

Build the explanation and its supporting workflow

Piet Baudoin works through Poldermarketing, remotely in Dutch and English, on positioning, visibility in Google and AI answers, and building and running AI automations. Those include lead follow-up, enrichment, qualification, CRM, reporting, content distribution and integrations. He can set up a CRM and read Search Console queries.

For post-seed startups, the aim is a first customer, a second and a repeatable process bringing the product to buyers who are happy with it. Start with positioning and messaging or the free growth scan to inspect how the public explanation currently reads.