Evergreen
Product Nickname vs Model Name: A Decision Guide
Informal product names can improve memory and conversation, but create category, ownership, and version debt. Use this framework to decide what to keep.
Why Informal Product Names Travel Farther Than Model Numbers
An informal product name can travel farther than a model number because it is easier to picture, repeat, and use in conversation. It becomes expensive when the name hides what the product does, who owns it, or which version someone actually used.
Nano Banana shows both sides. "Gemini 2.5 Flash Image" fits a technical release system. "Nano Banana" gives a person a picture, a joke, and a phrase that can move through a conversation. As Google expanded the name across several models, the memorable label also became less precise.
The decision is not whether a serious product can have a playful name. It is whether the public name and the technical identity can support different jobs without confusing the user.
Two names, two systems
A technical model identifier serves an operational system. It can encode a family, generation, performance class, modality, and release position. Engineers can use it in an API, documentation, evaluation record, or migration plan.
A public name serves a social system. It has to survive speech, memory, search, screenshots, recommendations, and the moment when one person tells another what to try.
| Naming job | Technical identifier | Informal public name |
|---|---|---|
| Distinguish versions | Usually strong | Often weak unless the version is attached |
| Fit code and documentation | Strong | Variable |
| Explain ownership | Often strong when the family is visible | Variable |
| Support ordinary conversation | Often weak | Often strong |
| Create an image or association | Usually weak | Often strong |
| Support global pronunciation | Depends on the system | Depends on the word and culture |
| Survive a portfolio expansion | Strong when governed | Can accumulate ambiguity |
The same product can use both. Trouble begins when the organization acts as if one name can satisfy every row.
flowchart LR
A["Memorable public name"] --> B["Conversation, recall, and search"]
C["Stable technical identifier"] --> D["Versioning, APIs, support, and evaluation"]
B --> E["One governed naming system"]
D --> E
E --> F["People can remember the product and identify what they used"]
Why Nano Banana stuck
Google's later account corrects a common origin story.
The team had already selected Gemini 2.5 Flash Image as the technical name. It needed a public codename for an anonymous LMArena submission. Product manager Naina Raisinghani proposed Nano Banana during a late-night exchange by combining two personal nicknames, "Naina Banana" and "Nano." Google says the team introduced the model under that name on LMArena in early August 2025. Google's Nano Banana name history
The name was not a secret internal label that leaked. It was a public pseudonym used while the model's ownership remained hidden.
The phrase had several advantages once people encountered it. Both words were familiar. The combination was unusual. It produced a visible mental image. It could become an emoji, a color, a joke, and a search phrase. It did not require someone to remember where "Flash" sat inside the Gemini model hierarchy.
Those properties did not prove that the model was good. The editing results gave people something to discuss. The name made that discussion easier to carry.
Google later adopted the label across product surfaces and added Nano Banana Pro for Gemini 3 Pro Image. By July 2026, Google's developer guide used Nano Banana for a family of four distinct API models. Google's current image-generation guide
The original advantage now creates a documentation requirement. "I used Nano Banana" is not enough for a reproducible test. The evaluator needs the model identifier, date, product surface, and account conditions.
Concrete language can help memory, but it is not a naming formula
Laboratory studies have repeatedly found differences between concrete and abstract word processing. A 2006 recognition-memory study reported better memory performance for concrete words than abstract words under its experimental conditions. The effect of word concreteness on recognition memory
That result does not prove that a concrete product name will outperform an abstract one. Product naming involves prior associations, category fit, pronunciation, distinctiveness, media, budget, quality, and culture. A word-recognition task is not a product launch.
It does provide a useful caution for highly abstract technical language. A name that offers no image, sound pattern, story, or familiar association asks the audience to remember the organization's internal taxonomy.
"Banana" is easy to picture. "2.5 Flash Image" is easier to place in a model catalog. Each form reduces a different kind of uncertainty.
A name travels when people can do something with it
Memorability is only the first condition. A name has to be socially usable.
A socially usable name can be pronounced with confidence, recognized when heard, typed without consultation, adapted into a sentence, and connected to an artifact another person can see. It gives a community material for shorthand without requiring everyone to learn the underlying architecture.
Nano Banana also arrived beside visual transformations. A figurine, clothing change, or pet plush could carry the capability into a feed while the name supplied a compact reference. The artifact made the product worth discussing. The name made the discussion easy to repeat.
This relationship prevents a common naming mistake. A strange label cannot manufacture product value. It can only help people carry value they have already perceived.
Distinctiveness can become category debt
An unfamiliar phrase may be easy to own in search and easy to notice in a list. It may also tell a new user nothing about the category.
"Nano Banana" does not reveal image generation, Google, Gemini, editing, or the difference between an app feature and an API model. That information has to arrive through product context, a descriptor, documentation, or repeated exposure.
Category debt is the continuing work required to explain what a distinctive name means. It is manageable when the product appears inside a strong parent brand and the interface supplies the task. It becomes costly when the name must stand alone across search, support, procurement, APIs, and public comparisons.
A naming system should answer four questions without forcing the reader to reconstruct a launch history.
| Reader question | Required naming signal |
|---|---|
| What kind of thing is this? | Category or functional descriptor |
| Who is responsible for it? | Parent company or product family |
| Which version did I use? | Stable version or model identifier |
| What should I call it in conversation? | Short public name |
The public name does not need to contain every answer. The surrounding system does.
Android shows the global clarity limit
Android's dessert names were memorable and playful. Google retired them as public release names with Android 10.
Google explained that L and R are not easily distinguishable when spoken in some languages, that some desserts were unfamiliar in parts of the world, and that new users could not easily tell which release was newer. The engineering codenames could remain internal while the public system moved to version numbers. Google's Android naming change
This case shows why delight and clarity can diverge. The names served an established community but did not provide universal version order or cultural familiarity at Android's scale.
The lesson is not that numbers are always better. It is that a global operating system has to make upgrade state legible to people who never joined the naming game.
Project Scorpio shows how to contain a codename
Microsoft revealed Project Scorpio as Xbox One X, then preserved the codename in the Scorpio Engine and a limited Project Scorpio Edition console. Xbox's Project Scorpio Edition record
That is a containment strategy. The codename retained meaning for enthusiasts and became a heritage signal. The shipping platform still had a formal name that could sit in the Xbox product line.
Containment works when the organization wants the energy of the informal name without making it responsible for every future release, support article, and comparison.
Bard becoming Gemini shows portfolio consolidation
Google renamed Bard to Gemini in February 2024. The company said the change reflected the relationship between the user experience and the Gemini family of models. Google's Bard-to-Gemini announcement
This was not a playful codename becoming public. It was a product name being consolidated into a broader technical and product family.
The case illustrates another kind of naming debt. Separate names can help a new experience establish itself, then become friction when the organization wants users to understand that the app, models, advanced tier, and ecosystem belong together.
Consolidation improves family recognition. It can also make everyday language less precise when the same word refers to a company initiative, model family, app, assistant, or paid experience. Descriptors and model identifiers still matter.
Test a candidate name before adopting it
A useful naming review separates human movement from operational precision.
| Test | Strong evidence | Warning sign |
|---|---|---|
| Recall | A person can remember it after encountering the product in context | Recall depends on seeing the logo again |
| Pronunciation | People in intended markets say it with confidence | Users avoid saying it or produce many incompatible versions |
| Transcription | A listener can type and search it | Speech produces unrelated spellings or terms |
| Distinctiveness | The name points to the intended product in search and conversation | It collides with a crowded category or unrelated established brand |
| Category fit | A descriptor makes the task clear without a long explanation | The name continually hides what the product does |
| Ownership | The parent brand can be recovered from the experience | Users cannot tell who operates the product |
| Version clarity | The current release can be named and compared | One nickname refers to several incompatible products without identifiers |
| Social use | The name fits ordinary sentences and recommendations | It only works inside presentation copy |
| Cultural review | Intended audiences understand the associations and tone | Meaning, pronunciation, or humor changes materially across markets |
| Legal review | Appropriate trademark and jurisdictional checks are complete | Distinctiveness is assumed from an internal brainstorm |
The test should use people who did not attend the naming meeting. Internal familiarity can make a weak name feel inevitable.
Search data, interviews, pronunciation tests, support logs, and task-based research can provide evidence. A social mention count may show attention, but it cannot tell whether people understood the product or remembered the correct version.
Adopt, contain, or retire
An informal name has three broad futures.
Adopt it when users already carry it, the associations fit the product, legal and cultural review succeeds, and the organization can attach clear category, ownership, and version signals. Google took this path with Nano Banana.
Contain it when the name has community value but should not become the main product taxonomy. A limited edition, engine name, experimental channel, campaign, or internal release label can preserve the connection. Project Scorpio followed this path after Xbox One X became the shipping name.
Retire it when pronunciation, cultural reach, category clarity, portfolio fit, or version order creates more friction than the name returns. Android's public dessert sequence ended for these reasons, even though the tradition remained recognizable.
The decision can change over time. A codename that is helpful during anonymous evaluation may become a public brand, then require a stronger version system as the family expands.
Keep the memorable name and the audit trail
The best system often has two visible layers.
The public layer gives people a short, memorable name and a clear category description. The technical layer gives evaluators, developers, support teams, and publishers a stable identifier.
For Nano Banana, a public record might say "Nano Banana, Google's Gemini image-generation and editing family." A reproducible test would add the exact identifier, such as gemini-2.5-flash-image, the date, the interface or API, and the account conditions.
That pattern lets the name travel without asking it to carry the entire release architecture.
An informal name is successful when people can remember it and still discover what they actually used. The name earns attention. The naming system preserves meaning.
AI assistance was used for research organization, drafting, and validation. Publication remains unauthorized.
Sources
Follow the evidence.
- The effect of word concreteness on recognition memorypubmed.ncbi.nlm.nih.gov
- Android public naming changeblog.google
- GIE-Benchalphaxiv.org
- Systematic review of human and AI co-creativityarxiv.org
- ai.google.dev: image generationai.google.dev
- CompBenchcomp-bench.github.io
- Bard becomes Geminiblog.google
- Nano Banana across Google productsblog.google
- EditInspectorresearch.google
- Nano Banana in Google Photosblog.google
- Gemini 2.5 Flash Image model pageai.google.dev
- Nano Banana examplesblog.google
- Google AI updates from November 2025blog.google
- Canva Magic Layerscanva.com
- Xbox One X Project Scorpio Editionnews.xbox.com
- How Nano Banana got its nameblog.google
- Gemini app updated image editing modelblog.google