The Unified Product Graph: Manifesto

The Thesis in One Paragraph

AI expanded what one person can produce. It did not expand what one person can hold in their head. Product knowledge sits in documents, where relationships are implied rather than declared, lifecycle lives in the author's memory, and traceability from evidence to shipped feature is usually missing. Retrieval-augmented generation and semantic search help AI find relevant prior text, but similarity is not the same as structure: decisions, relationships, lifecycle, and provenance cannot be retrieved reliably by similarity. They must be declared. The Unified Product Graph (UPG) is an open standard that declares them, as a typed graph with forward and reverse verb pairs and a portable .upg file format. Its central claim is simple: the missing layer in AI-assisted product creation is not more generation capability. It is structured memory. When product knowledge is declared rather than inferred, it compounds across sessions, roles, and tools instead of dissolving back into prose.

Part I. The Problem

The Production-Comprehension Gap

AI expanded what one person can produce. It did not expand what one person can hold in their head. We call this the production-comprehension gap: the widening distance between what AI enables a person to generate and what a person can actually reason about, connect, and act on coherently. As AI capabilities grow, this gap continues to widen.

The gap is less about AI capability than about how product knowledge is stored. A founder working alone can speed-draft dozens of artifacts in an afternoon: research notes, user flows, architecture sketches, feature specifications, pricing models. They may use different terms for each. Within a week, they have fifty of them. Soon after, they cannot remember which artifact connects to which pain point, which hypothesis was validated and which was abandoned, or whether the pricing model drafted earlier aligns with the positioning refined later. The artifacts exist. The agent reading them rarely knows the connections between them, and the founder rarely does either.

Documents, whether in Notion, Confluence, Google Docs, or markdown files, are containers for prose. They are not containers for relationships. Modern AI systems soften this limit: vector search, retrieval-augmented generation, and LLM-indexed wikis can surface the persona document when a question is asked about the feature. But similarity is not the same as structure. The connection between persona and feature still lives, implicitly, in the author's head. It is not declared anywhere a tool can reliably traverse, and that memory fades between sessions and does not transfer to the next person or agent on the project.

The cost is now structural, not stylistic. As building gets faster, decisions move upstream. Andrew Ng's claim that the product-to-engineering ratio is inverting may be extreme but is directionally correct: when code generation is cheap, the constraint shifts to what to build, and what to build requires faster access to context, not faster document generation. The PM toolkit was designed for a world where decisions happened weekly. In the AI-accelerated world, decisions happen hourly. The infrastructure has to keep up.

What is needed is structure for product work that persists across environments, and a framework-agnostic data model that retains what is true about the product as vocabularies and tools change around it.

AI expanded what one person can produce. It did not expand what one person can hold in their head.

Retrieval is not comprehension.

Speed without structure is chaos with better formatting.

Fragmented by Tool, Scattered by Convention

Product knowledge today lives across tools that each own a fragment of the picture. A typical team uses work trackers (Linear, Jira, Asana) for delivery, discovery platforms (Productboard, Vistaly) for opportunity trees, collaboration surfaces (Notion, Confluence, Miro, FigJam) for documents and whiteboards, design tools (Figma) for visual artifacts, and AI copilots (Notion AI, Linear AI, Figma AI, Cursor, Claude Code) running across every category. Each captures its own domain well. None captures the cross-domain relationships that hold product thinking together.

Each category solves its problem within its own scope and leaves a structural gap at its boundary.

• Work trackers. What it answers: What are we building? · What it does not answer: Why are we building it?
• Discovery platforms. What it answers: Why are we building it? · What it does not answer: Is it actually being built?
• Collaboration surfaces. What it answers: What has the team been thinking? · What it does not answer: What has the team decided, and how does it connect?
• Design tools. What it answers: What will it look like? · What it does not answer: What does it address, and why does it matter?
• AI copilots. What it answers: What can we generate next? · What it does not answer: How does it fit what already exists?

