Imagine this. You get a brand new robot vacuum cleaner. It's the commonly available white body machine with rounded edges; looks 'homely' than industrial so you can easily visualise it parked in your living area corner. You download the app to set it up. The app calls your rooms "living area" and "kids' room." These are great because you expect these as bare minimum in a smart app in 2026. And you know from the marketing material that once the job's done, you'll get a notification saying "All done! Your floors are clean." Everything about it reads: quiet companion, something that works alongside you while you're doing something else. Great.
You press start. The motor is a loud like a construction site (ok, not construction site but it's loud and harsh). The thing moves through your living room like it's clearing a well zoned area in an industrial setup. When it jams under the sofa, instead of asking for help, you get three hard beeps and an error code that requires Googling.
You can't name exactly what's wrong. You just know something is off.
What you're feeling is a product that was probably made with two different comparisons and eventually got shipped with both. Let me explain.
The physical design ideology is simple. This robot vacuum cleaner is like a domestic helper. The motor, how the cleaner moves around the house, the error communications you get were probably built using inspiration from industrial cleaners specs. Neither comparison is wrong on its own. What's wrong is that both are running at the same time, in the same object, and you feel the friction between them every time you use it.
That's the right word for it: metaphor. A theme is a mood board. A metaphor is a logic system. The product isn't actually a 'companion'. It can't have feelings or intentions. It's an appliance for God's sake! But it's shaped, weighted, and behaving as if it were one. The builders of this robot must have made a comparison and consciously or not, they said: this thing is like that other kind of thing. And that comparison propagated through every material decision, every sound decision, every software decision that followed.
When you accept "this is a companion," you don't need a separate rule that says "don't use error codes." You already know 'companions' don't issue error codes. The metaphor (companion) contains the implication.
A metaphor describes what the product is like. A governing metaphor is one that's been given decision-making authority. The difference is small until someone in a product meeting proposes adding a feature, and the question gets asked: does a companion do that? If the metaphor can say no, and the team accepts the no, it's governing. If the metaphor is only consulted when it agrees, it's signing up for that 'off' feeling users will eventually get.
Most product lines have a metaphor somewhere in a brand document, in an early product requirement brief, or in the CEO's head. What they don't have is a governing one. That's when it starts breaking and I mean this exact thing which becomes hard to articulate - 'feeling off.'
Now that you get the idea of both the metaphor and the governing metaphor, let's see how we can try to bake it in the products undergoing the build journey.
Start by looking at the product(s) you've already built, or the decisions you've already made, and ask: what is this thing consistently behaving like? Not what was it meant to be. What does it actually do when something goes wrong? How does it ask for attention? What does it do when you ignore it? The behavioural pattern usually reveals the metaphor that's already running. You either confirm it, refine it, or choose to replace it.
Once you have a candidate, test it as a decision tool. Take the three most contested questions currently open on your product: a feature that half the team wants to add, a sound design choice that's unresolved, a material that's cheaper but feels different when you hold it for the first time. Put each question to the metaphor. A 'companion' would handle that feature like this. A tool, on the other hand, would handle it like that. If the metaphor produces a clear answer each time, it's workable. If it produces the same answer every team member would have given anyway, it's not doing anything new. If it produces an answer that surprises you and you think the answer is right, you have a governing one.
Write it in a single sentence. Not "we want users to feel at home" but the comparison itself, stated directly. E.g. This is a silent house companion or this is a precision instrument you happen to keep in your kitchen. The sentence should feel slightly uncomfortable. If it's easy to agree with, it's probably not specific enough to govern anything.
"1,000 songs in your pocket" may have settled most of the original iPod's design arguments before the hardware existed. iPod was pocketable which means that weight mattered more than power. One thumb meant navigation had to work without looking… with just feel. A small screen meant only the essentials had to be displayed. And of course, battery life had to keep up with the promise of playing a thousand songs in a pocketable space constraint. That sentence became the tagline but more importantly, it was a constraint system, and every team argument about the hardware had an answer waiting: does this still fit in a pocket? Does it still work with one thumb?
The MacBook Air must have ran the same logic. "The world's thinnest notebook" killed ports, rebuilt battery geometry, changed keyboard feel, forced custom chips, rewrote thermal assumptions, and much more. Thickness of the laptop must have became more important than expandability. I'm sure when it came to sound, silence of the laptop mattered more than performance. Every feature proposal must have gone through the question if it still felt like the thinnest notebook. That question was allowed to say no. It said no often. The product line stayed legible for years because of this question - the governing metaphor.
I could also think of the Kindle. Its governing metaphor was probably: this thing is for reading. No email distraction or unnecessary for reading features like colour or apps. The screen should look and feel like paper, not glass. I had a Kindle Oasis and it was pretty slow. Now, it could could have been intentional because physical books are slow and don't flip pages at 165Hz. It said the thing is for reading.. so makes sense. The product stayed clear because the metaphor was clear, and nobody confused adding features with improving the product.
When no metaphor is chosen, the teams invent their own. All functions do. Leaders of the project would invent one, design would invent one, engineering another, marketing a third, and there's no stopping. The product ships with all of them running simultaneously, and users experience the contradictions without being able to name them, which is worse than a product they can simply criticise. A product that just feels slightly wrong is harder to walk away from and impossible to explain to someone else.
The robot vacuum is the visible version of this failure. The same thing happens in less obvious places. An AC unit with hospital-grade filtration specs, marketed in clinical language, installed into a domestic interior that was never designed to look medical. A smart lock that installs like a security system but is supposed to feel like coming home. A water purifier with one job — be trustworthy — that ships with a display showing twelve metrics nobody requested, because the capability existed and someone decided hiding it seemed wasteful.
The visual language of each metaphor is consistent in ways that are easy to feel before they're easy to explain. At one level, you can create broad buckets: companion products round their corners, tool products sharpen the corners. Any product positioned as helpers would use quiet sounds: the motor, the alert tone, the click of a closing panel. On the other hand, machines announce themselves. They want you to know they're working. Helpers ask for help when something goes wrong. Machines issue error codes. Helpers arrive in packaging that feels considered. Machines ship in corrugated boxes optimised for stack height (cost). All of it is the metaphor making itself visible in the only language it has.
Many product lines have an accidental metaphor: a default set of associations that accumulated while everyone was focused on the engineering. That one is usually findable. It's whatever the product most consistently is when nobody's watching. The question worth asking before the next feature brief or SKU extension is just: is that the one we'd have chosen? And if not, when did we stop choosing?