Users want to name a product, project or module but haven't decided on a name yet. Through a structured collaborative process, derive the name from the essence of the product, instead of directly listing a bunch of candidates for users to choose from.
Core Principles
- Figure it out before naming — Never list candidate names without understanding the soul of the product
- Names are derived, not pieced together — Naturally derive from product positioning, user portraits, and brand temperament
- Provide routes, not lists — Let users choose the naming direction first, then brainstorm specific names within the direction
- Validate intuition with data — Research naming patterns of products in the same track to avoid working behind closed doors
- No rushing — Names are the foundation of a brand, and it's worth taking time to get them right
Workflow
Step 1: Product Soul Mining (No Naming Involved)
The goal of this step is to understand the essence of the product, not to collect feature lists.
Proactively learn about the project background (read code, read documents), then ask users the following questions:
- Who are the users? — Who is using it? In what scenarios? How often?
- Product essence — Describe what this product is in one sentence? (Not a feature list, but a role/positioning/metaphor)
- Product boundaries — What does it do, what doesn't it do, and which direction will it develop in the future?
- Brand temperament — What first impression should users get when they see this name? (Professional/approachable/geeky/lighthearted/...)
- Hard constraints — Language preferences? Length limits? Words to avoid?
Key: If the user gives a metaphor (such as "like Jarvis"), be sure to dig deep into the meaning behind this metaphor — it reveals the user's imagination of the product's role.
Forbidden:
- Start listing names right after reading the project documents
- Think one question is enough; all the above questions must be covered
- Throw these questions at the user as a form all at once; it should be a natural conversation
Step 2: Naming Constraint Extraction
Extract the following from the answers in Step 1:
- Keywords — Refine core morphemes from the user's description (e.g., programming, assistant, partner, tool, management)
- Identify tensions — Are there contradictions between the user's multiple demands? (e.g., "needs to be warm like a person's name" vs "needs to be immediately recognizable as related to programming")
- Clarify priorities — If there are tensions, which demand takes priority?
Show your analysis to the user and confirm that your understanding is correct.
Example:
Your core demands:
- ✅ Let people know it's related to team collaboration
- ✅ Lighthearted and not serious, unlike enterprise software
- ⚡ These two are in tension: Collaboration-related names tend to feel "corporate", while lighthearted names often fail to indicate usage
My judgment is that "lightheartedness" takes priority, because you are competing with Slack/DingTalk on experience rather than features. Is that correct?
Forbidden: Skip analysis and directly propose names. This step is the key bridge from "feeling" to "logic".
Step 3: Route Diversification
Based on constraint analysis, derive 2-4 naming routes, each representing a different naming strategy.
Each route includes:
- Route Name — A one-sentence summary of the idea behind this route
- 2-3 illustrative names — Let users feel the vibe of this direction
- Pros and cons — Honestly explain the advantages and disadvantages of each route
Example:
Route A: Onomatopoeia/Action Words
Illustrations: Ping, Holler, Nudge
✅ Light, vivid imagery
❌ Not directly related to the "standup" scenario
Route B: Time/Rhythm Metaphors
Illustrations: DayBeat, MorningSync, Cadence
✅ Implies daily rhythm, fits standup frequency
❌ Relatively long, strong sense of combination
Route C: Abbreviations/Coined Words
Illustrations: Stanly（standup + daily）、Asynco（async + co）
✅ Unique and easy to register
❌ Requires explanation of meaning
Forbidden:
- Only provide one route
- Routes are too similar
- Only mention advantages, not disadvantages
- List more than 5 specific names/routes in this step (let users choose the direction, not the name)
Step 4: User Direction Selection
Users can:
- Directly select one route
- Combine elements from multiple routes ("The directness of C + the warmth of A")
- Reject all and supplement new directions → Return to Step 3
After selecting the direction, dig deep into 3-5 specific candidate names within that direction, each with a one-sentence explanation.
Forbidden: Diversify in other directions after the user has chosen a direction. Stay focused.
Step 5: Competitor Validation + Naming Strategy
After the user leans towards a certain name, do two things:
5a. Competitor Naming Research
Research the naming patterns of products in the same track:
- Are most pure English, dual Chinese-English brands, or pure Chinese?
- Name length? Number of syllables?
- Is there a risk of name collision?
5b. Naming Strategy Confirmation
Based on research results, suggest to the user:
- How many names are needed? (English name + Chinese name? Or just one?)
- Do we need a slogan?
- What's the reason?
Example:
Research found that Geekbot, Range, and Standuply, which are in the same track, all use only one English name.
Suggestion: Use only Ping, no separate Chinese name.
Reason: Users are development teams who already use English tools in daily communication; one syllable is easiest to remember.
If a Chinese scenario is needed, add a slogan: "Ping — Tap once, standup done"
Forbidden: Suggest a naming strategy without doing research; all suggestions must be supported by data.
Step 6: Final Confirmation
Summarize the decision-making chain of the entire process and output the final conclusion:
📌 Product Name: Ping
📌 Slogan: Tap once, standup done
📌 Naming Strategy: Single pure English brand
📌 Decision Basis:
- User Portrait: Remote development team
- Product Positioning: Asynchronous synchronization tool replacing daily standups
- Core Constraint: Lighthearted and not serious, looks inviting to use
- Competitor Practice: Mainstream in the same track is short pure English names
Communication Specifications
Must ask users
| Timing | What to ask |
|---|
| Step 1 | User portrait, product essence, product boundaries, brand temperament, hard constraints |
| Step 3 | Which route to choose |
| Step 4 | Which specific name to lean towards |
| Step 5 | Whether to agree with the naming strategy (number of names, need for slogan) |
| Step 6 | Final confirmation |
No need to ask users
| Item | Do directly |
|---|
| Read project documents to understand background | Read directly, then ask users with understanding |
| Competitor research | Search directly, then provide suggestions with data |
| Analyze tensions between demands | Analyze directly, then confirm judgments with users |
What AI should never do
- Throw a list of names right after reading the project documents
- Start naming without understanding the product essence
- Evaluate names only from the perspective of "sound good" instead of brand strategy
- Replace with a new batch of names when the user says "no" instead of reflecting on where the process went wrong
- List too many options to appear professional, causing decision paralysis
- Rush the user to make a decision