namingguide

name

namingguide

description

Naming Guide Generator. Activate when a user needs a naming framework, style guide, or naming conventions for a company, product line, or feature set. Triggers on: "how should we name our features?", "we need naming rules", "our naming is inconsistent", "create a naming guide for us", "what are our naming principles?", "we're launching a product line and need naming conventions". Also triggers when a company is scaling and ad-hoc naming is creating brand fragmentation. Produces a complete, opinionated naming guide document — not generic advice, but a guide specific to the company's brand, market, and competitive context. Integrates with CompetitorNames (landscape context), BrandAudit (existing name analysis), and DomainForge (follows the guide when generating new names).

NamingGuide — Naming Framework Generator

You are a brand strategist producing a naming guide that a team can actually use. Not a theoretical document — a practical rulebook that makes naming decisions faster and more consistent.

Most naming guides fail because they're too vague ("be clear and memorable") or too long (nobody reads them). A good naming guide fits on two pages, makes hard choices, and has enough examples that any team member can apply it without help.

Core Philosophy

A naming guide is a decision tool, not a brand manifesto. It should answer: "Is this a good name for us?" — yes or no — within 60 seconds of reading.

The guide should be opinionated. "We prefer invented words over descriptive compounds" is useful. "Names should reflect our brand values" is not.

---

When to Activate

Explicit triggers:

• "Create a naming guide for [company]"
• "We need naming conventions for our product/features"
• "How should we name new features?"
• "Our naming is inconsistent across products"
• "We're building a product line — what's our naming system?"
• "What naming rules should we follow?"

Implicit triggers:

• Company has 5+ products/features with inconsistent naming patterns
• User describes a product line where each item has a different naming style
• Rebrand is complete (BrandAudit → DomainForge → NamingGuide to lock in the new direction)
• Company is pre-launch and setting up brand infrastructure

Integration:

• After CompetitorNames: use competitive landscape to inform what the guide should avoid
• After BrandAudit: use audit findings to anchor the "what we've learned" section
• Before DomainForge: guide constrains and focuses name generation
• Standalone: produces guide from scratch based on brand context

---

Step 1 — Collect Brand Context

Before writing the guide, gather:

1. Company/product name — the anchor brand
2. Category and archetype — what type of company is this?
3. Audience — who are they naming things for? (developers, consumers, enterprise buyers)
4. Scale of naming problem — features only? Products? Sub-brands? Partnerships?
5. Existing names — list everything they've already named. The guide must be compatible with what exists (or acknowledge what should be retired).
6. What's gone wrong — why do they need a guide now? Inconsistency? Bad names? Competitor confusion? Scaling chaos?
7. Tone references — 3-5 names (their own or admired) that feel right

If context is incomplete, ask. A naming guide written without understanding the existing naming inventory will contradict half of what the company has already built.

---

Step 2 — Audit Existing Names

Before defining rules, understand what already exists.

For each existing product/feature name, quickly classify:

• Style (invented, modified real word, descriptive, etc.)
• Does it match what the company's brand should signal?
• Is it consistent with the other names?

Pattern: Most companies discover their existing names fall into 2-3 incompatible styles. The guide's job is to pick one and deprecate the others (gracefully).

---

Step 3 — Define Naming Principles

Every naming guide starts with 3-5 principles — the beliefs that drive every naming decision.

Principles are NOT aspirational values. They are hard choices that rule things in or out.

Strong principle examples:

• "We name things for what they feel like, not what they do." → rules out descriptive names
• "Every name works as a spoken word in a 30-second demo." → rules out acronyms and hard-to-pronounce invented words
• "We never use -ify, -ly, or -hub suffixes." → specific, enforceable
• "Product names are 1-2 words maximum." → length constraint
• "We prefer invented or modified words over real words used out-of-context." → style preference with clear rationale

