Name an Unfamiliar Product Without Sending the Reader to the Wrong Category
Name an Unfamiliar Product Without Sending the Reader to the Wrong Category
The slide says “business management system.” The founder meant it loosely: the tool organizes the notes that pass between repair jobs, and a conventional category name seemed like a handrail for a new reader. But every handrail points somewhere. A reader who takes “business management system” seriously has already begun furnishing the product with customer records, invoices, inventory, and reports before the second slide tells them none of that exists. By then the correction isn’t a detail. It’s a reversal.
The problem isn’t that familiar categories lie. It’s that they promise on your behalf. The question isn’t which label sounds most impressive or most modest. It’s which label creates expectations that are mostly true of the thing on screen.
April Dunford’s practitioner framing treats category context as a source of expectations about capabilities, customers, and alternatives. It is not evidence of how a real audience would read Handoff Notes.
List the expectations your opening label creates
Write down what a competent stranger would expect to see next after reading your current introduction. Not what you hope they associate with you, and not what a hostile reader would assume, but the ordinary working assumptions a person in this field would bring along.
A category label tends to trigger expectations along three axes:
- Who it’s for. Is this for the shop owner, the technician, the back office, or an enterprise operations team?
- What work it performs. Does it replace a system of record, a workflow, a communication channel, or a reporting layer?
- Which neighboring capabilities belong to the category. What does a buyer reasonably assume is included because it almost always is?
That last axis is where most introductions quietly overpromise. A category is not just a word; it is a bundle of expected features, integrations, and conventions. When a tool is narrower than its label, the reader has to discover the boundary by subtraction.
Treat these expectations as hypotheses, not facts about your audience. You can’t know from the deck alone that a whole market reads “platform” the same way. But you can list the assumptions the label invites, and you can check those assumptions against what the product actually does. A category name that orients quickly is worth keeping only while the expectations it creates remain mostly accurate.
Compare those expectations with the product that exists
Here is a fictional case, written for this comparison and not based on a real vendor. It is not an audience test, a naming recommendation, or a claim about anyone’s product.
Imagine a small tool called Handoff Notes. It does one job: it captures the repair-job notes that one technician passes to the next, structures them by job, and keeps a readable history of what was tried, what was replaced, and what remains open. It does not handle customer accounts. It does not invoice. It does not track parts inventory. It runs alongside whatever system already holds those records.
Now suppose the introduction currently reads: “Handoff Notes is a business management system for repair teams.”
For this fictional comparison, treat the following as expectations the label may invite, not observed reader response. “Business management system” may suggest a system of record rather than a layer that sits beside one. It may suggest customer data inside it, billing or inventory as part of the suite, and ownership of financial or commercial records at least on the roadmap. It may suggest a manager evaluating a consolidated back office as the primary buyer, rather than a technician trying to leave a clear note at the end of a shift.
Handoff Notes supports almost none of that. The actual task is narrower and more specific: reduce the failure that happens when the note between shifts is thin, verbal, or lost. Its user is the person doing the work, not the person reviewing the business. Its boundary is whatever system already holds accounts, invoices, and stock.
Once the gap is visible, the rule becomes simple. Judge the label by whether the next slide can develop it or must retract it.
| Introduction | Scenario expectations the label may invite | What Handoff Notes can actually show | What the next page must do |
|---|---|---|---|
| “A business management system for repair teams” | Accounts, invoicing, inventory, reporting; a consolidated back office; data of record | Job-based notes, handover history, open items; sits beside existing systems | Retract the implied scope. Clarify that it manages handover notes, not the business. |
| “A handover tool for repair teams” | A way to pass work between people; structured notes; some continuity across shifts | Exactly that, plus a readable history | Develop the detail: what a handover looks like, what stays out, how it fits the shift. |
| “Handoff Notes records what one technician needs to tell the next, so no job goes cold between shifts” | Notes attached to a job; continuity; the technician as user | The specific task, the user, and the boundary in one sentence | Show the note, the history, and where customer records remain. |
The first column creates a presentation problem disguised as a presentation solution. The word “system” makes the product sound substantial, but the rest of the hundred slides have to unmake that substance before they can explain what the tool does. The qualification and task statements keep their later slides additive. They let the product grow in the reader’s mind instead of shrinking.
Test whether a short qualification repairs the introduction
Not every familiar label should be discarded. A category can orient a reader quickly, and a qualification can preserve that speed while narrowing the picture. The test is whether the addition repairs the expectations the label creates, or merely restates them in softer terms.
Take the same fictional tool. Compare:
- “Handoff Notes is a business management system for repair teams, but focused on communication.”
- “Handoff Notes is a business management system for repair teams that records the job notes passed between technicians.”
- “Handoff Notes lets one technician leave the next a job note that survives the shift, without moving customer records or invoices into a new system.”
The first version cuts the category down with the word “focused.” That sounds modest, but it doesn’t change what the reader pictures. In this fictional comparison, it may still invite an accounts screen next. The qualification names no boundary, so the reader still meets the correction later.
The second version is better. It keeps the familiar label but adds the actual task. The phrase “job notes passed between technicians” begins to specify the user and the work. What it doesn’t do is remove the invoice and inventory expectations that “business management system” already raised. A reader may now expect a business management system whose communication module is stronger than most, which is a larger claim than the tool makes.
The third version drops the category and states the task. It is less conventional, and it asks the first sentence to carry more weight. In return, it tells the reader who works in the product, what they accomplish, and where the boundary sits. The next page can show the note, the history, and the fact that customer records stay where they are.
A useful qualification should pass one check: after reading it, can the reader describe the product’s job and its edge without further correction? If most of the following page is spent explaining what the product isn’t, the label never fit. Familiarity is useful when it saves the reader a step. It is a cost when the reader spends the next three slides undoing the picture it created.
Choose a reliable starting description, then refine its wording
A task-based description works because it names the work, the user, and the boundary in the reader’s own vocabulary. It doesn’t need to be a new category. It doesn’t need to claim a market. It needs to produce a starting picture that the rest of the material can deepen.
For the fictional tool, a usable opening might read:
Handoff Notes is for the repair teams whose work moves between people. A technician leaves the next one a structured note on a job: what was tried, what was replaced, what’s still open. The record stays with the job, so the next shift starts current. Customer accounts, invoices, and parts inventory stay in whatever system already holds them.
That paragraph does several things at once. It sets the user, the task, the boundary, and the integration posture. It gives the reader a concrete thing to picture. It also states the exclusion early, which is usually better than letting the reader discover it by looking for a billing screen that isn’t there.
Notice what it doesn’t do. It doesn’t borrow authority from a bigger category. It doesn’t say “next-generation platform” or “operating system for repair.” It doesn’t imply a roadmap by using the present tense for future features. It doesn’t claim leadership of a category it hasn’t named. Those choices keep the claim proportionate to the product.
Refine the wording against a page that can develop it. If the next section shows the note structure, the shift handoff, and the way records stay external, the opening has done its job. If the next section has to explain that the product is not actually a business management system, the opening sent the reader somewhere the material can’t follow.
The plain description is not a lesser form of confidence. It is what confidence looks like when it doesn’t need borrowed weight. A category can still be the right call when its expectations are mostly true. When they are mostly not, the task description is the more accurate handrail, and accuracy is what lets the reader arrive at the second slide already facing the right direction.
An introduction has done enough when the page after it can develop rather than retract its meaning. Keep the task description available for that reason. It is not the safe fallback; it is often the version that lets the product exist at its real size.
Frequently asked questions
What is the main risk of using a familiar category label for an unfamiliar product?
Familiar categories do not necessarily lie, but they promise on your behalf. A reader who takes 'business management system' seriously may already expect customer records, invoices, inventory, reports, and a consolidated back office. If the product does not do those things, the next slides must retract the picture rather than develop it.
What expectations does a category label typically create?
The body groups them along three axes: who the product is for, what work it performs, and which neighboring capabilities belong to the category. The last axis is where introductions often overpromise, because a category is a bundle of expected features, integrations, and conventions.
How can you test whether a short qualification repairs the introduction?
Ask whether, after reading it, the reader can describe the product's job and its edge without further correction. If most of the following page explains what the product is not, the label never fit. A qualification like 'focused on communication' may sound modest without changing the picture, while naming the actual task begins to specify the user and work.
What should a reliable task-based opening description include?
It should name the work, the user, and the boundary in the reader's own vocabulary. In the fictional Handoff Notes example, that means saying a technician leaves the next a structured job note, the record stays with the job, and customer accounts, invoices, and parts inventory stay in whatever system already holds them.
Should every familiar category label be discarded?
No. A category can orient a reader quickly, and a qualification can preserve that speed while narrowing the picture. Keep a category name only while the expectations it creates remain mostly accurate; when they are mostly not true, a task description is the more accurate handrail.