Why Product Roadmaps Miss, and How a Knowledge Graph Closes the Gap

In a 2023 Product Ops HQ survey, fewer than 9% of product teams and stakeholders said they were confident they could deliver their roadmap commitments, and 95% said they had to change the plan materially during the quarter.[1]

The reflex explanation is that PMs are bad at estimation, or that engineering blocks happen, or that priorities shift in response to customer demands. All true. But none of those explanations are getting better, and in our experience they get worse with one variable: the number of disconnected data systems the product organization touches to make a single decision.

Roadmaps don't fail because PMs can't prioritize. They fail because the inputs to prioritization sit in seven disconnected systems.

This post is about why that's a graph problem, what the research says about grounding decisions and AI in graphs, and what a typical enterprise PM workflow looks like when the inputs to a decision actually traverse.

Section 1: The seven-system problem

A typical B2B SaaS Product Manager at a $100M-$1B-revenue company runs the following inputs through their head before any roadmap commit:

• Customer feedback signals from Pendo, Mixpanel, or Amplitude — usage patterns, drop-off points, feature requests.
• Sales pipeline pressure from Salesforce or HubSpot · what deals are blocked by what missing capabilities.
• Competitive moves from Klue, Crayon, or a homegrown email digest — what shipped this week across 50+ adjacent vendors.
• Engineering capacity from Jira, Linear, or GitHub — what's actually buildable in the cycle.
• Strategic positioning from a quarterly board deck — where leadership thinks the market is going.
• Compliance and security constraints from a separate doc no one has updated since the last SOC 2 cycle.
• Cross-team dependencies from Confluence, Notion, or Slack — who else is touching the same code path.

Most product organizations are doing a version of the seven-system dance, mostly with spreadsheets and tribal knowledge as glue.

The cost shows up as PM time spent gathering data and chasing status instead of deciding. Years of investment in product analytics tools, project trackers, and feedback platforms haven't fixed this. The reason is that those tools are nodes, not edges.

Section 2: Why this is structurally a graph problem

The reason a PM can't answer "should we ship feature X this quarter?" in under 30 minutes isn't that the data is missing. It's that the relationships between the data points aren't modeled anywhere.

Consider the question: “How many of our top-50 strategic accounts have requested capability X in the past 90 days, and which of those accounts are also using a competitor that already ships it?”

To answer that, you need to traverse:

• Account list → CRM (Salesforce)
• Account list → “strategic” tier definition (a custom field in CRM that maps to a separate Notion doc)
• Capability X requests → Productboard, Pendo NPS comments, Slack #feedback, Zendesk tickets
• Competitor capability check → Klue battlecard (last updated 6 weeks ago), or G2 comparison pages
• Cross-join the four → a spreadsheet, manually

That's a four-hop traversal across four storage systems with no shared identifier. In graph theory terms, you don't have a graph — you have four disconnected components. Joining them is the work.

This isn't a new idea. It's the foundational vision behind Tim Berners-Lee's Linked Data work at the W3C,[7] and LinkedIn has run one in production since at least 2016, for search, recommendations and analytics.[6] What changed in the last 18 months is that the cost of building one of these graphs for a domain — like “every enterprise software vendor and product” — finally crossed below the cost of not building one.

Section 3: What the research says

The hard data on knowledge graphs improving product outcomes is thinner than it should be — partly because the deployments that work tend to be inside companies that don't publish benchmarks. But what's public points the same way:

McKinsey: redesigning the work matters more than adding AI

McKinsey's March 2025 State of AI survey of 1,491 participants found that redesigning workflows is the change most linked to bottom-line impact from gen AI, yet only 21% of organizations using gen AI had redesigned any workflows.[2] Our read: putting the inputs to a product decision into one connected graph is exactly that kind of redesign.

Microsoft Research: GraphRAG wins most head-to-head comparisons on global questions

The most rigorous recent benchmark is Microsoft Research's GraphRAG paper (Edge et al., April 2024, a preprint), which compared graph-grounded retrieval with standard vector retrieval on "global" questions over two corpora of about a million tokens each: podcast transcripts and news articles.[3] Global questions are the whole-dataset sensemaking that product orgs actually need (e.g., "which features appear across customer-facing complaints AND competitor releases AND strategic-account requests?"). On those questions, GraphRAG's answers won 72-83% of head-to-head comparisons on comprehensiveness, with an LLM, not a human, as the judge.

This matters because much of the enterprise AI stack still relies on vector retrieval alone.

Gartner: Knowledge graphs are now on the Slope of Enlightenment

Gartner's 2024 Hype Cycle for Artificial Intelligence placed knowledge graphs on the Slope of Enlightenment.[5]

Section 4: What this looks like in a PM workflow

Concretely, here's what the "feature X this quarter" question looks like with a knowledge graph:

Without a graph (today, for most B2B SaaS teams)

• PM exports a Pendo report. Tags it manually against a list of strategic accounts pulled from Salesforce earlier this week.
• Pings the CSM team in Slack to confirm which accounts have asked for the capability in QBRs (no shared system).
• Opens the most recent Klue battlecard. It's six weeks stale; sends a Slack to the CI analyst asking for a manual check.
• Two days later, a spreadsheet emerges with about 70% of the data. The PM makes a roadmap call and moves on.
• Three months later, the call turns out to have been wrong because the competitor shipped a better version of X two days after the spreadsheet was built.

With a graph (the design goal)

• PM asks: “Which strategic-tier accounts requested capability X in the last 90 days?”
• One graph query traverses account → tier → request → capability node. Returns, say, 14 accounts, with provenance.
• Follow-up: “Which of those 14 use a vendor that ships capability X today?” Same graph. Returns 9 of 14.
• Follow-up: “Which competitor ships it best — by review sentiment in the last 30 days?” Same graph. Returns ranked list with citations to the underlying reviews.
• Roadmap call made in one sitting, not after two days of chasing.

Section 5: Why the build-vs-buy math has flipped

For the last decade, the answer for most B2B SaaS companies was: a knowledge graph is fascinating in theory, but we're not going to spend 18 months and a data team to build one. That math was correct. LinkedIn and Google could justify it because they had unbounded scale and a hundred ML engineers; nobody else could.

What changed is that three of the four major cost lines collapsed:

• Schema design: shared standards (ISO 3166 for countries, open industry classifications such as NAICS) are now mature and widely available.
• Ingestion: public APIs for vendor, review and signal data now exist with clean terms of service.
• Storage and query: modern relational stores with JSON and vector-index support do what used to require a dedicated graph-database cluster.

The remaining cost is the graph maintenance: enrichment, taxonomy alignment, signal refresh, provenance tracking. That cost is real and ongoing. But it's also the cost that a vendor with 1,000 customers amortizes 1,000 ways. Which is why the build-vs-buy math has flipped for the first time.

Where to go from here

If your PM team is recognizable in the "without a graph" description above, the question to ask isn't "should we build a knowledge graph?". It's "at what point does the cost of operating without one exceed the cost of subscribing to one?"

For most teams above $50M ARR, the math says: it already does. The time spent gathering data compounds. The mid-quarter replans compound. The competitive blind spots compound. The output of a graph is faster, more defensible product decisions · which is the entire point of having product managers in the first place.

We'll cover the engineering side in the next post: Stop Building What Already Exists · Graph-Grounded Feature Discovery for Engineering Teams.