It used to take me daysss to ideate and design three screen versions of a product. Now if it takes more than five minutes, I turn to my partner and say "Why is it taking too long?!"
Five minutes used to be nothing inside a multi-day cycle. Now it's the whole cycle.
When you work across multiple AI surfaces with a team: Chat synthesizing, Design rendering, Code generating, agents reviewing, that shift in pace exposes what was previously invisible: your team wasn't actually thinking from the same place.
The bottleneck isn't production anymore. It's coherence and comprehension. I've written extensively about coherence here, but today let's talk about something so tiny, so small, yet the building blocks of coherence: ontology.
Your first act as a product and design leader in your org: architect shared ontology to enable context. Everything else follows.
The Coordination Problem Across Surfaces
Imagine trying to coordinate work without a shared reference system.
Someone points at the Design canvas: "Fix that one... no, the other one... the payment flow variant."
A user story references a screen: "When the user reaches the form where they enter card details..."
A PRD links to a design: screenshot attached, somewhere in this Figma file.
An engineer gets a Code prompt: "Use the design from the flow where the user... and match the pattern from this other screen..."
A grammar review agent is directed to: "Tighten the copy on that confirmation message we designed."
Everyone knows what you mean. No one knows what you're referring to.
It's like your org chart became a permission structure instead of a fluid collaborative structure. Design owns UX. PM owns roadmap. Engineering owns feasibility. But no one owns coherence. So when you ask three people what the product does, you get three answers, not because they're confused. They're just staring at a Cubism painting and seeing different versions. Good for art, not so good for product development.
This coordination overhead was invisible when execution was slow. A multi-day cycle absorbed explanation time the way a river absorbs rain.
But when you can generate 20 screens in one sitting (ask Claude Design, they know what I do!). When engineers can scaffold code in minutes. When feedback cycles compress to five minutes. Suddenly the overhead becomes the bottleneck.
Speed didn't solve the problem. It compounded it.
Think of it like a kitchen during rush service. One order per hour, a chef can shout "Make the salmon!" and everyone knows which recipe. But during service when orders pile up, chefs are asking "the salmon from which order?" Tickets aren't overhead. They're the only way to coordinate at speed. Without them, the faster you try to move, the more chaos you create.
The Anatomy of Ontology (Machine and Human-Readable)
Here's what shared context actually looks like:
Section # | Letter = State
A financial platform:
1 = (Onboarding) | A, B, C...
2 = (Discovery) | A, B...
3 = (Purchasing) | F = (Payment Confirmation)
Humans read it instantly: "3F is Payment Confirmation within Purchasing."
Machines parse it reliably: structured, hierarchical, constraint-based.
The name encodes everything. What section. What state. What sequence. What variants exist. What's missing.
Now try coordinating:
Designer: "Redesign 3F"
PM: "User story for 3F: When the user completes 3F, they receive confirmation"
Engineer: "Generate the component for 3F per Design canvas, validate per business rules in user story"
Grammar agent: "Tighten copy on 3F confirmation message"
Teammate: "3F looks good, but update the error state variant"
I told you it was small and simple. Yet - No re-explaining. No screenshots. No "which one did you mean?" Every surface—Design, user story, Code prompt, review agent, team feedback—speaks the same language.
A shared naming system is like a shared language. You can have brilliant ideas in different languages, but until everyone's speaking the same one, you're just translating constantly. And translation is work.
The name is the address. The address is the shared context.
How Ontology Changes the PM <> Designer <> Code <> Agent Dynamic
The old way: hand off briefs and hope they survived translation.
Usually in product development, Designer gets a brief. Interprets it. Designs something. Hands it off to engineering. Engineering interprets the design. Builds something. Hands it to product. Product realizes that's not quite right.
Multiple translation layers. Multiple places for coherence to break.
With shared ontology, the flow changes:
X-shaped person (or Designer turned Product Owner / or Engineer turned Product Owner) architects structure upfront: "We need three sections. Purchasing has six states (A through F). Payment Confirmation is the critical path (F)."
Designer renders within that structure: "1A through 1C for Onboarding. 3F is where we focus visual hierarchy and reassurance."
Code generates from the same structure: "All components scaffold from the ontology. 3F validates against this rule set."
Agents operate within it: review agents check 3F against design spec, grammar agents tighten 3F copy, testing agents run 3F scenarios.
Team remixes only what's referenced: "Only update 3F states. Don't touch the rest of Purchasing yet."
What changed: instead of sequential handoffs, you get parallel thinking inside a shared frame. That Cubism painting? Turning into a Pointillism.
What This Means for Teams (Structural Implications)
Your team doesn't need more specialists deeper in their lanes. It needs architects who see across gaps.
Specialization worked when work moved slowly through functions. Hand off from PM to Designer to Engineer. Each person focused on their piece. Coordination happened at the handoff.
But when AI collapses execution time, the gaps between functions become the real problem. The coordination overhead explodes.
Instead, you need people who think across disciplines. Not generalists doing everything. Architects who understand how PM-thinking connects to Design-thinking connects to Code-thinking connects to how agents will operate on that code.
When the ontology is locked in (after first shaping round), parallel work becomes possible:
Designer works on 2C while you're thinking about 3F while engineers scaffold 1A while a code review agent validates 1B.
New teammate joins. They see the ontology. Section 1 is Onboarding (A, B, C states). Section 2 is Discovery (A, B). Section 3 is Purchasing (F is Payment Confirmation). They understand the architecture from naming alone. No weeks of context onboarding. Just: here's how we think about this product.
Feedback becomes atomic. Not "the whole thing feels off" (what does that even mean?). "3F needs denser hierarchy" or "2B copy is too long." Specific. Addressable. Actionable.
What This Means for Leadership
You're no longer coordinating specialists. You're enabling architects.
Your job shifts.
From: managing handoffs between functions. To: building shared understanding upfront.
Hiring shifts. You're not looking for people who are deeper in one lane. There's always a need for specialists. But these days, you're looking for people who think across disciplines. Who see how design decisions affect engineering velocity. Who understand how a user story maps to code. Who ask "what does the ontology tell us?" instead of "who has authority over this?"
Onboarding shifts. You don't hand someone a 40-page context document anymore. You hand them the ontology. Section 1 is X. Section 2 is Y. States are A through F. They can start contributing immediately because they understand the structure.
Decision-making shifts. Instead of "whose lane is this?" you ask "what does the ontology tell us about this?" The structure itself becomes the decision framework.
The real work moved upstream. It's not designing screens faster or writing code faster. It's defining ontology, establishing engineer context, redesigning workflow.
Leaders who recognize this shift hire for it, organize around it, protect it. Leaders who don't end up managing chaos—fast chaos, but chaos.
The Irony (and Why It Matters)
Here's what nobody expects:
Speed requires more upfront thinking, not less.
But different thinking. Architectural thinking that is machine and human-readable.
The theorem: stable ontology → shared context → fast iteration → real collaboration
Without ontology: re-explaining → coordination overhead → slower despite faster tools
With ontology: precision → parallelization → agents and humans thinking in sync
The bottleneck moved. It used to be execution. Now it's comprehension. And you can't accelerate comprehension the same way you accelerate generation.
But you can architect for it.
This is coherence made operational.
When you work across surfaces and disciplines—and every team does now—shared ontology isn't optional. It's the foundational infrastructure that makes distributed thinking possible.
And that infrastructure is a leadership responsibility.
Not a design system detail. Not a naming convention for designers. A strategic decision about how your team thinks, communicates, and makes sense of its own work.
The name is the address. Everything else follows.
Co-created with Claude.
This is Part 10 of an ongoing series on X-shaped people and the future of innovation teams. Read Part 1: The X-Shaped Individual: Solving for Problems in 3D and Part 2: It's Only Through Doing That You Become: How X-shaped people are made — and how teams can grow them and Part 3: Your Design System Isn't a Style Guide Anymore — It's AI Infrastructure and Part 4: How Do We Price Human Judgment When 5 Hours Turns Into 30 Minutes and Part 5: Architecting Adoption: How Design Systems Survive Like a Language and Part 6: When the Truth Isn't Absolute: Managing Variance Across Design, Code, and Docs and Part 7: We're Teaching AI to Read Context, then Forgot to Tell Each Other, Part 8: Pain is the MOAT, Part 9: Coherence as the Prerequisite for Good Thinking
Thu Do is a hands-on product owner with 10+ years bringing products from 0-to-1 across startups, Fortune 500 consultancies (BCG, PwC), and innovation studios. She helps early-stage to early-growth companies ($1-10M ARR) and innovation teams turn big visions into competitive market-ready products and services through human-centered design, product alignment, and AI innovation. This article originally appeared on Thu's Tech Dialect. Find her on LinkedIn.