If people do not understand your offer, a catchier tagline may not solve the problem. First check whether you are unclear about the customer and alternatives, the value of the offer, or simply how the idea is expressed. Those are related decisions, but they are not interchangeable.

Here is a practical distinction. Positioning establishes the context in which suitable customers compare the offer. A value proposition explains why the offer matters to those customers. A tagline is a short expression that may make the brand easier to remember. Terminology varies between practitioners; the useful test is what each document helps you decide.

This guide works through one original example across all three jobs. For the sentence-writing task itself, use our business-description guide. Here, the goal is to identify which underlying decision deserves work before producing another headline.

Compare the questions, not just the definitions

PartMain questionUseful working output
PositioningCompared with what, and for which suitable customers?A context and alternatives brief
Value propositionWhy is this offer useful for that customer task?A supported explanation of relevant value
TaglineWhat short expression should be memorable?A phrase with a clear role in the wider message

A single line on a website can perform more than one job. The distinction is not a rigid rule that each business must publish three separate sentences. It is a way to prevent the team from solving a strategic uncertainty with wordplay.

For example, a tagline can mention a product category and benefit. That does not mean the team has investigated customers' alternatives. A complete positioning document can also remain unreadable to a visitor until its decisions are translated into ordinary public copy.

Keep the intended output visible during a meeting. If the task is deciding who the product serves, do not declare it complete because everyone likes a phrase. If the task is editing a button, do not reopen the entire company strategy without a reason.

Positioning begins with a relevant comparison

April Dunford's positioning primer distinguishes positioning from messaging and describes the relationships between alternatives, capabilities, customer value and market context. Its focus is especially relevant to products whose category is not obvious.

Use that idea as a practical question: what would the intended customer do without this offer? The answer may be another specialist product, an existing platform, a spreadsheet, a manual process or continuing as before. A search list of similar-looking companies is not necessarily the customer's actual comparison set.

Do not claim that an alternative is worse in every respect. A spreadsheet may be familiar, inexpensive and adequate. A specialist product needs to explain the relevant difference for a particular use, not pretend the existing approach has no value.

Evidence about real choices is more useful than the founder's preferred competitor list. Keep actual reported alternatives separate from possibilities the team wants to investigate. The first can inform the brief; the second remains a research question.

A value proposition connects the offer to a task

Strategyzer's official Value Proposition Canvas description links what customers are trying to achieve with the offer's proposed help. It also distinguishes a proposed fit from one supported by customer evidence.

You do not need to reproduce a proprietary canvas to ask the underlying questions. What is the customer trying to do? Which obstacle matters? What does the offer supply? Which result can reasonably follow, and what depends on the customer's own actions or other conditions?

A value proposition is not a list of every feature. It selects the capabilities that matter for the task. “Exports a CSV” is a capability. “Take the records into the spreadsheet your team already uses” describes a possible use, provided the export is actually compatible.

Keep the scope honest. Helping someone compare costs is different from guaranteeing savings. Making outstanding approvals visible is different from guaranteeing that clients reply. A relevant explanation can be attractive without claiming control over every eventual outcome.

Three different writing jobs: Relevant comparison; Useful offer; Memorable signal.
Three different writing jobs. Relevant comparison → Useful offer → Memorable signal.

A tagline has a smaller job

A tagline can supply personality, continuity or a memorable phrase. It may be abstract when the surrounding message supplies the missing context. The risk is asking that phrase to carry the entire explanation of an unfamiliar offer.

Consider an original phrase, “Room for the next idea.” It could describe furniture, software, storage or a creative service. It might work in a suitable visual and verbal context, but on its own it does not identify what is sold.

Do not judge a tagline only by whether the team finds it clever. Ask where it appears and what information surrounds it. A packaging line, a homepage heading and a search title encounter different contexts. The same phrase need not serve them all.

If customers cannot identify the category, add a clear explanation rather than making the slogan longer and longer. Memorable language can coexist with direct information. It should not require the reader to solve a puzzle before assessing suitability.

One original business across all three parts

Imagine an illustrative software offer for small design studios that need to track client approvals. This is a worked example, not a real observed business or a reported client result.

The initial positioning question is whether studios compare it with general project boards, email threads or another approval tool. That answer should come from real investigation. The draft cannot assume that every studio sees the same alternatives.

A provisional value proposition could be: “Keep each client approval, owner and due date in one shared list so the studio can see what is outstanding.” That statement is appropriate only if the product supplies those capabilities. It does not promise quicker client responses or a fixed revenue benefit.

A possible tagline is “Know what is waiting.” It provides a shorter expression, but it needs context. The page should still identify the approval-tracking product and the audience. The tagline is not evidence that the positioning is correct or the product is wanted.

Write a context brief before public copy

For the example, a useful internal brief records the intended studio type, the approval task, the actual alternatives reported by suitable customers and the capabilities that differ meaningfully. Add sources and dates for observations rather than merging them with assumptions.

Then record the conditions. Does the product require clients to log in? Can people approve without joining a team? Does the shared list actually synchronize between users? Those facts affect both the value explanation and which comparisons are fair.

Do not fill missing fields with confident guesses. If no customer has been asked about alternatives, label the list provisional. A brief can be useful while incomplete, provided it helps the team decide which question to investigate next.

