Content strategy (or content design) is still an emerging discipline. I say emerging because even though we’re at big tech companies like Airbnb and Facebook, it’s not easy to find us at smaller startups. Content strategy is nonexistent at most business-to-business software as a service (B2B SaaS) startups. We also still get the occasional, “what do you do, exactly?”

I can’t blame people for asking because the way we practice content strategy keeps evolving and it’s not done the same everywhere. I’m the sole product content strategist at Signal Sciences, which means that I’m lucky enough to have a lot of autonomy and ability to keep redefining what content strategy is and what it’s capable of.

The easiest way to describe what I do to people who are unfamiliar with content strategy is to say that I write all of the interface copy for our SaaS product…but that’s selling our discipline short. We’re not just writers. Content strategy is fundamentally about clarity, consistency, and communication that extends beyond just the product. It’s getting every department in the company aligned behind the same nomenclature and talking to our customers in the same voice so we sound cohesive. Our main goal is for everyone to speak the same language.

Shaping content strategy at Signal Sciences

Enterprise software is notorious for having confusing UX and nomenclature that doesn’t resonate with users, but Signal Sciences has always prioritized product design. We believe that highly technical users deserve user-friendly experiences.

When I first joined Signal Sciences, our technology was solid and we had a great UI, but our product was missing key editorial elements. We lacked any distinct voice and tone, consensus on grammar rules (should I use the oxford comma?), or guidance on word usage. (Should I say “developers” or “engineers?” “Graphs” or “charts?”)

To get everyone aligned, we defined our product’s taxonomy and created editorial guidelines.

Defining a product taxonomy… naming things is hard

We often hear about designing with scalability in mind, but we rarely talk about treating words and product terms with the same amount of care and attention. Terms can evolve as products evolve––a term that once made sense can stop making sense depending on how the product changes over time.

Outdated terms were a big problem that affected almost every department in our company. One of our biggest taxonomy problems was using the term “dashboard” to describe three entirely different concepts in our product hierarchy.

We also used the term “sites” for a unique concept in our product that represented what our users protect: a single web app, a group of web apps, an API, or a hybrid mix of both. “Site” didn’t make sense because it implied only a single website and was confusing our users… yet it existed in our product for years. Because this term was so problematic, different departments resorted to using terms that they felt made more sense to users—and “dashboard” was one of them.

Our original product hierarchy looked like this:

• The dashboard contains a set of dashboards/sites that each have their own set of dashboards.

When different departments disagree about taxonomy or can’t come up with a better term than the one that’s not working, everyone starts to speak their own language. We start to feel less confident about the way we communicate and we give our users an inconsistent experience. Content strategy is like a binding thread that helps connect departments by coming up with terms people feel comfortable using.

Renaming things sounds easy in theory, but is often challenging in practice. If a term is going to be scalable and worth the time and effort it takes to change it, then it has to be thoroughly researched. I’ve conducted interviews, dug through customer support tickets, put together audits, done competitive research, and brainstormed dozens of bad terms to get to the right one.

After going through this process, we now have a clear and easy-to-understand product hierarchy that looks like this:

• The console contains a set of workspaces that each have their own set of dashboards.

Getting consensus on new terms is only the first half of taxonomy work. The second half starts with socializing what these terms mean and how to use them correctly. Each term also needs its own rollout plan to change the term everywhere it exists across the entire company and any caveats that come with the change (a new term might impact the UI or the API).

B2B SaaS products, including highly technical ones like ours, will always need taxonomy work because taxonomy is part of the product ecosystem alongside the design system and codebase.

Better writing with editorial guidelines

As a fast-paced startup, we’re constantly creating content beyond the in-product experience. There are decks, whitepapers, marketing copy, and social media operating in tandem. But as an army of one, I can’t write everything that we publish.

Writing can be messy and subjective. Even grammar can be somewhat subjective depending on if you’re into AP style or the Chicago Manual of Style. There are even people out there who still believe in a double space after a period (I am definitely not one of those people).

When you’re working in the technical world of application security, vocabulary can also get messy. From my experience working with various product teams, I’ve heard people ask:

• Are “requests” and “traffic” the same thing?
• Are feature names capitalized?
• When do we say “alert” vs. “notification?”
• Is it ok to say “tags” or do we always need to say “signals?”

As part of our design system, Cosmo, I wrote editorial guidelines to answer questions like these and improve our overall messaging consistency. These guidelines include how to write in our product’s voice and tone, a product glossary, grammar rules, and guidance on word usage. Now everyone in our company has a quick reference on when to use the right words at the right time.

Hire a content strategist!

It’s hard to see the value of a content strategist if your company doesn’t have one yet. Content strategy adds meaningful value to B2B SaaS startups in their earliest stages, right when you’re solidifying core product features and ready to tell your product story. Every company has its own language and taxonomy system, and it deserves the same attention and consideration as other aspects of product work.