Product Operations Needs a Knowledge Graph: Reading Perri and Tilles' Three Pillars Through a Graph Lens

Melissa Perri and Denise Tilles' Product Operations: How successful companies build better products at scale (2023) is the most rigorous treatment we have of what Product Operations actually is and why it became a function.[1] Their central frame is what they call the Three Pillars: Business Data & Insights, Customer & Market Insights, and Process & Practices. If you run Product Ops, you've probably read it; if you haven't, the book makes a strong argument that this is the operating system of a scaling product organization.

This post is an argument that the Three Pillars are not just an organizational framework. Each one is structurally a graph problem. And the reason Product Ops teams keep getting stuck at the same growth ceiling is that the infrastructure they're given to execute on the pillars — a Productboard, a Pendo, a Jira, a Salesforce, a Slack — is a set of disconnected nodes with no edges between them.

The Three Pillars are an organizational framework. They're also, all three of them, structurally graph problems. That's why Product Ops teams stall when their tooling is a collection of disconnected applications.

The Three Pillars, briefly

For readers who haven't read Perri & Tilles, the very short version:[1]

• Business Data & Insights: the quantitative inputs · usage, revenue, and performance data · collected, normalized, and made available so product teams can make evidence-based decisions.
• Customer & Market Insights: customer research, feedback, and market and competitive analysis, brought to product teams in a form they can act on.
• Process & Practices: the standardized rituals, templates, and decision frameworks that let product teams operate consistently across the org. The bits a new PM can pick up on day one and ship in week two.

The book's thesis, paraphrased: when these three pillars are healthy, product teams move faster and with more strategic clarity. When they aren't — which is most of the time — you get the symptoms Perri previously catalogued in Escaping the Build Trap: feature factories, and teams measured on what they ship rather than the value it creates.[4]

Pillars 1 and 2: The insight pillars are a graph problem

The insight pillars start from a familiar failure pattern: the company has product analytics, it has customer feedback, it has sales pipeline data, it has market intelligence · and none of these data sets talk to each other.[1] Product Ops is brought in to fix this, and the first 90 days of any new Product Ops hire usually involves some version of building a manual bridge between Pendo, Salesforce, Productboard, Klue, and Confluence.

The bridge breaks. The bridge is always breaking. Why?

Because the systems share the same things · customers, products, features, competitors, requests · but they don't share identifiers for those things. A “feature request” in Productboard is a different identity than a “capability gap” in a Klue battlecard, which is a different identity than a sales-call note in Gong, which is a different identity than a Pendo NPS comment. A Product Ops analyst spends their time being the human entity-resolution layer.

That stitching is time product managers are not spending on product decisions. Years of investment in product-analytics platforms haven't removed it, because the platforms are nodes, not edges.

What “democratized data” actually requires

The goal of the data pillar is that every product team can answer its own questions without filing a ticket with the data team.[1] That goal requires three things, all of which a knowledge graph provides:

• A consistent node model so a question about "our top-50 strategic accounts" returns the same 50 accounts in every tool.
• A set of relationships that connect nodes (account → request → feature → competitor → release).
• A query interface that lets a non-technical PM ask a multi-hop question and get a correct, cited answer.

Those three things are the definition of a knowledge graph plus a graph-grounded copilot. Microsoft's GraphRAG research shows graph-based retrieval producing more comprehensive answers than vector search on corpus-wide questions: an LLM judge preferred them in 72-83% of head-to-head comparisons.[3]

Pillar 3: Process & Practices needs a shared substrate

The Process & Practices pillar is about consistency: the same intake form for every feature request, the same prioritization framework for every roadmap call, the same template for every PRD. But process without infrastructure is just paperwork · a PRD template that nobody fills in because filling it in takes too long, a prioritization framework that nobody applies because the inputs aren't available.

Take a representative example. A standard prioritization framework like RICE (Reach, Impact, Confidence, Effort) asks four questions every product team is supposed to answer for every roadmap candidate. In practice, the answers come from:

• Reach → product analytics (Pendo, Mixpanel) plus customer-success notes
• Impact → segmentation data plus pipeline pressure plus competitive context
• Confidence → experiment results, qualitative customer interviews, market signals
• Effort → engineering estimates from Jira, Linear, or the team lead's intuition

That's four traversals across five systems. Without a graph, RICE becomes a vibes-based exercise because the cost of getting the actual inputs exceeds the value of the framework. Product Ops teams know this; it's why so many of them quietly abandon RICE and reach for something scrappier.

With a graph, RICE works the way it's supposed to. The same query that returns "14 strategic accounts requested feature X" also returns the Reach number. The Impact number comes from the same graph, joining to revenue and segmentation data. The Confidence number traverses to experiment results and signals. Process & Practices stops being aspirational documentation and starts being muscle memory.

Process without infrastructure is paperwork. The reason most prioritization frameworks die quietly in Product Ops orgs is that gathering the inputs costs more than the framework returns.

Strategy is the most graph-shaped problem

Above the three pillars sits strategy: OKRs that ladder to bets, portfolio choices that reflect actual market position, and leadership conversations grounded in shared evidence. It is the work that breaks first and hardest at scale.

At a 50-PM organization with 12 product lines, the questions the strategy team needs to answer regularly include:

• Across all 12 product lines, where are we losing deals — and is the reason concentrated in a specific capability gap that multiple teams could fill if they coordinated?
• Which 3 competitors are showing the most release velocity in our top 5 categories, and which of our product lines is most exposed?
• Of the 200 capability requests in our Productboard across all product lines, which 20 would unblock the most strategic-account revenue if shipped this quarter?
• Are our OKRs actually pointed at the categories where the market is growing fastest — or at the categories where the leadership team feels comfortable?

Every one of those is a multi-hop question across product, market, competitor, and revenue nodes. Without a graph, the answers come from a quarterly slide deck that takes weeks to assemble and is already stale by the time it's presented. With a graph, the answers come from a query that runs in seconds and can be re-run any time leadership changes the question.

What a graph-grounded Product Ops org actually looks like

Day 1 of a new PM

The new PM joins. Product Ops onboards them not with a tour of seven different SaaS dashboards, but with a single workspace where they can ask: “What are the top 5 capability requests for the product I'm about to own, ranked by strategic-account revenue impact, with citations to the underlying customer conversations and the competitor releases on the same theme?”

That's a graph query. It used to take a senior PM days of digging to answer; on a graph it is one question.

Quarterly business review

The strategy team prepares the QBR not by manually building slides from seven systems but by running a standard query set against the graph. The output is automatically cited — every claim about category growth, competitor moves, or capability gaps links back to the underlying node in the graph. Leadership stops arguing about the numbers because the numbers come with provenance.

Cross-team coordination

Two product lines independently propose capability X for the quarter. The graph catches this at intake because both proposals reference the same capability node. Product Ops notices, surfaces it, and coordinates a single build that serves both product lines. The duplication is caught before the work starts · not at the end of the quarter when both teams realize they've shipped overlapping functionality.

Where to go from here

If you run Product Ops, the question to take to the next leadership offsite isn't “should we build a knowledge graph?”. It's “how mature is each of the Three Pillars in our org, and which one will hit the wall first if we don't build the substrate?”

In our experience, the data pillar hits the wall first, because cross-system entity resolution becomes the bottleneck before the other pillars get a chance to break. That's the pillar where graph grounding pays back fastest.