Why 60% of Product Roadmaps Miss — And How a Knowledge Graph Closes the Gap

In Productboard's 2024 State of Product Management survey, 4,500 PMs reported what most of us already suspected: 60% of items on the roadmap did not ship within their original quarter target.[1] Six in ten. That number has been flat — within 2 percentage points — every year since 2019.

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 the rate at which they get worse is correlated 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 graph-grounded product organizations, 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.

Forrester's 2024 Product Operations research found that 96% of B2B SaaS companies above $50M ARR now have a Product Operations function — but only 22% have a unified system of record for product, market, and customer data.[7] The other 78% are doing a version of the seven-system dance, mostly with spreadsheets and tribal knowledge as glue.

The Pendo/Mind the Product 2025 benchmarks put a number on the cost: PMs spend a median 33% of their time on data wrangling, status reports, and firefighting — the same number they reported in 2021.[8] Four years of investment in product analytics tools, project trackers, and feedback platforms haven't moved that line. 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 battle card (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,[10] and it's been productionized at scale by LinkedIn, Google, Microsoft, and Amazon for over a decade.[9] 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 about graph-grounded product orgs

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 is consistent:

McKinsey: 20-50% time-to-market improvement for AI-enabled product orgs

McKinsey's March 2025 State of AI report tracked product organizations using AI for input synthesis, decision support, and roadmap-scenario modeling.[2] The top quartile reported 20-50% reductions in time-to-market on roadmap items that benefited from these tools. The bottom quartile (using LLMs without grounding) reported essentially no measurable gain — the inputs were too unreliable to trust at the decision point.

The difference between the quartiles is the structural one: the top group had grounded their AI in some version of a knowledge graph — internal taxonomy, vendor entities, competitor maps. The bottom group was running ChatGPT against PDFs.

IDC: 28% less product-development rework

IDC's 2024 Worldwide AI for Enterprise Software Spending Guide found that companies with mature knowledge-graph infrastructure reported 28% less product-development rework than peers without it.[6] The mechanism: fewer features built that turned out to overlap with something the team already shipped (or a competitor already shipped well), and fewer roadmap items deprioritized mid-quarter because of a signal that should have been caught at intake.

Microsoft Research: GraphRAG outperforms vector RAG by 70-80%

The most rigorous recent benchmark is Microsoft Research's GraphRAG paper (Edge et al., April 2024), which compared graph-grounded retrieval against standard dense-vector retrieval on enterprise-style question-answering tasks.[3] On "global" questions — the multi-hop reasoning that product orgs actually need (e.g., "which features appear across customer-facing complaints AND competitor releases AND strategic-account requests?") — GraphRAG outperformed baseline RAG by 70-80% in human preference evaluation.

This matters because the standard enterprise AI stack as of mid-2025 is still mostly vector RAG. The organizations that invested in graph grounding are working with a measurably better substrate for product decisions, and the gap is widening as graph approaches mature.

The bottom quartile of product orgs got essentially no measurable gain from AI. The difference between them and the top quartile is that the top group grounded their AI in a knowledge graph.

Gartner: Knowledge graphs are now on the Slope of Enlightenment

Gartner's 2024 Hype Cycle for Data Management moved knowledge graph technology from the Trough of Disillusionment to the Slope of Enlightenment, with a 2-5 year Plateau of Productivity estimate.[5] In Gartner's framing, this is the phase where early-adopter wins start showing up in case studies and the cost of not adopting the technology begins to compound for laggards.

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 78% of B2B SaaS)

• 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 battle card. 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 14 accounts in 1.4 seconds 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 12 minutes instead of 2 days.

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 ontologies for enterprise software (GICS for industries, ISO 3166 for countries, etc.) are now mature and free.
• Ingestion: 200+ public APIs for vendor data, review data, signal data exist with ToS-clean access.
• Storage and query: Postgres + JSONB + HNSW indexes do what required a $1M Neo4j cluster in 2018.

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 — and the Forrester data suggests four out of five reading this will be — 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 33% PM time tax compounds. The 60% roadmap miss rate compounds. 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.