This article was featured as Community Post of the Week in the Mind the Product newsletter.

A few years ago, I was a product manager at a hardware company. We had built something genuinely impressive: a sophisticated colour management engine that sat at the core of our 3D printing pipeline. It handled gamut mapping, profile calibration, and real-time ink optimisation. The engineering was solid. The results were measurable.
I proposed we give it a name. Turn it into a platform. Call it somethingâChromSyncâ˘, I suggestedâand treat it as a product asset rather than a project deliverable.
The room went quiet. Then came the looks. Not hostile. Just⌠blank. As if I'd suggested we write poetry about the firmware.
That moment taught me something I've been thinking about ever since: the gap between a manufacturer and a product company is, in large part, a naming gap.
A name is not a label. It's a cognitive container.
When engineers build a capability, they think about what it does. When product people name a capability, they change what it is.
A name creates a cognitive container. Once something has a name, people treat it as a wholeâsomething that can be extended, protected, marketed, and improved across generations. Without a name, even the most sophisticated technology remains what it was the day it was written: a collection of files solving a specific problem, owned by no one, understood by few, and forgotten after the next rewrite.
This is not a semantic argument. It's an organisational and strategic one.
When I proposed ChromSyncâ˘, I wasn't asking for a logo. I was asking the company to commit to a long-term asset. To invest in documentation. To think about reuse across product lines. To build a moat. The name was the forcing functionâthe moment a project becomes a product.
The blank stares told me everything. The company had no concept of technology brand equity. They were, at their core, engineers shipping projects. And they would stay that way.
The evidence is sitting in your unboxing experience
Earlier this year, I was researching the Anker eufyMake E1, a consumer-grade UV printer capable of printing full-colour 2.5D textures onto physical surfaces. In the product documentation, two names jumped out at me:
Amass3Dâ˘: their proprietary textured surface printing technology; and
ColorMaestroâ˘: their AI-powered colour reproduction system.
Anker is, fundamentally, an engineering-first company. They built their early reputation on cables, chargers, and power banksâhardware categories that reward reliability and cost efficiency, not storytelling. Yet here they are, naming their technologies. Trademarking them. Positioning them as product features a customer can understand, remember, and ask for by name.
That's not a marketing team going rogue. That's a company that has made a deliberate choice about what kind of company it wants to be.
The contrast with most Chinese hardware manufacturers is stark. Many of them produce technology that is, by objective measures, competitive or superior. But their capabilities live inside SKUs, not inside named platforms. When the product is discontinued, the capability disappears with it. There is no equity to carry forward. No brand to leverage. No classic to build on.
Why engineer culture resists naming
This is worth examining honestly, because it's not stupidity or laziness. There are real reasons why engineering-led organisations resist the naming impulse.
Naming feels premature. Engineers are trained to ship working solutions before declaring victory. Giving something a name before it's proven feels like marketing spinâor worse, like setting expectations they'll have to live up to.
Naming feels arrogant. In cultures where modesty is a professional norm, standing something up and putting a brand name on it can feel presumptuous. Who are we to call this a platform?
Naming creates accountability. If ChromSync⢠is a named asset, it needs to be maintained, documented, and positioned. That's overhead. Projects can be quietly abandoned. Named platforms cannot.
Each of these instincts is understandable. But together, they produce the same outcome: technology that is built once, used once, and then forgotten.
The miracle that happens after the name
Here's the thing that's hard to explain to someone who has never watched it happen: the moment you name something, the way people relate to it changes.
When a capability has a name, teams ask different questions. Instead of "does this work?", they ask "how do we extend this?" Instead of "can we ship it?", they ask "what's the roadmap for this platform?" Instead of "who owns this code?", they ask "who owns this product?"
A name transforms a local solution into a shared asset. It creates the conditions for the kind of long-term investmentâin quality, in consistency, in storytellingâthat eventually produces classics.
Apple's Retina Display. Intel Core. Dolby Atmos. These are not just marketing labels. They are commitments. They signal to every engineer, every product manager, every customer: this matters enough to have a name. We are building something here.
The Chinese hardware manufacturers who will still be relevant in ten years are the ones currently learning this lesson. The rest will continue to build impressive things that no one remembers.
What this means for product managers
If you work in a hardware organisation that is still in project mode, here is a practical starting point.
Name the capability before you ship it. Not after it has proven itself; before. The name is part of the commitment, not a reward for success.
Make the name carry meaning. ChromSync. ColorMaestro. Amass3D. These names do work. They evoke something. They are not acronyms, not internal codenames, not version numbers. A good technology name passes the customer test: can someone who doesn't know how it works still understand what it stands for?
Treat naming as a strategic decision, not a marketing task. The question is not "what should we call this?" The question is "what are we committing to?" The name is the commitment made visible.
Protect it. Trademark it. Document it. Give it a home in your product architecture. An unnamed capability is a liability. A named platform is an asset.
The blank stares are a diagnosis
When I look back at that room, at the people who looked at me like I was speaking a foreign language, I don't feel frustration anymore. I feel clarity.
They weren't wrong to be confused. In their mental model, code was code. It did things or it didn't. The idea that a name could change what code isâthat a label could transform a project into a product, and a product into a classicâwas genuinely foreign to them.
That's not a gap you close with a workshop or a style guide. It's a fundamental shift in how an organisation understands value. Some companies make that shift. Most don't.
The ones who do start with something small and seemingly trivial: they give their best work a name, and they say it out loud with conviction.
That's where classics begin.
Lemon Wang is a product manager specialising in hardware strategy and user research, with experience across consumer and professional 3D printing. She writes at lemon.wang.