A connected product has several names before a customer ever sees it. Engineering may use a board number. The app team may have a project code. A sales presentation may describe it as a platform. The public name needs a different job: help a buyer recognize the product, talk about it, and find it again. Start there, before asking a room full of colleagues which word feels most futuristic.
This guide is for a team choosing the public name of a device or device family. The practical outcome is a short, documented comparison of candidates, followed by a small buyer test. All sample names and situations here are illustrative. A naming exercise can reveal communication problems; it cannot establish trademark clearance or predict market demand.
Write the sentence the customer needs
Describe the product in one plain sentence with the proposed name left blank. “Blank is a room sensor for people who want to check conditions from one display” is more useful than “Blank is an intelligent connected experience.” The first sentence identifies an object and a task. The second leaves a reader guessing what arrives in the box or what work the software performs.
Keep that sentence beside every candidate. If a name only works after replacing the product description with grand language, it may be doing the wrong job. Ask whether the buyer needs to recognize hardware, a hosted service, or a toolkit. A device name that sounds like an enterprise analytics portal can send the conversation toward features the team never intended to build.
Separate the company from the first product
A company can have a broad name and a specific first product. That lets the packaging say something useful such as Room Sensor or Gateway Mini without asking the corporate name to explain every feature. Draw the naming hierarchy on paper: company, product family, model, and version. Each level should answer a different question. A model code can serve inventory without becoming the phrase a household is expected to remember.
Test a second plausible product in that hierarchy. If it requires the company name to change, decide whether that constraint is acceptable. Some businesses deliberately serve one narrow job for years. Others expect a related family. The exercise is about fitting the intended business, not stretching every candidate to cover every imaginable market.
Run a spoken test before a logo test
Read each candidate aloud in a realistic sentence: “The installer is bringing the blank tomorrow.” Then ask another person to write down what they heard. Do this without showing the spelling first. Record the variations, including spaces, doubled letters, and mistaken endings. A single mistake is not a verdict, but repeated errors reveal the explanation the team will have to provide.
Try the same exercise over an ordinary phone connection. Avoid coaching the listener with “it is spelled exactly how it sounds.” That sentence hides the very result being measured. If the name has more than one plausible pronunciation, decide whether the alternatives are harmless or likely to cause confusion. Internal familiarity makes unusual spellings feel easier than they may be for a new customer.
Test recognition after a little time
Immediate preference and later recall are different observations. Show a small set of candidates in the same plain type, with the same product description. After a separate task or a break, ask participants which names they remember and what products they associate with them. Record their actual words. Avoid translating a vague positive reaction into a claim that the name has been validated.
Five relevant buyers can be a useful first round for finding obvious friction, although that small group does not represent a market. Recruit people close to the actual buying role. A facilities manager and a consumer browsing home accessories may respond to the same name for different reasons. Keep their observations separate so the team can see which audience a candidate serves.
Inspect the name where it will live
Put the candidate on a rough package front, a mobile app title, a support page heading, and an invoice line. Use ordinary sizes. A name that looks striking across a presentation slide may be hard to distinguish on a small label. Check its appearance in mixed case and in the fonts the product is likely to use. Look especially at letter combinations that resemble numbers or each other.
The domain deserves its own test. Ask someone to type the address after hearing it, then inspect the result. Keep the full extension visible in the exercise. Owning one address does not mean every nearby spelling will be available, so list the likely mistakes and decide which ones create a practical problem. Do not assume a short string is automatically an easy string.
Keep search and clearance distinct
A web search can reveal existing uses, confusing neighbors, and language associations. It is a useful screening step, not a complete rights assessment. The USPTO guidance on comprehensive clearance searches explains that checking for conflicting marks involves multiple resources. A domain registration alone does not establish the right to use a name for every product or in every market.
Have qualified trademark counsel assess finalists for the intended goods, services, and territories before a consequential launch commitment. Give counsel the actual product plan, not only the word. Meanwhile, keep a dated record of the team's preliminary searches and observations. The useful output is a clear question for professional review, rather than a confident “available” label based on an empty search result.
Watch for promises hidden in the wording
Terms that imply complete security, universal compatibility, or perfect reliability can create expectations the product team cannot support. Read the candidate beside the product description and ask what a reasonable buyer might infer. If the name makes a large promise, the supporting claims need careful review. A product can sound confident while describing a bounded, demonstrable use.
For instance, a proposed sensor brand built around a word meaning “always” may raise questions about outages and service life. That does not automatically rule it out, but the team should notice the implication. The NIST IoT device cybersecurity baseline is a reminder that security consists of specific capabilities to examine. A reassuring name should never substitute for that product-level work.
Make the decision traceable
Use a simple comparison sheet with columns for spoken accuracy, recall, product association, visual fit, domain entry, and unresolved rights questions. Write observations in the cells instead of assigning impressive-looking scores without a method. If two people disagree, keep both observations and identify the buyer role behind each one. The team can then make a judgment with its tradeoffs visible.
End the exercise with one candidate, one alternative, and a short list of work still required. The next action might be another buyer round, a language check, or professional clearance. Resist reopening the entire naming process whenever someone discovers a new word. A usable name should let the team return to building the product, with a clear reason for the choice and an honest record of what the test did and did not establish.