Naming the Work

A project name is a communication tool. Name the work clearly enough that people can refer to the same initiative in meetings, documents, and decisions. Use a descriptive name when clarity matters. Use a codename when confidentiality requires it. Before debating names, write a short brief covering the work, audience, outcome, scope, and where the name will appear. Test the name in a roadmap, task, status update, and spoken sentence. If people need an explanation every time, the name is not doing enough work. GitLab documents a similar practice: its naming process begins with a brief that establishes context and stakeholder input, while its confidentiality guidance reserves codenames for sensitive work. Sources: https://handbook.gitlab.com/handbook/marketing/brand-experience/naming/ and https://gitlab.com/gitlab-com/content-sites/handbook/-/blob/364d18aeca81b2ee581f82e506f4ea1edae1d665/content/handbook/communication/confidentiality-levels.md

Related reading: \2 · \2

The existing naming guidance focuses on practical naming constraints. A second evidence layer matters because the name eventually sits beside public claims about the company or product. FTC guidance emphasizes that express and implied marketing claims need a reasonable basis and that what a name or message conveys can matter in context.

That does not mean a company name must explain the entire product. It means founders should test the associations a name creates and avoid building the brand around claims they cannot substantiate.

Sources: \2 and \2.

Use this on one live decision rather than as a general checklist.

1. Current state: What is happening now, using a small set of observable facts?

2. Decision: What exactly must be decided, and by when?

3. Evidence: Which customer, financial, operational or team evidence would change the decision? Separate evidence from interpretation.

4. Smallest action: What is the smallest reversible step that can produce useful evidence?

5. Owner: Who can make the decision without waiting for the founder?

6. Measure: What will you watch: conversion, contribution, cycle time, quality, cash timing, retention, response or another directly relevant measure?

7. Review point: Put a date on the decision. Do not let an experiment continue simply because nobody defined when it ends.

8. Stop condition: What evidence would make you pause, change or abandon the approach?

• Activity replaces evidence: the team completes tasks but does not learn anything that changes a decision.
• A proxy becomes the goal: a visible number improves while the underlying business problem remains.
• The rule becomes rigid: a useful framework is applied after the context has changed.
• The founder remains the hidden bottleneck: ownership is named but approval still routes back to one person.
• The source is broader than the claim: evidence from one context is presented as if it proves a universal rule.

A strong output from this guide is not a completed checklist. It is a documented decision with an owner, evidence, trade-off, next action and review date. If those five elements are missing, the work is not finished.