Before AI, a product team carried the cross-tool translation in their heads: they juggled the tools and held the connections between a feature in Linear, the persona in Notion that motivated it, the hypothesis in Miro that validated it, and the pricing tier in a spreadsheet that packaged it. That arrangement held while humans were the only ones producing product work. When AI agents generate artifacts at machine speed, the human-translation layer cannot keep up. Connections accumulate faster than any person can catalogue them.

The Model Context Protocol (MCP) changed the mechanics but not the problem. MCP servers let an AI agent pull from each of these tools directly, so retrieval is no longer the bottleneck. But retrieval is not comprehension. Documents pulled from Notion, issues pulled from Linear, and frames pulled from Figma do not describe themselves in compatible terms: every tool has its own schema, its own vocabulary, its own notion of what a "feature" or a "user" even is. Without a shared schema across tools, the information arrives in the agent's context window as parallel streams, not as a connected graph.

The same fragmentation is at work one layer up. Every framework that product people use (Opportunity Solution Trees, Business Model Canvas, Jobs-to-be-Done, Lean Canvas, growth loops, RICE) created its own tool, its own labels, its own silo. Pain Point in Lean Canvas is Need in Jobs-to-be-Done is Frustration in an empathy map is Friction in a funnel. The concepts overlap; the labels do not. A product person juggling four frameworks across four tools is juggling four vocabularies that do not interoperate.

The grassroots PM-AI ecosystem amplifies the same pattern. Hundreds of Claude skills, GPT templates, and custom workflows now exist for product work. Each one outputs a markdown document. Each one defines its own input format and its own output format. None know about the others. The treadmill has a terminal condition: bloat with decreasing coherence.

The cost is quantified. Employees switch between apps roughly 3,600 times per day; each switch costs minutes to fully regain context, and longer to regain deep focus. Knowledge workers spend close to 30% of their workday searching for information they already have. Fragmented systems erode trust: the persona in Notion says one thing, the segment in Amplitude says another, and the roadmap in Linear reflects neither. The product manager becomes the human API.

More generation, same fragmentation.

Each category solves its problem well within its own scope. What is missing, across the whole landscape, is a shared substrate that describes what a product is.

The intelligence does not compound. It fragments.

Part II. The Missing Layer

Structured Memory is the Missing Layer

At the root of the production-comprehension gap is a memory problem. Human working memory is limited to approximately 7 ± 2 chunks. Large language model context windows, while much larger, reset between sessions and degrade with the position of information within the window. Neither provides the persistent, structured, queryable memory that long-running product work requires.

A growing landscape of tools addresses memory at the seat level. Karpathy's LLM Wiki proposes an incrementally updated markdown collection that the model curates rather than retrieves over, so synthesis is stored once and re-used instead of re-derived every query. Graphify turns a repository of code, docs, and diagrams into a queryable knowledge graph for AI coding assistants. Claude-mem captures session observations in a local store and re-injects relevant context into the next Claude Code session. These are valuable where they sit, but each is scoped to one operator, one codebase, or one agent. Product work needs something different: a memory shared across people, agents, stakeholders, and time, independent of any single tool or installation. Structure that lives on one developer's machine is not structure the next collaborator, or the next agent, inherits.

Documents solve memory poorly. A document is a linear container for prose, which means it must be re-read to be used. The next AI session that needs information from a 1,500-word persona document must re-read the entire document, because the relationships inside it are not indexed as typed data. RAG and semantic search can surface the right document, but a retrieved document still has to be re-parsed, and the connections between artifacts remain implicit in prose rather than declared as traversable edges.

A typed graph solves memory differently. Every entity becomes a stable, referenceable record. A persona captured in week one has a stable identity, a defined shape, and declared relationships to the jobs, needs, and outcomes it connects to. In week ten, an AI agent retrieving that persona performs a single structured query rather than a document re-read. More importantly, every entity written during the intervening nine weeks is already connected to it. Output from yesterday's session becomes context for today's without re-contextualising, and without depending on any individual operator's local setup.

Compounding. A property of structured memory in which each new entity added to the graph does not merely sit alongside existing ones but actively connects to and extends them, so the queryable value of the graph grows faster than its storage cost.

