If you are deciding whether an AI product should become your company name, you probably do not have a naming problem. You have a portfolio commitment problem. The rename will make your bet visible, but it will also force you to explain what existing customers still own, what will keep improving, and what now defines the company’s future.
The Intercom-to-Fin move offers a clean way to think about that decision. The company is now named Fin, while Intercom remains its customer service software platform; Intercom 2 has also launched as a complete rebuild with continued investment behind it. The growth brand moves up to the corporate level without erasing the durable product brand beneath it. That is the strategic work of this rebrand.
The decisive choice is what you do not rename
The most important word in this rebrand is not Fin. It is “remains.” Intercom remains a product, a customer commitment, and a place where the company can keep creating value. Fin becomes the corporate identity and the clearest expression of the next growth thesis.
Changing the company name while retaining the established product name is not an incomplete rebrand. It is deliberate brand architecture. The two names answer different customer questions:
- The company brand answers: What future is this organization building toward?
- The product brand answers: What can I buy, operate, renew, and rely on today?
- The category brand answers: What new capability should I understand, budget for, and compare with alternatives?
Those answers do not always belong under one name. Forcing them together can make the new strategy sound smaller than it is or make the established product appear to be on its way out. Keeping Intercom as the platform avoids turning corporate ambition into accidental product deprecation.
Before approving a similar rename, write a transition contract. This is not a legal document. It is a short internal statement that every product, sales, marketing, support, recruiting, finance, and communications leader can use without improvising. It should answer:
- Exactly which entity is being renamed?
- Which products keep their current names?
- What changes for an existing customer because of the rename?
- What explicitly does not change?
- Where will investment increase, continue, or decline?
- How should someone describe the relationship between the company and each product?
If the answers vary by executive, your organization is not ready to communicate the rename. Customers will encounter every inconsistency as a separate strategic story.
A new category needs a clean place in the buyer’s mind
Established brands are efficient because buyers use them as shorthand. The same shorthand becomes restrictive when a company wants to define a substantially different category. People do not continuously reassess every vendor from first principles. They attach new information to what they already believe.
That is why a legacy name can create friction even when it has strong awareness and customer trust. The problem is not that buyers dislike the old brand. The problem is that they already know where to file it. Every pitch for the new category begins with a correction: the company you associate with one product is now asking you to understand it as something else.
Fin had time to develop as a distinct service-agent identity before becoming the company name. The business introduced Fin three years before the corporate rename and deliberately led with that name while keeping Intercom in the background. That sequence matters. It allowed the category proposition to earn meaning before the corporate identity was placed behind it.
You should look for the same underlying evidence before elevating a product brand:
- Prospects ask for the new product or category by name instead of treating it as another feature of the established platform.
- The product has a distinct job, competitive set, buying conversation, and roadmap.
- Your largest resource-allocation decisions increasingly revolve around the new category.
- The existing company name repeatedly requires explanation before buyers understand the new proposition.
- The legacy product can remain a coherent, investable business under its own name.
- Leadership is willing to keep prioritizing the category when it competes with comfortable, near-term work elsewhere in the portfolio.
Wait if the new product still depends almost entirely on legacy demand, if “AI” is the only thing making it sound like a new category, or if leaders cannot explain the future of the existing portfolio. A corporate rename should settle a strategic truth that is already visible in the product and resource decisions. It cannot manufacture that truth.
Test the strategy before you test the name
Name preference is the least important question at the start. A memorable name cannot rescue an unstable thesis, and a room full of favorable reactions cannot prove that the proposed architecture makes sense. Test the decisions the name is meant to encode.
Strategic permanence
Ask whether the new identity can survive normal product evolution. A company named after a feature will eventually outgrow its name. A company named for a durable category, customer outcome, or long-term platform has more room to expand.
Pressure-test the choice against plausible roadmap changes. If the current interface changes, the underlying models improve, or the product expands into adjacent workflows, does the name still represent the company? If one disappointing planning cycle would make leadership retreat to the old story, the corporate rename is premature.
Customer comprehension
Do not ask customers whether the new brand “makes sense.” That question invites politeness. Show them the proposed naming hierarchy without an explanation and ask them to describe:
- What the company does.
- What they can buy.
- What happened to the existing product.
- Which name they expect to see in the application, documentation, support experience, and commercial relationship.
- Whether the new offering feels like a feature, a product, a platform, or a category.
The vocabulary in their answers matters more than a preference score. If customers merge the company and product into one ambiguous object, the hierarchy needs work. If established customers assume their product is being replaced, the continuity story is too weak. If prospects still describe the company only through the old category, the new position has not yet become legible.
Portfolio durability
Every product affected by the rename needs a stated fate: promoted, retained, integrated, or retired. Silence creates its own answer, and customers usually interpret it as declining commitment.
The Intercom-to-Fin architecture avoids that ambiguity. The corporate brand follows the AI growth engine, while the established platform receives a rebuilt product and continued investment. You can apply the same discipline by requiring a roadmap, owner, customer promise, and success measure for every brand that survives the transition.
Operating commitment
A company name is a resource-allocation claim. Check whether hiring plans, executive attention, roadmap capacity, sales enablement, partner priorities, and operating metrics already support the future implied by the name.
This is where weak rebrands reveal themselves. The homepage changes, but planning continues to favor the old center of gravity. Sales compensation rewards the previous motion. Product teams keep describing the AI offer as an add-on. Recruiting language promises one future while internal goals fund another. If those contradictions remain, the market will believe the operating behavior rather than the new identity.
Turn the rebrand into an operating model
A corporate rename touches more than brand assets. It changes the nouns people use to make product, commercial, and technical decisions. Treat it as a cross-functional migration with a defined architecture, owners, dependencies, and observable failure modes.
Before launch, remove internal ambiguity
Start with an inventory of named objects. Separate the corporate brand, legal entity, product names, application name, AI agent, domains, documentation, status pages, integrations, partner listings, support channels, and customer-facing team names. They may not all change together, and some should not change at all.
Create a controlled vocabulary for each object. Record the approved name, a plain-language definition, the transition phrase, phrases to avoid, and the person responsible for exceptions. Then apply it to roadmap documents, release notes, sales materials, onboarding, job descriptions, support macros, analytics labels, and executive reporting. This prevents each function from inventing a slightly different portfolio.
Keep the public brand change separate from legal and payment instructions. A new display name does not automatically mean that the contracting entity, tax information, or bank details changed. Telling customers to update those records without confirmation can create payment failures, procurement delays, and fraud risk. Legal and finance owners should identify any real operational changes and communicate them through established, verifiable channels.
Build the customer FAQ from actual consequences, not brand language. Cover logins, existing contracts, invoices, data handling, support access, integrations, domains, saved links, product roadmaps, and administrative work. For every item, say whether action is required. “No action required” is useful only when you have verified it across the relevant systems.
At launch, separate ambition from continuity
Lead with the scope of the change. Say which name belongs to the company, which belongs to the existing product, and how the new category fits. Then explain why the corporate identity is changing. Follow that with a precise account of what existing customers should expect.
Do not rely on “nothing changes” as reassurance. It is usually too broad to be credible, especially when a new product strategy and increased investment are central to the story. Name the stable elements instead: the product that remains, the workflows that continue, the commitments that persist, and any interfaces or commercial records that stay the same.
Use the same architecture everywhere a customer can encounter the company. A clear launch page cannot compensate for an application header, help center, invoice, partner marketplace entry, or sales deck that implies a different relationship. Transitional wording can help connect the names, but it should have an exit condition rather than becoming permanent clutter.
After launch, measure the translation tax
Launch reach tells you that people saw the rename. It does not tell you that they understood it. Establish a pre-launch baseline where possible, then monitor evidence of confusion:
- Support conversations asking whether the existing product is being discontinued or replaced.
- Sales calls in which representatives must repeatedly correct the company-product relationship.
- Documentation searches that mix old and new names in ways your information architecture does not handle.
- Broken redirects, failed bookmarks, authentication problems, or integration errors caused by changed domains or labels.
- Procurement and accounts-payable questions about the company name, contracting entity, or invoice sender.
- Prospect descriptions of the category after encountering the new positioning.
- Retention, adoption, and expansion for the established product, tracked separately from awareness of the new corporate brand.
Review the language in those interactions, not just their volume. The words customers use will show whether the new mental model has formed. Retire transition copy only when support, sales, search, and customer interviews indicate that people can move between the names without assistance.
Key takeaways for your own portfolio decision
- The Fin corporate name expresses the future growth bet; retaining Intercom protects a valuable product identity and signals continued commitment.
- A corporate rename is a brand-architecture and resource-allocation decision, not a cosmetic marketing project.
- Elevate a product name only when the category, roadmap, buying conversation, and operating priorities already support it.
- Tell customers exactly what is renamed, what remains, what changes, and whether they need to act.
- Validate comprehension with unscripted customer explanations, not name-preference questions.
- Measure confusion across support, sales, documentation, procurement, integrations, and product health after launch.
If this decision is in front of you, bring a one-page transition contract to your next portfolio review. Ask product, sales, support, legal, finance, and recruiting to describe the company and its products using the same nouns. If they cannot, keep working on the architecture. If they can, and your resource allocation already matches the story, the rename can do its real job: make the strategy easier for the market to understand.
Leave a Reply