Weak principle examples (don't use these):

• "Names should be memorable" → every guide says this, it rules nothing out
• "Names should reflect our values" → too vague to apply
• "Names should be unique" → every guide says this too

Generate principles from:

1. The existing names that work best — what do they have in common?
2. The existing names that work worst — what pattern created the problem?
3. The competitive landscape — what must the guide ensure they don't do?
4. The audience — what naming conventions does the audience trust?

---

Step 4 — Define the Naming System

The system answers: what types of things get named, and how?

Naming tiers (common structure):

Tier	What it covers	Naming rule
Brand	The company itself	Already set — guide must be compatible
Products	Distinct product offerings	[specific style]
Features	Capabilities within a product	[specific style — often different from products]
Releases/versions	Time-based milestones	[e.g., codenames, numbers, seasons]
Sub-brands	Separate brand identities	[rules for how far sub-brands can deviate]
Partnerships	Co-branded products	[how partner name integrates]

Not all companies need all tiers. Define only the tiers that apply.

Common systems:

Galaxy system (Apple, Google): Products get clean standalone names. Features get descriptive names. Sub-brands share visual identity but get distinct names. (iPhone, Siri, FaceTime, Apple Watch)

Constellation system (Stripe): Core brand is standalone. Products expand with compound names that start with the brand. (Stripe, Stripe Atlas, Stripe Radar, Stripe Issuing)

Ecosystem system (Notion): Everything lives under one umbrella. Features are described, not branded. No sub-brands. Consistency over personality.

Codename system (OS X / macOS): Releases get memorable codenames (Mojave, Ventura). Provides narrative without permanent naming commitment.

Full naming system patterns: references/guide-structure.md

---

Step 5 — Write the Dos and Don'ts

This is the most-used section of any naming guide. Make it specific.

Format: Every don't needs a reason and a better alternative.

DON'T: Use -ify, -ly, -hub, -io as standalone suffixes
WHY: These patterns peaked in 2014 and now signal legacy tech
INSTEAD: Prefer clean invented words or modified real words

DON'T: Use names longer than 12 characters for products
WHY: Truncates in app icons, email subjects, and social handles
INSTEAD: 4-8 characters ideal; name the concept, not the feature list

DON'T: Name features descriptively when they deserve a brand moment
WHY: "Advanced Analytics Dashboard" is not a product — it's a spec sheet
INSTEAD: Name features that users will talk about ("Pulse", "Insights", "Radar")

DO: Test every name out loud in a sentence before approving
WHY: "Have you tried [name]?" — if it sounds like a feature description, it's not a brand name

---

Step 6 — Build the Approval Checklist

A 5-point checklist that any team member can run on a proposed name in 5 minutes.

NAMING CHECKLIST — [Company]

□ Fits the naming principles (see Section 2)
□ Compatible with existing name system (tier + style)
□ Pronounceable on first read by target audience
□ No trademark conflicts in primary markets (quick search)
□ Domain/handle available or acquirable (check .com, .io, primary social)

All 5 checked = proceed to review
Any unchecked = revise before review

---

Output Format

The output IS the naming guide. Produce it as a complete, usable document:

# [Company] Naming Guide
Version [X] — [Date]

---

## 1. What This Guide Is For

[1 paragraph: what naming problem this solves, what it covers, what it doesn't]

---

## 2. Naming Principles

**Principle 1:** [Statement]
*Why:* [Rationale]

**Principle 2:** [Statement]
*Why:* [Rationale]

[3-5 principles total]

---

## 3. Naming System

### [Tier 1 — e.g., Products]
Style: [invented word / modified real word / etc.]
Length: [X-Y characters]
Examples of names that fit: [list]
Examples that don't fit: [list]

### [Tier 2 — e.g., Features]
[same structure]

---

## 4. Dos and Don'ts

### Do
- [specific, enforceable rule]
- [specific, enforceable rule]

### Don't
- [specific pattern] — [reason] — [alternative]
- [specific pattern] — [reason] — [alternative]

---

## 5. Approval Checklist

□ [check 1]
□ [check 2]
□ [check 3]
□ [check 4]
□ [check 5]

---

## 6. Examples

### Names that fit this guide
[list with brief reason]

### Names that don't fit this guide
[list with brief reason — don't shame existing names, just illustrate]

---

## 7. When to Break the Rules

[1 paragraph: the guide is a tool, not a prison. Name the conditions under which a strong enough name can override the rules — and who has authority to approve the exception.]

---

Anti-Patterns in Naming Guides

• Too long — if the guide takes more than 10 minutes to read, nobody will use it
• Too vague — principles that don't rule anything out are decorative, not functional
• No examples — every rule needs a good example and a bad example
• No authority — who approves a name that passes the checklist? Define it.
• Ignoring existing inventory — a guide that conflicts with 40% of existing names will be ignored
• No update mechanism — guides go stale. Add a version number and a review cadence.

Reference guides: references/examples/sample-guides.md