Why language, ontology, and representation matter in product operations
Why This Guide
How many times have you heard an executive team complain that they have no visibility into what is happening? They are surrounded by slides, dashboards, RAG statuses, and data, but still do not really know what is going on.
How many times have you heard a team complain that they are overwhelmed, that they have no sense of the real priorities, and that they are in constant swivel-chair mode "reporting" on things without much confidence that the reporting matters, or reaches the right ears?
How often have you heard people talk about the workarounds they need just to get any work done? And how they dread the moment a leader assumes context that is not really there, because they saw a status somewhere that was meant to tell the truth, but got flattened, filtered, or whitewashed on the way up?
How often have you heard people complain that there were no set definitions for things, but then when someone finally did try to set those definitions, it took the life and variety out of the thing itself? What was once variable, contextual, and real became an oversimplification to placate someone who needed a neat dashboard.
The inspiration for this short guide came from a simple observation: operations, especially in complex domains, involves information architecture and ontology creation. But it is very different from what you might do if you were doing operations management in a factory or manufacturing setting. The concepts are slippier. The flows and feedback loops are more variable. What you call things is extremely important, but also much more of an art than in more deterministic settings.
Words alone will rarely sink the ship. But they absolutely can contribute to headaches, misalignment, wasted motion, false confidence, and harmful flattening.
Who Is This For
This guide is for people working in and around product development operations, especially where the work is hard to name cleanly and harder to represent well.
It is for leaders and operators who have to decide what to call things, how to structure status, how to design planning and reporting views, and how to make complex work more legible without flattening it beyond usefulness.
That includes people in product operations, technology operations, transformation work, portfolio or planning functions, architecture, delivery leadership, platform leadership, and adjacent roles responsible for operating models, governance, coordination, or shared language.
In This Guide
In this guide, we will explore how people name work, how those names drift as they move across a system, how containers get mistaken for reality, how summaries lose context, and why so many operating problems are really problems of representation, interpretation, and scale.
Frequently asked questions
Why does shared language matter in product ops?
When teams use the same word for different things, or different words for the same thing, plans, reports and AI all misread the work. Many operating problems are really problems of representation and interpretation.
What does Getting the Words Right cover?
How people name work, how those names drift across a system and why so many operating problems come down to representation, interpretation and scale, with practical exercises to try.
Who should read Getting the Words Right?
Product operations, portfolio and transformation leaders, and anyone designing how work is structured, named and reported across an organization, including teams preparing their data for AI.
How do you build a shared glossary?
Collect the terms teams actually use, find where the same word means different things, agree definitions with the people who own them and attach them to the objects in your tools so the language holds as work moves.
How does language relate to an ontology?
An ontology is the formal version of shared language: the types of things you track and how they relate. Getting the words right is the first step to a model both people and AI can read.