Ask any product manager what their product looks like, and they’ll probably open a roadmap, a Jira board, or a Notion page. These tools answer one question well: what work are we doing?
But there’s a different question that’s harder to answer: what is the product?
Not what you’re building next. Not what tickets are in flight. What does the product actually consist of — the features, the rules, the user needs, the flows, the actors, the constraints — and how do all of those things relate to each other?
Most teams can’t answer this clearly. That’s a problem. And it’s the problem that semantic graphs are built to solve.
The Limits of Ticket-Centric Thinking
Tickets are a work management primitive. They describe discrete tasks, assign them to people, and track their completion. This is useful — teams need to coordinate execution.
But tickets describe changes to a product, not the product itself. Once a ticket is closed, it’s done. The product has moved on. The ticket is just history.
The result is that your product’s current state is only ever implied. It’s the accumulated sum of thousands of closed tickets, filtered through whatever docs someone wrote at the time, minus anything that was quietly changed without a corresponding update.
You can’t query your product. You can’t ask “which features depend on the user being logged in?” or “what flows break if we remove this concept?” You can’t see whether two features contradict each other. You can’t trace a user need all the way through to the metrics that measure it.
Because your product isn’t a thing you can see. It’s a residue of work.
What a Semantic Graph Looks Like
A semantic graph is a structured representation of your product as a network of typed nodes and typed relationships.
Nodes have types: Feature, Need, Rule, Flow, Actor, Metric, Component, and more. Each type has a defined schema — the properties it must have, the invariants it must satisfy.
Relationships are also typed: a Feature addresses a Need. A Flow requires an Actor. A Rule constrains a Feature. These aren’t freeform tags or custom fields — they’re ontological relationships that carry semantic meaning.
The result is a product model that’s explicit, traversable, and validatable. You can ask the graph questions:
- Which user needs are currently unaddressed by any feature?
- What features would be affected if we change this business rule?
- Which flows involve a payment step?
- What does the product look like from the perspective of an unauthenticated user?
These aren’t questions you can answer with a Jira board. They’re questions a graph can answer in milliseconds.
Dependencies Become First-Class Citizens
One of the most powerful things about a semantic graph is what it does to dependency reasoning.
In ticket-centric thinking, dependencies are manually declared: “this ticket blocks that one.” It’s an honor system. People add dependencies when they remember, miss them when they don’t, and the graph of dependencies is usually wildly incomplete.
In a semantic graph, dependencies are structural. If a feature addresses a need, that relationship exists because someone modeled it — not because someone remembered to add a blocking link. If a flow requires a specific rule to be in place, that constraint is expressed in the graph, not in a comment in a ticket.
This means that when something changes, the impact is traceable. Remove a concept and the graph shows you every feature that references it. Modify a rule and the graph flags every flow that depends on it. Add a new actor and the graph can surface which existing flows might need to accommodate them.
Dependency visibility isn’t a feature you add on top of a ticket board. It emerges naturally from a structured product model.
The Ontology Question
To model your product as a graph, you need an ontology: a vocabulary of node types and relationship types that applies to all products, or to your product specifically.
This sounds daunting, but most products have a surprisingly consistent underlying structure. There are features. There are users (actors). There are needs those users have. There are flows that users traverse. There are rules that constrain behavior. There are metrics that measure outcomes.
A fixed ontology isn’t a cage — it’s a shared language. Once your whole team speaks the same product vocabulary, conversations get cleaner. “This feature addresses the need for social proof” is a different — and more useful — statement than “we should add reviews somewhere.”
The ontology makes implicit product knowledge explicit. And explicit knowledge is the only kind that survives team changes, org restructuring, and time.
What This Means for AI
There’s a practical reason why semantic graphs matter even more now: AI agents need to understand your product to help you with it.
When an AI assistant helps an engineer write code, the ideal scenario is that it understands not just the codebase, but the product the codebase implements. What features exist. What rules constrain them. What user needs drive them.
A flat PRD document is too ambiguous for an AI to reason about precisely. A semantic graph is structured, typed, and queryable — exactly the kind of input that AI reasoning works well with.
This is why Specor exposes the product graph via the Model Context Protocol: so that AI coding assistants can query the product model before generating code, and do so with the same precision a human expert would bring.
The Shift Is Conceptual, Not Just Technical
Moving from tickets to graphs doesn’t require throwing out your Jira board. It requires a change in what you consider the primary artifact.
Tickets are ephemeral. They represent work in progress. Once closed, they’re history.
The product model is permanent. It represents what the product is. It grows and evolves, but it never closes.
Building this as an explicit, versioned artifact — not a document, not a board, but a structured graph — is the shift. Everything else follows from that. Once your product has this structure, you can apply Git-style version control to it — branching, committing, and merging product definitions the same way engineers handle code.