The property is concrete. A persona captured in week one is referenced by three hypotheses written in week three, which are refuted by a research insight captured in week five, which motivates a feature shipped in week eight. In week ten, asking "what evidence supports this feature?" traverses four typed edges and returns the answer. No re-reading. No re-assembly. No drift. The graph gets denser with every session, and every new entity increases the number of questions the graph can answer. This is the opposite of document accumulation, where each new file is another thing to read from the top.

• 1. Without UPG: Three persona interviews land as three 1,500-word documents · With UPG: Three persona nodes linked to job and need nodes; each record fits on half a screen
• 3. Without UPG: New AI session has no memory; documents re-pasted in full · With UPG: list_nodes(type='persona') returns three structured records in one call
• 6. Without UPG: Hypothesis cross-check requires pasting documents again · With UPG: AI cross-checks against each persona's validated needs; flags tension with a specific need that contradicts the pricing assumption
• 10. Without UPG: Feature prioritisation requires an hour of re-reading to support a one-minute decision · With UPG: get_graph_digest() returns chain completeness per feature; twenty candidates rank themselves by evidence density

Each session in the left column starts from zero. Every session in the right column starts where the last one left off. The argument is not that UPG saves time on any one session. The argument is that UPG makes every session cheaper than the last.

This is the property that qualifies a structure as memory rather than storage. It is the property that the production-comprehension gap requires.

The field's strongest voices have circled the same conclusion without naming it at this layer. Marty Cagan argues we are entering a golden era of product discovery, while warning that AI amplifies whatever pattern a team is already in. Teresa Torres warns that AI summaries miss 20-40% of important detail; the detail most at risk is relational. John Cutler separates inherent complexity (understanding users, markets, strategy) from accidental complexity (bad tooling and fragmented information) and argues that infrastructure should erase the second so practitioners can spend their energy on the first. Andrew Ng and Lenny Rachitsky describe the bottleneck shift to product management itself.

Each of them sees the problem and proposes practice changes, mindset changes, and skills changes. None of them proposes a solution at the schema layer. UPG is the missing layer beneath the conversation that the thought leaders are already having.

The missing layer in AI-assisted product creation is not more generation capability. It is structured memory.

The graph is the memory that neither the human nor the AI alone naturally maintains.

Compounding is what qualifies a structure as memory rather than storage.

UPG makes every session cheaper than the last.

Declared, Not Inferred

If structured memory is the answer, the next question is what kind of structure. An AI agent given access to a corpus of product documents can do more than retrieve them: it can infer connections between them by re-reading prose at query time. Microsoft's GraphRAG demonstrates this at enterprise scale; LLM-assisted extractors do it on smaller corpora. The result is an emergent graph, assembled on demand from similarity and summarisation.

Emergent graphs work. The case for some structure is settled: graph-augmented benchmarks roughly triple LLM accuracy on schema-intensive questions, and GraphRAG reports comprehensiveness wins over flat retrieval. The case for which structure is not.

The distinction that matters is between emergent graphs and curated graphs.

Emergent graphs describe what a corpus contains. They read documents and surface the concepts mentioned, the entities named, and the soft associations between them. They are excellent for personal knowledge synthesis, exploratory reading, and retrieval over unstructured material. They reflect what you have written.

Curated graphs describe what a practitioner has decided. Entities are created deliberately, with known types, stable identifiers, typed edges, and lifecycle status. Edges carry verbs with direction. The graph does not reflect what you have written. It reflects what you have resolved, connected, and committed to building.

For product creation, five differences matter:

• **Absence.* Emergent graph: Surfaces corpus-level absence ("no documents discuss pricing") · Curated graph (UPG): Surfaces ontological absence: the entities the domain expects* but the graph does not have
• **Connections.* Emergent graph: Soft associations based on co-occurrence or similarity · Curated graph (UPG):* Named, typed edges (addresses, pursued_by, requires) traversable in either direction
• **Identity.* Emergent graph: Re-derived on each extraction; `node_42` this week may be `node_87` next · Curated graph (UPG):* Stable opaque IDs that survive sessions, tool changes, and schema evolution
• **Interchange.* Emergent graph: Each extraction reflects its source's vocabulary; two tools produce two incompatible graphs · Curated graph (UPG):* A common ontology so a Linear issue connects to a Figma component through a typed edge
• **Semantics.* Emergent graph: A `feature` is a label; a flat graph · Curated graph (UPG):* A feature carries a lifecycle, evidence requirements, and a traceability chain to user interviews

