Context
Edge was shifting from a browser with AI features to an AI browser. The change brought entirely new experiences to the surface with no precedent, existing category, or established language to describe them. I was the sole content designer on the browser. And that made this as much a content problem as a product one: the teams building these features were encountering them for the first time too. Nobody had the words yet — not the users, engineers, or PMs. The naming and the explaining had to happen in parallel with the building.
The problem that wasn't the real problem
Every naming decision became a debate. PMs argued for the words that fit the product roadmap. Marketing pushed for language that worked in launch copy. Leadership pulled toward whatever sharpened the competitive story. And each team had real reasons. Even when I narrowed the options to two, the room split — passionate disagreement on both sides, no clear winner, and a deadline closing in. Cross-team meetings turned into rounds of defense. Decisions that seemed settled by Friday were reopened by Monday, with a different lead asking why we hadn't considered a third option that we had, in fact, already considered and ruled out.
Then I started noticing the pattern. The decisions weren't sticking. Even after a lead finally signed off on a name, that same name would surface in the next round, debated all over again as if no one had agreed to it the first time. And the more I watched it happen, the clearer it got: every word was being argued on its own terms, disconnected from every other word the team had picked. Each naming decision was freestanding. There was no framework holding them together. The problem wasn't which word to choose. It was that nothing held the words in place.
Working at a different altitude
At some point I stopped trying to defend individual names and started asking a different question. Instead of arguing for each word, I needed a principle that would connect all the names — something every decision could point back to, so no particular name had to be defended without a foundation. The principle I landed on: names describe function, not brand. If a feature name depended on the AI mode, or the Microsoft AI brand, or any of the umbrellas the product was sitting under that quarter, it would break the moment the framing changed. And the framing always changed. Names had to stand on their own, regardless of whatever category they were grouped under.
I anchored the framework in the content principles that already existed for Edge. They hadn't been pulled into the AI conversation yet, but the foundation was there. From it, I established one rule: every feature had to be understood independently of any AI mode or brand. The name had to describe what the feature did — not what umbrella it sat under, not what marketing campaign it belonged to, not what the team happened to be calling the broader experience that month. Once that rule existed, the naming debates changed shape. When a new feature came up for discussion, I had a framework to point to instead of starting from nothing. The conversation moved from "which name do we like?" to "which name aligns with the explanation of what this does?" That second question had a much shorter answer.
The framework lived in product language, but I was also the person carrying it into marketing. While product is precise and functional and marketing is catchy and benefit-led, the concept underneath a feature had to be the same in both places. Otherwise users would encounter two different products: the one the UI described and the one the launch page promised. I was present in both conversations, which meant I was the one holding the line on consistency. The marketing team would adapt the feature description into whatever tone their channel needed, but the core value prop — the answer to "what does this do and why does it matter" — had to come from the product language first.
What held
The back and forth negotiation had stopped. When a name came up for debate in a new round, someone could point to the framework and the conversation moved on instead of restarting from nothing. And then what I had aimed for happened: other teams began applying the framework on their own. A PM would push back on a proposed name in a review I wasn't in, and the reasoning they used was the reasoning I had introduced — function over brand, independence from the mode, name has to stand on its own. The framework had stopped being mine. It had become the way the team thought about naming.
The language also started traveling. A feature description that landed in the product UI would show up in the marketing brief two weeks later, almost intact. The marketing team adapted the tone for their channel — tighter, more benefit-led, more persuasive, but the concept underneath stayed the same. The "what does this do and why does it matter" answer didn't have to be reinvented every time the feature crossed a team boundary. Product language flowed into marketing language. Marketing language flowed into launch pages. The words held their shape because the framework underneath them held its shape.
Then the AI mode was pulled. I opened the settings page expecting to rewrite, bracing for the kind of full-scale relabeling that a framing change usually triggers. Nothing needed to change. The feature names still made sense. The descriptions still described what the features did. Nothing had to be rewritten because nothing had ever depended on the mode to make sense in the first place. The words described function, not brand. And when the brand went away, the function was still there — and the words were still there with it, exactly where they'd been built to stand.
My biggest lesson
I thought my job was to be a good writer. I learned it was about being an analyst. And as one, it meant collecting the moving pieces from PMs, designers, leads, and engineers—to make sure the language met those needs. Beyond that, I built a system that held when the product changed underneath it. Most content designers defend their language choices. But the real skill is building a system that makes language decisions hold when the product shifts fast and clarity is scarce.
I stopped defending individual words. Instead, I built a system where decisions could easily be made. I gathered all the feedback I could. Not to win arguments, but to understand how language lived in the product over time. A word had to work across contexts, across updates, across the evolution of features. I learned that the strongest copy wasn't clever. It was durable.
Why this is necessary in the AI product era
AI products evolve faster than language can follow. A feature ships. The copy describing it becomes outdated before it's published. The product changes again. The words meant to explain it are already obsolete. This isn't a Microsoft problem or an Edge problem—it's the problem every AI company faces right now. The language can't be reactive. It can't be an afterthought bolted onto product decisions after the fact. It has to be built alongside the product, anticipated, systematic. It has to account for the fact that the product will shift underneath it. Language as infrastructure, not decoration.