The product management infrastructure gap that's costing 40% of your team’s week
Sales standardized on CRM in the late 1990s. Engineering committed to Git in the mid-2000s. Both professions made their single source of truth mandatory infrastructure.
Now it’s 2026, and product management has spent fifteen years insisting it doesn't need what every other function considers non-negotiable. Malte Scholz has watched this pattern play out in product organizations of every size – from five-person startups to telcos with hundreds of business units – first as a product manager, then as the founder of airfocus, and now as Head of Product within Lucid, a 1,000+ person org with over 80 product teams. The breakdown looks the same at every scale.
Malte’s LinkedIn Post on the lack of a single source of truth in PM sparked a discussion among product leaders, unveiling an avoided conversation. It starts with a confession: "We have built our profession on a refusal to professionalize our infrastructure, and the bill is coming due."
can support your team.
Book a demo
The infrastructure gap
Sales has CRM, Marketing has its stack, Finance has ERP, Engineering has Git. Malte points out: "Product people don't have that today. They're stuck in Jira workarounds, spreadsheets, and PowerPoint.”
John Cutler, Head of Product at Dotwork, names the cultural root directly. "I think a lot of product orgs pride themselves on being decentralized, process-light, and scrappy. They naturally distrust process, whereas sales teams often live and die by their systems."
It's not that product teams lack tools. Most have Jira, Notion, spreadsheets, and half a dozen other apps. Yet the profession has never committed to operating from one shared source. That commitment precedes any tool, and product skipped that part completely.
The consequences are not abstract. Product managers spend up to 40% of their week syncing data across Confluence, Jira, and Slack – time that goes to maintaining information, not making decisions. 92% of product teams report that decisions are influenced by the loudest voice rather than data, according to the airfocus product ops report. Leaders struggle to make confident calls because the data is always one export behind. Engineering leader Boris Popovschi describes the symptom perfectly: "My favorite things are like 'We created another spreadsheet where we over-prioritized things from the previous three.' I call it a 'Hidden doc-driven process.' The truth is somewhere out there, in some doc."
The truth lives somewhere, but nobody can find it.
Three reasons product leaders stay silent, and what each one costs
1. Profession pride: "We're strategists, not operators"
Product orgs see process discipline as a threat to autonomy. Being scrappy is part of the identity. But as long as that identity goes unchallenged, the product manager absorbs the cost personally, becoming the unpaid integration layer between CRM, Zendesk, Jira, and internal docs.
The product manager’s job becomes maintenance, not direction. The org never sees the cost because it's distributed across hundreds of small moments: the ten minutes finding the right deck, the 30-minute sync that exists only because two teams are working from different versions, the roadmap update that takes an afternoon because it lives in three places.
2. Past shelfware: “We tried this and it failed"
Many product leaders have implemented product management tools that became shelfware within six months. The conclusion is usually "Tools don't work for us" rather than "We never committed to the discipline behind the tool." Malte draws a critical distinction:
The mistake is using a generic tool for a specific job, and then blaming the category when it didn't stick. The gun-shyness becomes a self-fulfilling prophecy: The org stays on spreadsheets, the coordination overhead grows with each new team, and eventually a shadow roadmap emerges because nobody trusts the "official" one anymore.
The mistake is using a generic tool for a specific job, and then blaming the category when it didn't stick. The gun-shyness becomes a self-fulfilling prophecy: The org stays on spreadsheets, the coordination overhead grows with each new team, and eventually a shadow roadmap emerges because nobody trusts the "official" one anymore.
3. Survival mode: "We're firefighting, process is the first thing out the door"
This is the most sympathetic barrier. In smaller, fast-moving orgs, sticking to a process is genuinely hard. When you're fighting fires, infrastructure feels like a luxury you'll invest in "once things calm down." Spoiler: Things won't calm down.
Scrappy is fine with five product managers. With 50, it's malpractice. The cost of not starting compounds silently: Each quarter without shared context adds another layer of coordination overhead that the next quarter inherits.
Starting the conversation, and what's on the other side
Stop calling it a "tool decision"
The framing determines the outcome. If the internal conversation is "Which product management tool should we buy?", it becomes a procurement exercise that dies in the pilot stage. If the conversation is "Are we willing to commit to shared infrastructure the way sales did two decades ago?", it gets executive sponsorship.
The strongest objection comes from product leaders who argue that product work is fundamentally different from sales, and they're right. The jobs, workflows, and methodologies vary enormously across teams. But the commitment to a shared data layer has nothing to do with making the jobs the same. Malte explains the architectural principle that resolves this: "There is a database for all of your product artifacts: OKRs, epics, opportunities, feedback, initiatives. What’s important is that you only have an object once in the database. You want to reference that one object and then slice and dice the information in different ways."
One object, held once, rendered many ways. Each team keeps its own workflow and methodology. The underlying data stays consistent. Flexibility and a single source of truth aren't opposites; they're enabled by the same architecture.
Make documents outputs, not sources
Mats-Omri Schumacher, CPO at Asset Ocean, frames the shift cleanly: "Slides, Confluence pages, and spreadsheets stop being the source of truth. They become outputs: Snapshots in time generated from the actual source."
Whether you use Git or a dedicated product management platform, the principle is the same: The source is structured, the slides are renderings. When the source is structured, leadership gets real-time visibility rather than asking for status updates. Cross-team dependencies become visible instead of being discovered in retros. The product manager’s week shifts from syncing to thinking.
Start lean, and look at what's on the other side
The single source of truth doesn't need to be complete. It needs to start. Centralize feedback or roadmaps first and let the discipline build incrementally. Small wins like these deliver value quickly and build momentum for wider adoption. A product ops partner is crucial: product managers alone cannot maintain this on top of their normal job. Nathan Thomas, Head of Product at Ricoh Europe, describes what life looked like before his organization made the shift:
Ricoh has 84,000 employees across 150 country offices. Before centralizing: silos, duplicated work, broken communication between design, product, and engineering. After: 20x scaled product team delivery on one connected platform, with an end-to-end process from design to engineering. The "before" was not a tooling problem. The "after" was not a tooling solution. It was an infrastructure commitment. You can read the whole story of how Ricoh scaled product team delivery 20x with airfocus.
The AI era stakes: Why this conversation just became urgent
Everything above would matter even in a slower era. But three forces make this conversation no longer optional.
Engineering cycle times have collapsed. Claude Code, Cursor, and similar tools mean teams can ship faster than ever. But discovery, validation, and decision quality haven't kept pace. The bottleneck has moved upstream to the work product organizations are structurally least equipped to handle, because they have no shared infrastructure for context. Jamie Lyon, CPO at Lucid, puts it plainly in the AI maturity report: "AI doesn't fix dysfunction. It exposes it, at speed."
The data from the report confirms the disconnect. 71% of product orgs say their output would suffer if AI were removed. Yet 48% still struggle to separate signal from noise, even though 57% use AI for analytics and 52% for research. The AI tools are running, but they're operating on broken context. If your product context lives in 47 fragmented documents, AI doesn't clarify; it produces faster confusion.
MCP and similar protocols are changing the architecture question entirely. When AI agents can pull product context from any system that exposes it, the conversation shifts from "Which product management tool should we use?" to "Is our product context structured and accessible at all?" If the answer is "it lives in 47 PowerPoints," AI cannot help you. Malte states the new reality simply: "It's impossible for an AI to make a good decision when it doesn't know what's going on. It doesn't make any sense."
Product orgs without a structured source will find that their AI investments don't compound. They amplify the fragmentation instead.
The commitment product teams have been avoiding
The question is no longer whether product will make this commitment. It's how much misalignment, how many wasted AI investments, and how much product manager burnout will accumulate before it does. The infrastructure gap is not new. What's new is that AI has made the cost of inaction visible (and compounding) in a way that spreadsheets and slides never could. But Malte is optimistic: "Salespeople and engineers have mastered their tools; product managers can too."
The profession has everything it needs to close this gap. It just has to stop telling itself that the gap is a feature.
How airfocus helps teams close the infrastructure gap
airfocus gives product organizations the shared source of information that sales and engineering have had for decades: a single place where OKRs, initiatives, feedback, and roadmaps live once and render across teams, methodologies, and stakeholder views. With the airfocus MCP, that structured context becomes the foundation for AI-powered product decisions – not another layer on top of fragmented data.
Ivan Peric
Read also
Explore how airfocus can support your team
