Knowledge graphs as a product

TL;DR

The capstone question is never "should we have a knowledge graph?" It's "which product bets get cheaper, better, or possible if our knowledge were connected, and what does that cost end to end?" Run it like any platform investment, with three honest numbers. Cost is dominated by construction and curation, forever — storage is a rounding error. Value comes only from features shipped on top; the graph itself earns nothing. Compounding means each new domain makes every previous domain more valuable. That's the property that separates graphs from ordinary data projects, if you sequence for it. The playbook that survives contact: start with one killer query in one domain, ship a visible feature in a quarter or two, and let each win fund the next domain. Treat the ontology-plus-curated-graph as the moat — competitors can buy your database vendor tomorrow, but they can't buy your resolved entities or the organizational agreement encoded in your ontology. Hold the honest exit too: if the questions are single-hop, the domain fits one system, or nobody owns curation, the right call is no — written down, with the trigger that would reopen it.

🎯 For the product leader

Why it matters — This is the lesson where the other seven become a budget line and a roadmap. Knowledge graphs fail at the portfolio level far more often than the technical level. They get funded as infrastructure with no feature attached, or starved as a side quest when the compounding needed patience.

What it changes in your decisions — The graph never appears on your roadmap as itself; only features do, each carrying its slice of graph cost. Sequencing changes too. Domain order is chosen for adjacency — shared entities with the last domain — not for whichever VP shouted loudest.

Ask yourself — "What's the first feature, in which quarter, that a user will notice — and does each next domain reuse entities the graph already resolved?"

Risk if ignored — The two canonical deaths: the platform mirage — two years of foundation-building, zero shipped features, budget yanked at the first CFO review — and the pilot orphan: a great demo nobody funded to steady state, decaying into the quiet death.

The business case, in three honest numbers

Cost — construction dominates, forever. The end-to-end shape: pipeline and extraction engineering, entity-resolution tuning, permanent curation staffing, ontology stewardship, plus the smallest line — storage and compute. LLMs repriced extraction meaningfully, but they moved the construction share of budget from perhaps 80% to 60-70%. They reduce the steady-state curation tail only somewhat, since LLM-drafted facts increase review volume. Any business case whose cost model is mostly database licensing was written by the database vendor.

Value — features, attributed honestly. The graph monetizes only through what ships on top: the fraud feature's loss reduction, the assistant's deflection rate, the 360-view's expansion revenue, the risk dashboard's audit pass. Attribute each feature's graph-share the same way you'd attribute model cost per feature. Without that discipline, the graph is unfundable at every budget review and indispensable in every architecture diagram, simultaneously.

Compounding — the strategic argument, with a condition. Domain two reuses domain one's resolved customers. The supplier domain connects to both. Each addition raises the value of every prior query. That's the moat logic — the curated, resolved, agreed-upon graph is expensive to replicate because your competitor must redo the organizational work, not just the software. But compounding only happens if domains are chosen adjacent (shared entities) and quality holds (trust, once lost, un-compounds faster than it built).

The sequencing playbook

The loop deserves three annotations. Ship inside an existing surface. The first graph feature should improve a screen people already use (the account view gains "supply-chain exposure"), not launch a "graph explorer" destination nobody visits. Graphs are middleware, and middleware wins by disappearing. A quarter or two, not a year. If the first visible feature is further out, the scope is wrong, not the timeline. The loop is also the org design. Each turn adds a domain steward and expands the governance cast. The team grows with proven value, never ahead of it. Prioritize the queue like any other roadmap under constraint — the graph earns no exemption from ROI ordering.

Build, buy, and the LLM-only challenge

In practice the answer is a seam, not a box. Build the differentiating core; buy the commodity edges (external identifiers double as resolution anchors). Let the measured failures of LLM-only retrieval tell you when the graph investment turns on. The strategic instinct is the same one behind every build-vs-buy call: own what differentiates, rent what doesn't.

When the answer is no

Say no crisply when: the valuable questions are single-hop (a good schema wins), the domain fits one system of record (the connective layer connects nothing), the knowledge changes faster than curation can follow (the graph would always lie), nobody will own stewardship (an orphaned graph is a liability with a dashboard), or the honest goal is "AI strategy" optics (a graph built for the board deck dies the quarter attention moves). A written no — with the trigger that reopens it ("when support tickets require joining three systems," "when the assistant's multi-hop failure rate crosses X") — is a strategy artifact worth as much as a build.

Failure modes

• The platform mirage — "first we build the foundation, then the features." The foundation takes two years. The features never arrive. The budget dies at review.
• The pilot orphan — a demo that wowed, funded as a project not a product. No steady state, no steward, quiet death by staleness.
• Non-adjacent domain hopping — each new domain chosen politically, sharing no entities with the last. Costs stack linearly; value doesn't compound.
• The unattributed platform — no feature carries graph cost, so the graph looks free until it looks expensive. The first budget squeeze kills it.
• Moat mistaken for database — believing the store is the asset. The actual moat — resolved identities, agreed ontology, curation muscle — goes unfunded.
• No written no — the graph idea returns every planning cycle, burns a discovery spike each time, and is never either built or buried.

Practitioner checklist

• Is the first visible feature named, scoped to one killer query, and landing inside an existing surface within two quarters?
• Does the cost model show construction + permanent curation as the dominant lines — and does steady state survive the pilot team's departure?
• Is every subsequent domain adjacent — reusing entities the graph already resolved — and does the value narrative show compounding, not stacking?
• Does each graph-backed feature carry its attributed share of graph cost through budget reviews?
• Is the build/buy seam explicit: differentiating core built, commodity knowledge bought, LLM-only baseline measured before each escalation?
• If the answer is no: is it written, with the reopening trigger — and if yes: can I defend the moat in one sentence that doesn't mention a database?

Related lessons

• What is a knowledge graph? — the killer-query test this capstone operationalizes.
• Governance, quality & trust — the steady state the business case must fund.
• Prioritization & roadmaps — the portfolio discipline the sequencing loop plugs into.
• Product sense for AI products — the judgment for pricing and positioning what the company knows as a product.