product-naming
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese用户想给产品、项目或模块起一个名字，但还没想好叫什么。通过结构化的协作流程，从产品本质出发推导名字，而不是直接列一堆候选词让用户挑。
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
第 1 步：产品灵魂挖掘（不碰名字）
Step 1: Product Soul Mining (No Naming Involved)
这一步的目标是理解产品的本质，而不是收集功能列表。
主动了解项目背景（读代码、读文档），然后向用户追问以下问题：
- 用户是谁？ — 什么人在用？什么场景下用？使用频率？
- 产品本质 — 用一句话介绍这个产品是什么？（不是功能列表，是角色/定位/比喻）
- 产品边界 — 做什么、不做什么、未来往哪个方向长？
- 品牌气质 — 用户看到这个名字时，应该有什么第一反应？（专业/亲切/极客/轻松/...）
- 硬性约束 — 语言偏好？长度限制？需要避开的词？
关键：如果用户给出一个比喻（比如"像 Jarvis"），一定要深挖这个比喻背后的含义——它揭示的是用户对产品角色的想象。
禁止：
- 读完项目文档就开始列名字
- 问一个问题就觉得够了，必须把以上问题都覆盖到
- 把这些问题当表单一次性丢给用户，应该是自然对话
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
第 2 步：命名约束提取
Step 2: Naming Constraint Extraction
从第 1 步的回答中提取：
- 关键词 — 从用户的描述中提炼核心语素（如：编程、助手、伙伴、工具、管理）
- 识别张力 — 用户的多个诉求之间是否存在矛盾？（如"要像人名一样有温度" vs "一眼看出跟编程有关"）
- 明确优先级 — 如果有张力，哪个诉求优先？
向用户展示你的分析，确认理解无误。
示例：
你的核心诉求：
- ✅ 让人知道跟团队协作有关
- ✅ 轻松不严肃，不像企业软件
- ⚡ 这两个有张力：协作类名字容易显得"企业味重"，轻松的名字又容易看不出用途
我的判断是"轻松感"优先，因为你要跟 Slack/钉钉竞争的是体验而非功能。对吗？禁止：跳过分析直接出名字。这一步是从"感觉"到"逻辑"的关键桥梁。
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".
第 3 步：路线发散
Step 3: Route Diversification
基于约束分析，推导出 2-4 条命名路线，每条路线代表一种不同的命名策略。
每条路线包含：
- 路线名称 — 一句话概括这条路的思路
- 2-3 个示意名字 — 让用户感受这个方向的味道
- 优缺点 — 诚实说明每条路的利弊
示例：
路线 A：拟声/动作词
示意：Ping、Holler、Nudge
✅ 轻快、有画面感
❌ 不直接关联"站会"场景
路线 B：时间/节奏隐喻
示意：DayBeat、MorningSync、Cadence
✅ 暗示每日节奏，贴合站会频率
❌ 偏长，组合感强
路线 C：缩写/造词
示意：Stanly（standup + daily）、Asynco（async + co）
✅ 独特好注册
❌ 需要解释含义禁止：
- 只给一条路线
- 路线之间差异太小
- 不说缺点，只说好话
- 在这一步列超过 5 个具体名字/路线（让用户选方向，不是选名字）
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 meaningForbidden:
- 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)
第 4 步：用户选择方向
Step 4: User Direction Selection
用户可以：
- 直接选一条路线
- 组合多条路线的元素（"C 的直接 + A 的温度"）
- 全部否掉，补充新方向 → 回到第 3 步
选定方向后，在该方向内深挖 3-5 个具体候选名字，每个附带一句话解释。
禁止：用户选了方向之后还在其他方向上发散。聚焦。
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.
第 5 步：竞品验证 + 命名策略
Step 5: Competitor Validation + Naming Strategy
用户倾向某个名字后，做两件事：
After the user leans towards a certain name, do two things:
5a. 竞品命名调研
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. 命名策略确认
5b. Naming Strategy Confirmation
基于调研结果，向用户建议：
- 需要几个名字？（英文名 + 中文名？还是只要一个？）
- 要不要 slogan？
- 理由是什么？
示例：
调研发现同赛道的 Geekbot、Range、Standuply 都只用一个英文名。
建议：只用 Ping，不另起中文名。
理由：用户是开发团队，日常沟通已经用英文工具；一个音节最好记。
如果需要中文场景，加 slogan："Ping — 轻拍一下，站会搞定"禁止：不做调研就建议命名策略，所有建议必须有数据支撑。
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.
第 6 步：最终确认
Step 6: Final Confirmation
汇总整个过程的决策链路，输出最终结论：
📌 产品名称：Ping
📌 Slogan：轻拍一下，站会搞定
📌 命名策略：纯英文单品牌
📌 决策依据：
- 用户画像：远程开发团队
- 产品定位：替代每日站会的异步同步工具
- 核心约束：轻松不严肃，一看就想用
- 竞品惯例：同赛道主流为纯英文短名称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
| 时机 | 问什么 |
|---|---|
| 第 1 步 | 用户画像、产品本质、产品边界、品牌气质、硬性约束 |
| 第 3 步 | 选哪条路线 |
| 第 4 步 | 倾向哪个具体名字 |
| 第 5 步 | 命名策略是否认同（几个名字、要不要 slogan） |
| 第 6 步 | 最终确认 |
| 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 |
AI 绝不应该做的
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