Many Repositories, Many Products: The Holistic View Nobody Has
A Product Marketing Manager described her company’s product setup to me: a hardware product with a software dashboard, a separate software-only product with a larger engineering team, and a firmware team working on both. Five repositories. Three release cadences. Four teams.
Her challenge? Combining updates across these systems into a coherent picture of what shipped.
“Seeing that holistic view would be valuable,” she said. “Patterns across them in a way that only AI could see, because nobody at the business has the depth across every stream.”
This is the multi-repo, multi-product problem. And it’s more common than you’d think.
The fragmented reality
Modern products are rarely monolithic. A typical mid-market software company might have:
- A frontend repository for the web application
- A backend repository for the API
- A mobile repository (or two, for iOS and Android)
- An infrastructure repository for deployment and tooling
- Maybe a data pipeline or ML repository
- Integration repositories for third-party connections
Each repository has its own commit history, its own release cycle, its own team. Each one tells part of the story. None tells the whole story.
A VP of Product at a financial analytics platform described this exact challenge. They have a data repo, a backend, a frontend, and a mobile app. When they tried to communicate what shipped, they’d announce a backend change without mentioning the frontend work that made it visible to users. Or they’d talk about the mobile app without connecting it to the backend capabilities that enabled it.
The customer experience crosses all these boundaries. The communication about it shouldn’t stop at repository lines.
The aggregation problem
When a customer asks “what’s new,” they don’t care about your repository structure. They care about their experience.
Internally, though, the people who know what shipped organize around those repositories. The frontend team knows what they built. The backend team knows what they built. Nobody has the combined view.
A Head of Engineering at one company admitted during our conversation: “To be honest, I know enough to feel like I’m giving good advice, but I would love to have a much more holistic understanding.” She was going into planning season and wanted to see patterns across engineering streams. It wasn’t possible without manually aggregating from six different sources.
The math gets worse as you scale. A company with 15 repositories feeding into their product offering can’t reasonably expect any single person to track what’s happening across all 15. The cognitive load is too high. The context-switching is too expensive.
“If I could just get a report of what happened across all 15 of these areas,” one product leader told me, “even that would be useful.”
Multi-product complexity
Repositories are one dimension. Products are another.
A product marketer at a large enterprise company told me she’s responsible for approximately 20 significant products. Not features. Products. Each with its own engineering team, roadmap, and customers.
She described needing to join calls just to understand what different teams were working on. There was no other way to gather the information. The alternative was flying blind.
At a three-sided platform (serving shoppers, brands, and creators), the challenge was similar. Engineering ships constantly, but the product team doesn’t have visibility into most of it. “New features are just the tip of it,” a PM told me. “Our engineering team does way more than that.”
When you multiply repositories by products by teams, the number of information sources becomes unmanageable. Nobody has the holistic view because having it would require being everywhere at once.
Why this matters for communication
The fragmentation isn’t just an internal inconvenience. It shows up in customer communication.
When product updates come together piecemeal from different sources, they reflect that fragmentation:
Incomplete coverage. The monthly recap mentions the frontend improvements but misses the backend performance work that made them possible.
Inconsistent framing. The dashboard team describes their work one way. The mobile team describes theirs another way. The customer sees disconnected announcements instead of a coherent product evolution.
Delayed delivery. Assembling updates from five or six sources takes time. By the time you’ve gathered everything, reviewed it, and published, you’re already behind on the next cycle.
Missed connections. A firmware update enables a new hardware capability, which unlocks a new software feature. The customer sees three separate announcements instead of one story about expanded functionality.
The net customer impact
The real question isn’t “what did the backend team ship?” It’s “what’s the net customer impact across this work?”
A product leader at a financial analytics company framed it well: instead of telling customers about backend changes they’ll never see, or limiting communication to just the frontend, they wanted to grab everything together and express the full experience.
“Here’s how we process data now. Here’s how we display it in these charts. Here’s how it’s available in the frontend and the mobile app.” That’s a much richer story than any single repository could tell.
Telling that story requires aggregation. It requires connecting work that happened in different places, by different teams, at different times, into a unified narrative about customer value.
Building the holistic view
The teams that solve this problem share a common approach: they aggregate at the source.
Instead of asking each team to contribute their updates to a shared document (which creates coordination overhead and inconsistent quality), they pull from the places where work actually happens. Code changes. Merged PRs. Deployed releases. The artifacts that prove something shipped.
Then they combine those signals across repositories and products. A change in the backend repository plus a change in the frontend repository plus a change in the mobile repository equals one customer-facing capability, expressed once, coherently.
This isn’t about replacing human judgment. Someone still needs to decide which stories matter most, how to frame them for different audiences, what level of detail is appropriate. The raw material, though (the comprehensive view of what shipped across engineering streams), doesn’t require manual excavation from 15 different sources.
The head of engineering’s wish
The Head of Engineering who wanted a more holistic understanding had the right instinct. The patterns across streams are often more interesting than any single stream.
Which areas are seeing the most activity? Where is engineering effort concentrated? How do changes in one system ripple into others? These questions matter for planning, for prioritization, for understanding where the product is actually going versus where leadership thinks it’s going.
The same view that helps engineering leadership understand their organization also helps product marketing communicate with customers. It’s the same underlying data, just filtered and framed for different audiences.
When nobody has the holistic view, everyone is working with partial information. Engineering makes decisions without understanding downstream impact. Product marketing communicates incomplete stories. Customers receive fragmented updates that don’t connect.
The holistic view is the foundation for coherent communication at scale.
If your product spans five repositories, three teams, or two technology stacks and you’re struggling to see the full picture of what shipped, let’s have a chat about how Changebot aggregates across your engineering streams into one coherent view.
