Product Operations Needs a Knowledge Graph: Reading Melissa Perri's Three Pillars Through a Graph Lens

Melissa Perri and Denise Tilles' Product Operations: How successful companies build better products at scale (2024) 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: Data & Insights, Process & Practices, and Strategic Operations. 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 any product organization above about 30 PMs.

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]

• Data & Insights: collecting, normalizing, and democratizing the data product teams need to make evidence-based decisions. Pulls together customer feedback, usage analytics, market signals, and competitive intelligence into shared, queryable surfaces.
• 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.
• Strategic Operations: connecting product strategy to execution at scale — OKRs, portfolio prioritization, leadership alignment, the work that keeps the company's product bets coherent.

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, fragmented data, strategic drift.[8]

Forrester's 2024 numbers tell us how far the function has spread and how unevenly it's succeeding:

Pillar 1: Data & Insights is a graph problem

Perri and Tilles open the Data & Insights pillar with a specific 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 entities — customers, products, features, competitors, requests — but they don't share identifiers for those entities. A “feature request” in Productboard is a different identity than a “capability gap” in a Klue battle card, 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.

The Mind the Product / Pendo benchmarks put a number on this: a median PM spends 33% of working time on the cross-system stitching that Product Ops is supposed to eliminate.[4] The number has been flat since 2021. Four years of investment in product-analytics platforms haven't moved the dial because the platforms are nodes, not edges.

What “democratized data” actually requires

Perri and Tilles repeatedly use the word democratized when describing what Data & Insights should produce: every product team should be able to answer their 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 entity model so a question about "our top-50 strategic accounts" returns the same 50 accounts in every tool.
• A set of relationships that connect entities (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. The Microsoft GraphRAG benchmarks suggest the "multi-hop question with cited answer" piece is now technically feasible at the 70-80% accuracy level on global questions, which is past the threshold of useful for most product decisions.[6]

Pillar 2: 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. Perri and Tilles emphasize that 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 within 18 months 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 competitive 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.

Pillar 3: Strategic Operations is the most graph-shaped problem

Of the three pillars, Strategic Operations is the one that breaks first and hardest at scale. Perri and Tilles describe it as connecting product strategy to execution — OKRs that ladder to bets, portfolio choices that reflect actual market position, leadership conversations grounded in shared evidence.[1]

At a 50-PM organization with 12 product lines, the questions Strategic Operations 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 entities. Without a graph, the answers come from a quarterly slide deck that takes the Strategic Ops team three weeks to assemble and is 60% 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 the research suggests about graph-grounded Product Ops

The three research lines we've been tracking all point the same direction:

McKinsey: top quartile vs bottom quartile in product orgs

McKinsey's March 2025 State of AI study found that product organizations using AI in roadmap and prioritization workflows split into two clear groups: those grounding the AI in some form of knowledge graph (top quartile, 20-50% time-to-market improvement) and those running ungrounded LLMs against documents (bottom quartile, no measurable gain).[7] The grounded group is doing what Perri and Tilles would describe as Data & Insights done well.

Forrester: knowledge management reduces rework 25-32%

Forrester's 2023 TEI study on enterprise knowledge management found 25-32% reduction in development rework and 16-24% reduction in time-to-merge for cross-team PRs.[9] Product Ops is, in many ways, knowledge management for the product organization; the same mechanism applies.

IDC: 28% less product-development rework with mature KG

IDC's 2024 Worldwide AI for Enterprise Software Spending Guide reported that companies with mature knowledge-graph infrastructure see 28% less product-development rework than peers without it.[10] The mechanism is exactly the discovery problem Perri and Tilles describe: fewer features built that duplicate existing capability, fewer roadmap items deprioritized mid-quarter because of a signal that should have been caught at intake.

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 two weeks to answer. Now it takes the new PM 90 seconds.

Quarterly business review

The Strategic Ops 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 entity 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 entity. 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 “what's the Three Pillars maturity score of our org, and which pillar will hit the wall first if we don't build the substrate?”

For most organizations Perri and Tilles describe, the answer is Data & Insights hits the wall first — because cross-system entity resolution becomes the bottleneck before the other pillars even get a chance to break. That's the pillar where graph grounding pays back fastest, which is why subscribing to a productionized market graph has become the most-leveraged Product Ops investment a $100M-$1B revenue software company can make in 2026.

Next post: The Account Intelligence Problem — What Competitive Intelligence Teams Actually Need from a Knowledge Graph.