Most robotics homepages are written in the language of the lab that built the product. Buyers read them in the language of the operation they run.
Robotics founders should describe their technology in the language of the buyer's operation, which means product mix, shifts, peak season, and the exceptions that stop a line. Technical vocabulary isn't too hard for operations buyers. It signals that the product was designed around research goals rather than their operation, and that signal costs trust before anyone evaluates a single capability.
The problem with jargon is the signal, not the difficulty
A director of operations at a distribution center talks fluently in cost per pick, mispick rates, dock-to-stock time, and labor hours per shift, and reads integrator quotes and WMS reports for a living. That's deep technical knowledge built around their operation rather than your research.
So when a homepage leads with "embodied intelligence in unstructured environments," the buyer isn't stuck on the vocabulary. They're noticing whose vocabulary it is. Every technical field has its own words, and which field's words you choose signals to the reader whose problem you set out to solve.
Researchers at Ohio State found that the signal holds even when the words are explained. In a 2020 study in the Journal of Language and Social Psychology, Hillary Shulman and colleagues had 650 adults read short passages on topics including self-driving cars and surgical robots, written with or without specialized terms. Adding hover-over definitions didn't help, and the jargon versions left people less interested in the topic. Shulman's read was that specialized vocabulary works as a signal about who a conversation is for.
That's the cost on a robotics homepage, and it's why simpler words aren't the fix. The buyer's words should be used with the same precision you'd use for your own research documentation. That choice tells them the product was built with their operation in mind.
Why technical founders default to lab language
No founder sets out to write their homepage like a research paper. It ends up that way because a founder's first audiences rewarded exactly this vocabulary. Investors wanted to understand the technical moat. Grant committees, conference reviewers, and the lab down the hall wanted the precise term. The first technical champion at a pilot site wanted the architecture. Every one of those audiences paid the founder back for sounding like a researcher, so that language became the default. It ended up on the website and in the pitch deck because no one stopped to ask whether a buyer would hear it the same way.
It's also hard to see from the inside. Psychologists call this the curse of knowledge; once you know something, it's hard to imagine not knowing it. In a 1990 Stanford study, Elizabeth Newton asked people to tap out the rhythm of well-known songs and predict how often listeners would name the tune. Tappers expected listeners to get about half of the songs correct, but listeners only named 3 of 120, or 2.5%. The tappers could hear the melody in their heads. The listeners heard knocking.
We work in robotics every day, and we catch ourselves doing it too. "Foundation model" and "physical AI" feel like common vocabulary inside this industry. To a plant manager, those terms can read as buzzwords or bring to mind a chatbot, and neither tells them what your robot does on their floor. That language has its place in the investor deck, in technical due diligence, and in conversations with an integrator's controls engineer. Keep the technical language for those readers, and write everything a buyer sees in the language of their operation.
Jargon works on exactly one person in the buying company
Technical language does land with someone. The technical champion, often an engineer or automation lead, reads your materials the way you wrote them. That's why it feels like it's working. The champion gets excited, the first call goes well, and then the deal stalls somewhere you can't see.
It stalls because the champion doesn't approve a capital purchase alone. Gartner puts B2B buying groups at five to sixteen people drawn from as many as four functions, and our guide to What Is Sales Enablement in Robotics and Automation? covers who they are in this industry and what each one needs to see. Every person on that committee reads your website, your deck, and your LinkedIn page without the champion's background. When your language only works for the champion, the champion has to translate it for everyone else, and they'll do it with less time, less context, and less conviction than you would.
The same capability, in lab language and in plant language
Translation doesn't mean removing the capability. It means describing it from inside the buyer's building: what happens on their production line, to their product, on their shift. Here are four rewrites across the places founders talk most. The "before" lines are composites, not quotes from any company.
Homepage headline
Before: "Foundation models for embodied intelligence in unstructured environments."
After: "Robotic picking that keeps up when your product mix changes, so your team can spend their shift on the work that needs them."
The buyer already knows their mix changes. New SKUs land before peak, packaging shifts when a supplier changes, and seasonal items come and go. "Unstructured environments" is the researcher's name for that problem. "When your product mix changes" is the buyer's name for it, and using it tells them you know what their building looks like in November.
Pitch deck capability slide
Before: "Learned 6-DoF grasp policies that generalize across heterogeneous SKUs."
After: "Picks items it hasn't seen before, so adding a new product doesn't mean calling us to retrain the system."
The before is accurate and impressive to anyone who knows what a grasp policy is. The after answers what a VP of Operations is really asking about generalization, which is what it costs them every time the catalog changes.
LinkedIn post
Before: "Excited to share our latest paper on sim-to-real transfer for deformable object manipulation."
After: "If polybags are the item your team still picks by hand, this one's for you. Our system learned to handle them in simulation before it ever touched a real one, so it doesn't stumble when your supplier switches bags."
The paper is still worth sharing. Lead with the problem it solves on a real line, and the people who have that problem will read the rest.
First call
Before: "Let me start by walking you through our perception stack."
After: "Before we get into the system, tell me what your team does today when a product shows up that the line wasn't set up for."
On a first call, translation starts with the question you ask. Opening with the architecture tells the buyer the meeting is about your product. Opening with their exceptions tells them it's about their operation, and it hands you the language to use in every follow-up.
People are part of the story, so put them in it
Lab language tends to describe a system with nobody around it. "Fully autonomous," "zero touch," and "lights out" are written as strengths. On a homepage, those words say nothing about the people who do the job today, so the buyer fills in that part themselves, usually with the worst case. The buyer will raise the staffing question later in the deal either way. Your copy decides whether they arrive at it already worried.
Describe the system working alongside the people who'll run it. Instead of "autonomous exception handling," say what actually happens. When the robot can't pick an item, it sets it aside, flags it, and an operator clears it from a tablet without stopping the cell. Instead of implying the job disappears, say how it changes. It's also the more credible message, because anyone who has lived through an automation project knows someone always handles the exceptions. Putting that person in your copy tells the buyer you know it too.
The research is why it works. The operation is why it matters.
None of this asks you to hide the technology. The right technical reader will want every detail, and they should get it. But the homepage, the deck, the LinkedIn page, and the first ten minutes of a call are where everyone else in the buyer's company decides whether you understand them. One test before anything goes out: could a plant manager read this line aloud to their own team and have it mean something about their shift? If not, it's still written for the lab. The words that win the buyer are already in use in their building, and the founders who learn them first get the second meeting.
Sources
- Shulman, H. C., Dixon, G. N., Bullock, O. M., & Colón Amill, D. "The Effects of Jargon on Processing Fluency, Self-Perceptions, and Scientific Engagement." Journal of Language and Social Psychology, 2020. Online experiment, 650 US adults. Source for the finding that definitions did not offset jargon's effect on perceived difficulty and engagement.
- Newton, E. "The Rocky Road from Actions to Intentions." PhD dissertation, Stanford University, 1990. Source for the tapper/listener study (120 songs, 3 identified, tappers predicted about 50%).
- Gartner Sales Survey Finds 74% of B2B Buyer Teams Demonstrate "Unhealthy Conflict" During the Decision Process. Survey of 632 B2B buyers, August–September 2024. Source for buying group size (5–16 members across up to 4 functions).