Emergent and curated graphs are not mutually exclusive. A team that writes extensively in Notion or Confluence can extract an emergent graph from its pages and still maintain a curated UPG of its product. The two structures answer different questions.

The wiki and the graph. The wiki holds what you know. The graph holds what you have decided, validated, connected, and committed to building. Ask the wiki "what have we been thinking about?" and it returns pages and paragraphs that mention the topic. Ask the graph "what have we decided to build, and what is its evidence?" and it returns typed entities connected by typed edges, traceable end to end. UPG is the second structure, because product work is the second question.

This is the move that separates a graph from a database with relations, a wiki with backlinks, or a vector store with embeddings. All three can show that things are nearby. Only a typed, curated graph can declare that one thing informs, refutes, addresses, or implements another. The verb is the meaning. The direction is the subject. The type carries the lifecycle and evidence requirements that an entity is expected to satisfy. Product work is a domain where certain entities call for others: every feature calls for a hypothesis; every hypothesis calls for evidence; every claim of impact calls for a metric. An emergent graph can see what is present. Only an ontology can see what is expected but missing.

Knowledge cannot compound when structure is only inferred at query time.

The wiki sees proximity; the graph sees connection.

Similarity is not structure.

An emergent graph is not a curated one.

Part III. The Substrate

Beneath, Not Within

Once the requirement is named (a curated graph, declared rather than inferred, shared across people and agents and time), the next question is where the graph lives. The answer is: not inside any one tool. UPG is designed to sit beneath the landscape rather than within it.

The distinction matters. Each category in §2 already has a leader, often several. Linear is excellent at issue tracking. Productboard is excellent at discovery. Figma is excellent at design. Notion is excellent at structured documents. None of them is in a position to become the canonical product ontology, because none of them was designed for that role and each has a commercial interest in keeping its own schema authoritative. The same was true of healthcare in 2012, when Epic, Cerner, and dozens of other electronic health record vendors each owned their own patient model. The fix was not a sixth vendor with a better schema. The fix was a shared resource standard beneath them all.

UPG follows that lineage.

• HTML. Year: 1993 · What it standardised: Document structure for the web · What it changed: Won by being the format every browser could read
• SQL. Year: 1986 · What it standardised: Relational data access · What it changed: Won by being the language every database spoke
• JSON. Year: 2001 · What it standardised: Data interchange · What it changed: Won by being the format every API could parse
• Schema.org. Year: 2011 · What it standardised: Web content vocabulary (800+ types) · What it changed: Reached 31.3% of all web pages within a few years, backed by competing search engines and a tangible incentive: rich search results
• OpenAPI. Year: 2011 · What it standardised: API contracts · What it changed: Became the universal language for REST API description
• FHIR. Year: 2014 · What it standardised: Healthcare resources (150+ types) · What it changed: 96% of US hospitals adopted FHIR-capable systems by 2025
• MCP. Year: 2024 · What it standardised: AI-agent tool access · What it changed: Made any MCP-capable client addressable from any MCP server
• UPG. Year: 2026 · What it standardised: Product knowledge ontology · What it changed: The product layer that the others left untouched

Each of these won by being the layer beneath, not the tool above. They succeeded because they were commons. Anyone could implement them. No vendor controlled the spec.

Product management is the only major discipline of this depth that does not yet have a shared data standard. The discipline is not too young: its core concepts (persona, opportunity, hypothesis, experiment, learning, outcome) have been stable for years. The books are written. The frameworks are established. What is missing is a machine-readable, relationship-rich, tool-agnostic way to represent those concepts together.

