Data Silos Between Engineering and Product
PMs and engineers use different tools, different language, and different timelines. Here's how the silo forms – and what actually fixes it.
By Ellis Keane · 2026-03-16
Somewhere along the way, "product-engineering alignment" became a job title instead of something that just happened when competent people worked together. Companies now hire dedicated humans whose entire purpose is making sure two groups of smart people – who sit in the same Slack workspace, attend the same standups, and theoretically work toward the same goals – can actually understand what the other group is doing. The data silos between engineering and product that make this necessary aren't a people problem. They're a tooling problem.
PMs and engineers communicate plenty. The issue is that they work in completely different systems, and the silos that form between those systems are structural – baked into the architecture of how modern teams choose their tools. No amount of "let's align more often" fixes a problem where the tools themselves have no awareness of each other.
The Two Realities
I'm drawing from our own experience building Sugarbug here, because we live this every day and I think the specifics are more useful than the abstract version.
The PM side of things (that's mostly me, in our case) lives in Notion. Specs get written there, priorities tracked, customer conversations logged, feature requests catalogued in running lists that grow by the week. Notion is where the "why" lives – why we're building something, what the customer actually said, what strategic context sits behind a given decision. It's messy, it's sprawling, and it's where most of the important thinking happens before a single line of code gets written.
Meanwhile, our engineers live in Linear and GitHub. Linear holds the tasks, the sprint cycles, the dependency chains and blocking issues. GitHub has the code, the pull requests, the review threads where people argue constructively (hopefully) about implementation details. That's where the "how" and the "when" live – how something is being built, when it'll ship, what's in the way.
Both realities are accurate, both essential, and they're completely disconnected from each other. The gap between them is where requirements go stale and rework starts accumulating.
How Data Silos Between Engineering and Product Actually Form
It's tempting to think this is a deliberate choice – that someone decided to keep the information apart. In practice, the silo forms through completely reasonable behavior that nobody intended to be harmful.
A PM writes a spec in Notion, links it in Slack to the engineering channel, and considers the handoff done. An engineer reads the spec, creates three Linear issues from it, and starts building. So far, everything's working.
But then the spec changes – a customer conversation shifts the priority, or the business context evolves. The PM updates the Notion doc and drops a note in Slack about the change. The engineer, deep in a coding session, doesn't see the Slack message for hours. By then they've built two of the three features against the old spec, and the third issue in Linear still references requirements that no longer exist.
Nobody was careless here. Nobody "failed to communicate." The information lived in one system and the work happened in another, and the connective tissue between them was a Slack message that got buried under other threads before the right person saw it.
This happens repeatedly – across every spec, every sprint, every quarter – and the drift compounds. The gap between what product thinks is happening and what engineering is actually building gets wider with every handoff that relies on a human noticing a message at the right time.
Why "Better Communication" Doesn't Fix It
I've sat in retrospectives where the action item was "communicate changes more proactively," and (lovingly) that's the organizational equivalent of telling someone to just be more organized. It sounds actionable, it makes the Confluence page look productive, and it changes absolutely nothing about the system that caused the problem. We've run that same retro action item three times now – I checked.
The reason better communication doesn't solve data silos between engineering and product is that communication is already happening – the data exists, the decisions are being made and recorded. They're just recorded in tools that have no awareness of each other.
Notion doesn't know that a spec has been decomposed into three Linear issues. Linear doesn't know that the requirements behind an issue changed in Notion two hours ago. GitHub has no idea that the PR being reviewed implements a feature whose priority just got downgraded in the PM's Notion board. Each tool is functioning exactly as designed – they just weren't designed to function together.
"There's a certain dark comedy in spending your Monday morning confirming that the tools you pay for haven't silently diverged from reality over the weekend." – Ellis Keane
So what happens is that PMs manually mirror changes from Notion into Linear when specs change, engineers ping PMs on Slack to ask "is this still the plan?", and leads spend their Monday mornings cross-referencing boards to check for drift. We've watched ourselves burn several hours a week on what amounts to manual data synchronization between tools that should, in theory, already know about each other.
What a Systems Fix Actually Looks Like
The instinct when you see a gap between two tools is to build a bridge – a Zapier automation, a webhook, a sync script. For simple, predictable flows (when a Linear issue moves to "Done," update a Notion status), that works fine.
But data silos between engineering and product involve context, not just status. The PM didn't just change a status field; they rewrote a paragraph in the spec that changes what "done" means for two of the three Linear issues. Simple status webhooks miss requirement-level changes unless you add diff logic and semantic mapping on top, which most teams never get around to building.
What you actually need is something that understands the relationships between the data across tools – not just "this Notion page is linked to this Linear issue," but "this section of the spec describes the requirements for this issue, and that section just changed." The goal is mapping spec edits to impacted issues automatically, rather than relying on someone to notice and propagate the change.
That's the difference between a sync layer and a knowledge graph. A sync layer copies data between tools. A knowledge graph tracks how the data relates, detects when those relationships change, and surfaces the changes to the people who need to know.
We're building Sugarbug to work this way – connecting the tools that PMs and engineers already use (Notion, Linear, GitHub, Slack, Figma) into a knowledge graph that maintains the relationships between specs, tasks, code, and conversations. We're still early (honestly, there's a lot we haven't figured out yet about how to make semantic diff detection reliable at scale), but the core graph is working and it's already caught spec-drift situations that would have turned into rework.
Data silos between engineering and product form because the tools are structurally disconnected, not because people communicate poorly. The fix is connecting the data at the relationship level, not adding more communication channels.
What You Can Do This Week
I'm not going to pretend the only answer is "use Sugarbug." There are things you can do right now, with whatever tools you're already running, to reduce the worst effects of the product-engineering data silo.
Make cross-references explicit, bidirectional, and owned. Every Notion spec should have a "Linear Issues" section at the bottom that links to the issues it spawned, and every Linear issue should link back to its source spec. Assign one person per spec to own the cross-reference – not the whole team, one person, with their name on it. We tried the "everyone's responsible" version and (predictably) nobody was. The links will drift over time regardless, but having a named owner means there's someone to ping when the drift gets noticed.
Establish a "spec change" ritual with a trigger, not a reminder. When a spec changes materially (not typos – actual requirement changes), the PM updates the linked Linear issues before closing the Notion tab. Not later, not "when I get a chance" – before the tab closes. The comment on each affected issue should be one line: what changed, link to the updated section, and whether the issue's acceptance criteria are still valid. We've found that tying the update to a physical action (closing the tab) works better than relying on anyone's memory, because memory is exactly how the silo formed in the first place.
Run a 15-minute Friday priority-match check. One person (rotate weekly) pulls up the PM's top 5 priorities in Notion and the engineering sprint's top 5 in Linear, side by side. The question isn't "are these identical?" – they won't be, and that's fine. The question is "are any of these actively contradicting each other?" If the PM's #1 priority isn't anywhere in the sprint, that's the conversation to have on Monday, not a status update.
These are manual processes, and they have a shelf life. At five engineers and two PMs, they're tedious but they work. At fifteen engineers, three PMs, and a design team adding Figma into the mix, the cross-tool relationships multiply faster than anyone can track by hand. But they'll teach you where your worst product engineering alignment gaps actually are – and that diagnostic value is worth the effort even if you eventually automate the whole thing.
Whether the long-term fix is Sugarbug or something else (we obviously think we're building the right thing, but I'm biased), the product management engineering collaboration problem only resolves when the tools themselves are connected at a semantic level, and humans can focus on making decisions rather than shuttling context between apps.
If your manual cross-references are holding up, ride that as long as it lasts. If you keep having the same retrospective action items about communication, the problem isn't your people. It's your data architecture.
Connect Notion, Linear, GitHub, and Slack into one knowledge graph – so spec changes surface to the right engineers automatically.
Q: How long does it take to set up Sugarbug for a product-engineering team? A: The initial connection takes minutes per tool – you authenticate Linear, GitHub, Notion, Slack, and Figma via OAuth, and Sugarbug starts building the knowledge graph immediately. The graph gets meaningfully useful within a day or two as it ingests your existing data and starts mapping relationships between specs, issues, and conversations. We're still refining the onboarding flow, but the aim is that you shouldn't need to configure anything beyond connecting your accounts.
Q: Does Sugarbug replace Linear, Notion, or any of our existing tools? A: No. Sugarbug sits alongside your existing tools and connects them – it doesn't replace any of them. Your PMs keep writing specs in Notion, your engineers keep working in Linear and GitHub, and Sugarbug maintains the relationships between them so context doesn't get lost in transit. Think of it as the connective tissue between the tools you already use.
Q: Can Sugarbug detect when a Notion spec changes and alert the right engineers? A: That's a core part of what we're building. When a spec changes in Notion, Sugarbug identifies which Linear issues are linked to it and surfaces the change to the engineers working on those issues. We're still iterating on the semantic detection piece (figuring out which changes are material versus cosmetic), but the cross-tool linking and basic change detection are working.
Q: What is the difference between a sync tool and a knowledge graph for this problem? A: A sync tool copies status changes between apps – when a Linear issue moves to "Done," update a Notion checkbox. A knowledge graph tracks how the data relates: this spec describes the requirements for these three issues, and the acceptance criteria changed, which affects the two issues that haven't shipped yet. The difference matters most when the changes are semantic, not just status-level.
Q: Is product-engineering alignment a communication problem or a data problem? A: In our experience, it's almost always a data problem that gets misdiagnosed as a communication problem. The teams are communicating – they're just doing it through tools that have no awareness of each other. Fixing the data flow between those tools tends to resolve the alignment issues that no amount of retros or sync meetings could fix.