Lead with a category when buyers recognize it and its expectations fit your product. Use a use case when a specific situation is easier to recognize. Start with an activity when the work itself is the clearest way to explain what you do.
Then check what buyers think you mean. Imagine a prospect reading your homepage and asking whether your product replaces their help desk, when it only organizes feedback from support tickets. The description has created an expectation the product cannot meet.
This exercise helps you choose an introduction and test whether people understand it without your explanation.
Define the product before choosing its introduction
For this exercise, an activity names work someone does, such as organizing customer feedback. A use case adds a person, situation, and purpose: a product manager reviewing support feedback before roadmap planning. A category names a kind of software, such as a feedback management tool.
All three can appear on the same page. You are choosing which one leads and which details follow.
The positioning behind that introduction requires more work. April Dunford’s positioning quickstart starts with what buyers would do without your product, then connects differentiated capabilities, customer value, the customers who care, and market category. She explains that category choice creates expectations about competitors, features, and price.
Before writing alternatives, record the buyer’s current approach and the capability that makes switching worth considering. If those are unclear, resolve them through buyer research before polishing the description.
For an AI product, state what the software produces and what the user must review. A promise to draft a recommendation for approval creates different expectations from a promise to make the decision automatically.
Follow a decision tree based on buyer familiarity
Use this decision tree to choose a starting candidate. It is an editorial heuristic for this exercise, not a validated rule about which description will perform best.
- Do intended buyers already use a category name for this purchase? If its expected capabilities fit your product, lead with that category and add the specific job you support. If the name is unfamiliar, go to step 3.
- Does the category create expectations you cannot meet? Try a narrower, accurate category. If the mismatch persists, go to step 3.
- Do buyers recognize a recurring situation with a clear desired outcome? Lead with that use case. Name who encounters it and when the product becomes useful. Otherwise, go to step 4.
- Can buyers readily describe the activity? Lead with the work, then explain the software’s output and who uses it.
- Is even the activity hard to explain? Show a concrete before-and-after workflow and investigate which part buyers recognize. A new category name would require its own explanation.
Each choice has a tradeoff. A category invites comparison with other products in that market. A use case may make the product seem relevant only in that situation. An activity can sound like a feature or a service unless the supporting copy explains the software.
A small team may reasonably introduce a broad product through one urgent use case. Record what that choice leaves out so you can revisit it when your audience or product changes.
Collect buyer language and check the expectations behind it
Ask intended buyers about a recent instance of the work. What triggered it? How did they handle it? What did they call the task? Did they look for software, ask a colleague, or keep using their existing process?
Keep their wording separate from your interpretation. Someone describing a frustrating spreadsheet has identified a problem; you still need to learn whether they want to change their process.
Joanna Wiebe’s review-mining method starts with the audience, the solutions they want, and what they already use. In her Flow example, review themes lead to questions for the developer about product capabilities before she writes the copy.
Apply that check to each promising phrase: can your product fulfill the expectation it creates? Reviews and public discussions can suggest language, but their authors may differ from your intended buyers. Check the framing with people who face the situation you want to serve.
Worked example: three introductions for the same product
Imagine a fictional SaaS product called SignalSort. It imports support-ticket exports, groups related feature requests, and links each group to the original tickets. A product manager reviews the groups before planning. It cannot respond to tickets, run a public voting portal, or decide the roadmap.
The intended buyer is a product manager at a small SaaS company who currently sorts feedback in a spreadsheet. Keep those facts fixed while changing the introduction.
| Lead | Candidate description | Possible misunderstanding to investigate |
|---|---|---|
| Activity | Organize feature requests from support tickets. | The reader sees a sorting feature but misses when a product manager would use it. |
| Use case | Prepare support feedback for your next roadmap review. | The reader assumes it is useful only immediately before a roadmap review. |
| Category | A customer feedback management tool for small SaaS product teams. | The reader expects a voting portal or other features the product lacks. |
Put the same supporting sentence below every version:
Import a ticket export, review grouped requests, and open the original tickets to check the context.
Suppose buyers readily describe roadmap preparation but disagree about what feedback management software includes. That would give you a reason to test the use-case introduction first. If buyers consistently ask for a feedback management tool and understand this product’s scope, start with the category version.
These are hypothetical decision paths. No interviews or performance results are being reported for SignalSort.
Test what people understand before asking which version they prefer
Create three cards with the candidate introductions. Keep the supporting copy, product facts, visual treatment, and next step identical. Recruit people with the same relevant role and recent experience of the task.
Show each participant one version first, distributing those first exposures across the three versions. Capture their understanding before explaining the product or showing alternatives. If you later show all three, record preferences separately: those answers come from people who now know more than a new visitor would.
Ask the same questions each time:
- What would you use this product to do?
- When would you reach for it?
- What would you use instead?
- What would you expect it to include?
- What would you need to see before trying it?
Define an accurate interpretation before reviewing answers. For SignalSort, a reader should understand that it organizes existing support feedback for a product manager to review. Expecting it to answer tickets or set priorities automatically is a material misunderstanding. A response that mentions sorting but leaves the purpose unclear needs a follow-up question.
Keep one record per participant:
| Field | What to record |
|---|---|
| Relevant experience | Role and recent instance of the task |
| First version seen | Activity, use case, or category |
| Initial interpretation | Their wording, captured before your explanation |
| Assessment | Accurate, incomplete, or materially mistaken, with a reason |
| False expectations | Capabilities they expected that the product lacks |
| Unanswered questions | What they still need to understand |
| Next step | What they actually chose to do; record stated intentions separately |
Preserve verbatim responses when you have permission to record them. Review the pattern of misunderstandings alongside each participant’s context. If every version creates the same false expectation, inspect the shared supporting copy as well as the introductions.
Select a candidate provisionally when relevant participants can explain it accurately and their interest concerns a task the product supports. If responses remain mixed, record the uncertainty and revise the copy or investigate the buyer group. You do not need to declare a winner after every round.
Dunford’s product positioning exercise calls for testing an initial position with customers and distinguishes positioning from the messaging built from it. The card exercise here is a proposed way to examine the opening explanation; it is not a test protocol attributed to Dunford.
A small interview round can reveal misunderstandings. It cannot establish conversion lift or represent the entire market. When you are ready to test behavior on a page, use the FindVex guide to building a SaaS homepage experiment from buyer intent to define the audience, outcome, and evidence needed for a decision.
Copy this positioning worksheet
Complete the worksheet for one buyer group. Use it to organize evidence and open questions; leave unknowns visible.
BUYER AND PRODUCT
Buyer role and recent situation:
Current workaround or alternative:
Product capability that matters in that situation:
Evidence that the capability works:
Category buyers already recognize:
Expectations attached to that category:
Expectations our product cannot meet:
CANDIDATE INTRODUCTIONS
Activity introduction:
Use-case introduction:
Category introduction:
Supporting sentence shared by all versions:
COMPREHENSION CHECK
Relevant experience required of participants:
How first exposures will be distributed:
Accurate interpretation we want to hear:
Material misunderstandings to watch for:
Next step participants can actually take:
DECISION
Candidate selected, or reason the result is inconclusive:
Supporting observations and participant context:
Unresolved questions:
Next revision or research task:
Date and reason to review the decision:Your next task: write three introductions you can defend
Fill in the current workaround and the expectations your product cannot meet. Use those constraints to write an activity, use-case, and category introduction for the same buyer and product.
Before arranging interviews, write down what an accurate explanation would include and what would count as a material misunderstanding. You will then have three candidates and a consistent way to assess what buyers understand.