The arrival of MCP makes the timing not a coincidence. MCP solves the transport problem: how AI agents connect to data sources. It does not solve the vocabulary problem: what the data looks like within any specific domain. Think of MCP as the road network. Roads are only useful if the vehicles on them speak a common language. Right now, every PM tool that exposes an MCP server defines its own schema. Productboard's MCP server speaks Productboard. Dovetail's speaks Dovetail. They share the road and speak different languages.

UPG is what they can all reference. The specification's primary read/write interface is the UPG MCP server. A companion cloud server does the same over a remote graph for teams that want a shared store rather than a local file. Any MCP-capable client (Claude Code, Cursor, Zed, Continue, a custom in-house agent) reads and writes product graphs without bespoke integration. The agent's side of the contract is the MCP tool list; UPG's side is the graph operations those tools map to.

The trade is acceptance. By building on MCP rather than a proprietary API, UPG inherits the protocol's reach and its constraints. For the current AI-agent landscape, that trade is clearly the right direction: MCP is becoming the default way agents reach out into the world, and UPG is designed to be reachable.

UPG is substrate, not another tool.

Tools are transient; the knowledge they capture should not be.

MCP is the road network. UPG is the language the vehicles speak.

Product management is the only major discipline of this depth without a shared data standard.

Frameworks as Views, Extensions Without Forking

Two questions remain. How does one substrate accommodate the dozens of frameworks practitioners already use? And how does it grow into new domains without forking the schema or breaking the graphs already in circulation?

Frameworks render the same graph differently

Every discipline brings frameworks, and every framework brings its own vocabulary. Product management uses Opportunity Solution Trees, Jobs-to-be-Done, Lean Canvas, and the Business Model Canvas. Design uses empathy maps, user journey maps, and design-thinking stages. Engineering uses domain-driven design, the C4 model, and architecture decision records. Growth uses funnels, loops, and aha-moment frameworks. Each is a trusted method for thinking about part of the product, and each brings real clarity within its own domain. The collisions appear where they describe the same thing under different names.

• The user. Product management: Persona, Buyer · Design: User archetype · Engineering: Actor · Growth: Segment, Cohort · UPG canonical type: persona
• Unmet user state. Product management: Pain Point, Need · Design: Frustration, Pain · Growth: Friction · UPG canonical type: need (with valence: pain / gap / constraint)
• Discovery-level bet. Product management: Opportunity, Bet · Design: Design question · Growth: Growth bet, Experiment hypothesis · UPG canonical type: opportunity
• Strategic goal. Product management: Outcome (OKR), Objective · Design: Journey goal · Engineering: SLO · Growth: North Star Metric · UPG canonical type: outcome
• Thing to build. Product management: Feature, Solution · Design: Design, Flow · Engineering: Service, Component, Module · Growth: Experiment · UPG canonical type: feature
• Evidence for a claim. Product management: Validated Learning, Insight · Design: Research finding, Usability observation · Engineering: Telemetry signal · Growth: Experiment result · UPG canonical type: insight (research) / learning (experiment)

One response to these collisions is to give each framework its own schema and translate between them as needed. That is the practice today, and it is why moving between tools costs so much human-mediated translation. UPG takes a different response.

In UPG, frameworks are view definitions over a canonical graph. The underlying data is framework-agnostic: whatever the practitioner's framework calls it, the entity lands in the graph as a need with a declared valence, or as a feature regardless of whether a Lean Canvas calls it a Solution. The presentation is framework-fluent: the same need with valence: pain renders as Pain Point in a Lean Canvas view, as Frustration in an empathy-map view, and as Friction in a funnel view.

The same value_proposition node appears in the Business Model Canvas as Value Proposition and in the Lean Canvas as Unique Value Proposition. Editing the entity in any view edits the underlying record everywhere. Framework choice becomes a presentation-layer question rather than a data-modelling one. A team that adopts Lean Canvas for two years and wants to move to Jobs-to-be-Done only changes their framework view. The data is untouched.

This is the move that lets a single UPG graph describe a product across all the disciplines that touch it. *The graph is what a product is. The frameworks are how different people choose to read it.* The two are not in tension; they are layered.