The brief is not necessarily homepage text. Its job is to align decisions. Translating it into a short public explanation comes afterward, with enough context for a new visitor and without internal planning jargon.

Diagnose the problem behind a weak headline

If visitors think the approval tool is an agency service, the category may be unclear. If they understand the software but cannot see why it differs from an existing board, the comparison and relevant value may need work. If they understand both but cannot remember the brand phrase, that is a different question.

If the product is unsuitable for their workflow, a copy edit cannot manufacture compatibility. If pricing is outside their budget, clearer wording may help them discover that sooner. A lower enquiry count is not always evidence that the message became worse.

Write the observed mismatch rather than a broad diagnosis such as weak branding. Include the draft and what the reader actually said. Specific evidence makes it easier to choose a bounded revision and check it afterward.

Avoid replacing every artifact at once. Changing the category, audience, offer and slogan simultaneously can be a product decision, but it makes learning about the effect of one wording change harder.

Separate difference from superiority

A feature can be different without being valuable to the intended user. A product can be better for one task and worse for another. Your explanation should identify the relevant tradeoff rather than declare universal superiority.

For the approval example, a focused list might be easier to inspect than a broad project board. It might also lack the board's planning functions. Present those limits honestly. The right customer can then decide whether a specialized workflow is worth using alongside existing tools.

An original service example shows the same issue. A mobile bike repair service differs from a workshop because it travels to a location. That may help some customers while limiting the work it can perform on-site. Convenience is not proof of superior quality for every repair.

Do not add best, only or first merely to make a proposition sound distinctive. Such claims need appropriate evidence and a clearly defined scope. A useful specific difference often communicates more than an unsupported superlative.

Use research questions that match the uncertainty

If alternatives are uncertain, ask people about a recent relevant decision and what they actually considered. If the offer's value is uncertain, investigate the task and what mattered in choosing help. If wording is uncertain, test how people interpret the draft.

The GOV.UK in-depth interview guidance emphasizes actual stories and neutral follow-up questions. Use that practice to avoid feeding the desired answer to participants. Asking whether someone loves an efficient approval solution largely announces the answer the team hopes to hear.

Keep discovery and draft comprehension distinct. Someone can describe a real problem without understanding your page. Someone can understand a page perfectly while having no need for the offer. The evidence types support different decisions.

Our customer-interview question guide covers the pre-draft investigation. The reader-feedback guide covers what people understood after seeing a particular draft.

Test each artifact fairly: State the audience; Write the claim; Check real understanding.
Test each artifact fairly. State the audience → Write the claim → Check real understanding.

Keep a short claim-and-evidence table

For each important statement, record the claim, its basis, its scope and the next check. “Customers use email” might be supported by several interviews, but those interviews may concern one recruitment source. “The product keeps one shared approval record” should be checked against the actual implementation.

A demonstration is not a customer outcome. A proposed tagline is not an observed recall result. An interview quotation does not establish how common a view is across the whole market. Preserve these distinctions in both internal documents and public copy.

If evidence is absent, revise the claim or mark it as a hypothesis for testing. Do not make the website sound authoritative by quietly removing the uncertainty from the brief. The public message and the supported offer need to remain aligned.

This table can also reveal operational gaps. A headline may promise an output the team has not defined or a turnaround it cannot reliably meet. Fixing the actual delivery may be more important than finding a stronger adjective.

Turn the brief into a coherent page

Use the Offer Builder for an editable explanation and the Homepage Planner to organize context, proof and next action. These tools help with the writing workflow; they do not automatically establish market positioning or discover competitors' private data.

A useful first screen identifies the offer and audience. Supporting sections can explain the relevant difference and show genuine evidence. A tagline may add personality, but it should not obscure the product or the commitment behind the action.

Check the destination too. If the message promises a sample, provide a sample. If it asks for contact, explain what is returned. A coherent value explanation can be undermined by a mismatched next step.

Keep terminology consistent across the page, service description and follow-up. Consistency means the same offer and conditions, not necessarily repeating the exact slogan everywhere. Different contexts can need different levels of explanation.

Review the result against the right outcome

Ask what decision the revision was meant to improve. A category change may aim to reduce misunderstanding. A value explanation may help suitable readers assess fit. A tagline test may investigate recall. Do not combine them into one unexplained success score.

Use the Reader Check for actual responses and the Test Planner to define the next investigation. Keep recruitment, draft version and conditions visible. A small convenience sample can reveal a concrete issue without proving a population-wide rate.

Business outcomes require additional evidence. Better comprehension does not guarantee enquiries, purchases or profit. A before-and-after sales change can also reflect audience, price, seasonality or delivery changes. State what was observed without choosing a causal story beyond the design.

The practical result is a clearer division of work: investigate the competitive context, explain supported value, then choose a memorable expression that fits. When those jobs are separated, the next edit becomes a decision with a purpose rather than another attempt to make a slogan carry the whole business.

Before approving a new version, ask a delivery colleague to review it alongside the internal brief. Can the business supply the described capability under the stated conditions? Does the comparison omit a limitation that matters? Does the action create the commitment the reader expects? This check prevents a clear public sentence from drifting away from the actual service. Save the reviewed version and the reason for the change so later edits do not reintroduce a promise the team had already found unsupported.

Repeat that operational review when the offer itself changes.