The 2027 test is the load-bearing version of this claim. When the next framework emerges (and one always does), teams using UPG do not migrate data. They add a view definition. Their history persists. The new framework is a new lens on existing knowledge, not a new starting point.

Extension Without Fragmentation

The same move applies one layer down. UPG covers the full arc of product creation today, from research insights and personas through to architectural decisions and growth experiments. New domains will appear: healthcare product work, regulatory product work, developer-relations product work, climate-tech product work. The architecture has to accommodate them without forking the spec or breaking the graphs already in circulation.

UPG's domain architecture is region and atomic domain, not core and extended. The earlier "twenty core, two-hundred-and-eighty-four extended" framing has been superseded. The current model is structural:

• Atomic domains are the graph's subject headings (user, strategy, discovery, engineering, growth, market intelligence, design, and others). At v0.4 the registry holds 36 of them, and each entity type carries an immutable domain assignment.
• Regions roll the atomic domains up into ten super-domains: Strategy & Outcomes, Users & Needs, Discovery / Research / Validation, Market & Competitive, Experience / Design / Brand, Product & Delivery, Engineering & Platform, Business / GTM / Growth, Analytics & Data, Operations & Quality. Each region carries an anchor entity (the type that carries the region's design problem most sharply), a shape archetype (cascade, convergent hub, cyclic processing graph, layered DAG, layered mesh, cyclic value-exchange, event-driven collage), and boundary edges that fix how the region connects to its neighbours.

The architecture is what makes extension safe.

A healthcare product team adds a new atomic domain (clinical_outcomes, say) with its own entity types: clinical_outcome, compliance_requirement, patient_journey. The new types declare which existing region they roll up into (likely Users & Needs and Operations & Quality), and they connect to existing types through registered cross-domain edges. The catalog grows. No existing entity type changes. No graph in circulation breaks.

A fintech team adds a regulatory domain. Same pattern.

An open-source contributor builds a developer_relations domain with community_engagement, contribution_funnel, and developer_persona. Same pattern.

Each extension enriches the graph by addition. The wire format is stable: every type carries an immutable type_id that survives renames, merges, and deprecations. When pain_point was folded into need with a valence: pain property, the old type_id was preserved, so existing .upg files auto-migrate on load without data loss.

This is how successful standards have always scaled. HTML grew by adding new elements with the same parsing rules. Schema.org grew by adding new types with the same structured-data format. FHIR grew by adding new resources with the same REST patterns. UPG grows the same way: new domains plug into existing regions, or new regions plug into the framework, but the foundation does not move.

Beneath all of it is portability. A product graph is a single .upg file (JSON, or its human-readable serialisation in UPG Markdown). It is versionable in git, diffable between revisions, transferable between tools, and feedable to any AI agent as structured context. The file travels with the product, not with the vendor that happens to be hosting it this year. Export from one tool and import into another, and the relationships survive. The personas still connect to the jobs, the jobs still connect to the opportunities, the opportunities still connect to the experiments. The graph travels with you.

The graph is what a product is. The frameworks are how different people choose to read it. The two are not in tension; they are layered.

Edit the entity in any view, and you have edited it everywhere.

The standard grows by addition. The foundation holds.

Your product graph is yours. The file travels with the product, not with the vendor.

Closing Call

Product work needs a foundation that outlasts any single tool. The tools we use today will be replaced. The vocabularies will keep diverging. The frameworks will keep multiplying. AI capability will keep accelerating, and with it, the production-comprehension gap will keep widening if nothing structural changes.

UPG is the structural change. An open standard, MIT-licensed, MCP-native, layered for incremental adoption, portable as a plain file, and shaped by product work rather than by the open web. The thesis is the same in any audience:

The missing layer in AI-assisted product creation is not more generation capability. It is structured memory. When product knowledge is declared rather than inferred, it compounds across sessions, roles, and tools instead of dissolving back into prose. The graph is the memory that neither the human nor the AI alone naturally maintains.

The substrate is here. The tools that read and write it are here. The next move belongs to the people who build products.