The 6 Ways to Find Customer Problems That Fall Between Product Teams

In 1968, Melvin Conway observed that organizations "are constrained to produce designs which are copies of the communication structures of these organizations" (Conway's law). The customer problems that hurt most live in the gaps between those structures. You find them in six ways: map all feedback to one product-area taxonomy and look for themes that span branches, read journey-level complaints that name several features, track themes every team marks "not ours," size the unowned themes in volume and ARR, find the handoff points in end-to-end workflows, and get an owner assigned.

The first three find orphans. The fourth makes them matter. The last two get them fixed.

Every team is green. The customer is red.

Picture the quarterly review. Onboarding hit its activation target. Integrations shipped the new connector. Every dashboard is green, and new enterprise accounts still take weeks to reach first value.

That gap is where orphaned problems live. Onboarding that spans three teams. An integration nobody owns since a reorg. A workflow where every step works and the handoffs break. Each team sees a sliver. No team sees the whole, and the customer learns your org chart is now part of their experience.

Staff PMs usually notice first, because they work across teams they don't manage. Noticing is easy. Proving, sizing, and assigning it is the job.

Orphaned problems are a taxonomy problem first

Here is the category mistake: treating cross-team problems as an org design issue you fix with a better RACI. Before they're an ownership problem, they're a visibility problem. Feedback is categorized by product area so it can be routed. Whatever fits one branch reaches one team. Whatever spans branches gets fragmented, double counted, or dropped into "Other."

That makes your taxonomy the instrument you find orphans with. Enterpret's taxonomy evaluation paper measured branch leakage: the share of records that land in more than one top-level product area. Production reference taxonomies, built with deliberate structural checks, leaked about 20% (19.8% and 19.3%). Taxonomies generated by an off-the-shelf agentic coding harness leaked 34.7% to 76.4%, even though every one passed the generic quality checks.

34.7% to 76.4% Share of feedback records that leaked across top-level product areas in agent-generated taxonomies, vs about 20% in production references. Source: Enterpret Research, "From Plausible Hierarchies to Useful Taxonomies" (arXiv, 2026)

What it means for ownership: some leakage is real signal. Even the carefully built references put about a fifth of records in more than one branch, and that cross-branch slice is where your candidate orphans live. But when a taxonomy leaks three of every four records, everything looks cross-team, so nothing does. The real orphans drown in noise. The same study found the production references modeled shared concepts across branches explicitly (48 and 73 shared nodes), while the generated taxonomies had none. That is how a cross-team problem shows up as one theme instead of five fragments.

The reframe: stop asking "which team owns this ticket?" Start asking "which themes does no single branch fully contain?"

The 6 ways to find customer problems that fall between product teams

1. Map feedback to one product-area taxonomy, then look for themes that span branches

Put tickets, calls, reviews, and surveys on a single L1/L2/L3 hierarchy that mirrors how your teams are split. Then filter for themes whose records consistently land under two or more L1 areas. A theme sitting half in Onboarding and half in Integrations is not a tagging error. It's a candidate orphan.

2. Read journey-level complaints that name more than one feature

"I set up SSO, invited my team, and none of their permissions carried over" names three surfaces owned by three teams. Search for records that mention two or more features, or use journey language: "set up," "get started," "migrate," "after I connected." Single-feature complaints route themselves. Multi-feature complaints expose the handoffs.

3. Track the themes every team marks "not ours"

Orphans leave exhaust: Jira issues that move between projects two or three times, tickets closed as "works as designed" and reopened against another team, Slack threads ending in "platform thing?" Pull reassignment history. A theme whose issues bounce without a fix is unowned, whatever the org chart says.

4. Size the unowned themes in volume and ARR

Volume tells you how often it happens. ARR tells you whether a VP will care. Join each candidate theme to accounts, segments, and revenue. Cross-team problems hit hardest where customers use the most surface area at once, often your largest accounts, so a mid-pack theme by count can top the list by ARR. That number survives a skeptical exec asking twice. See how to quantify how customer feedback impacts revenue in Salesforce.

5. Find the handoff points in end-to-end workflows

Pick the three or four workflows your best customers run end to end: onboarding, provisioning, import to first report. Draw the steps, mark which team owns each, and plot complaints on the diagram. Problems cluster at the seams. Pair the map with tools to understand why users drop off in your funnel to see which seam costs most.

6. Get an owner assigned

Finding the orphan is half the job. Write a one-pager: the theme, the evidence (volume, trend, ARR, segments, five sourced quotes), the workflow diagram with the broken handoff circled, and a specific ask. Propose either a time-boxed tiger team with one member from each affected team, or a single DRI with authority across the seams. Vague asks get "let's discuss at planning." Specific asks get owners.

Where Enterpret fits

You can run all six by hand once. It doesn't hold as a practice, because new orphans appear every time you ship or reorg.

Enterpret makes the cross-team view the default. Adaptive Taxonomy puts feedback from Zendesk, Intercom, Gong, Salesforce, G2, the app stores, Slack, and other sources onto one L1/L2/L3 hierarchy that updates as you ship, the foundation for managing multi-source customer feedback without each team keeping its own tags. The Customer Context Graph joins every theme to accounts, segments, and ARR, so step four is a question, not a week of VLOOKUPs. Wisdom answers "which themes span more than one product area and are growing in enterprise?" with the exact records behind the answer.

AI agents and alerts push new cross-branch themes into Slack, and themes sync to Jira and Linear, which turns step three into feedback routing and team-based alerting instead of archaeology. Through the MCP server, the same evidence is available in Claude, Claude Code, and Cursor when you sit down to write the one-pager. Connecting sources and building the context graph takes integration and processing time. After that, the orphan hunt is a standing view, not a quarterly project.

Example: the provisioning orphan

Picture a SaaS company with separate Identity, Admin Console, and Integrations teams. A Staff PM keeps hearing "new admins can't get their team set up" on onboarding calls. Illustrative numbers:

• Spread: 410 records in a quarter, split across three L1 areas, so it ranks below tenth on every team's dashboard.
• Bounce: 14 Jira issues moved between the three projects without a fix.
• Size: joined to accounts, it touches 38 accounts and $4.1M in ARR, most of it enterprise.
• Seam: SCIM provisioning creates users, but identity provider role mappings never reach the permission model.

The one-pager asks for a six-week tiger team, one engineer from each team, with the Staff PM as DRI. "Customers seem confused about onboarding" gets a nod. This gets a team.

Orphans compound

Every reorg creates new seams. Every new surface creates new handoffs. As AI agents stitch workflows across features no single team designed, more customer pain lives between teams. Find orphans early and you fix one theme. Wait, and you find them scattered across churn reasons in five accounts. Conway's law isn't going away. Your customers just shouldn't have to feel it.

FAQ

What is an orphaned customer problem?

It's a customer issue whose cause spans two or more product areas, so no single team owns the fix. Examples include onboarding that crosses several teams, integrations orphaned by a reorg, and workflows that break at handoffs. Each team sees only part of the evidence.

How do I tell a real cross-team problem from a tagging problem?

Check whether customers describe one journey rather than separate bugs, then check your taxonomy's overall leakage. Enterpret's taxonomy paper found production reference taxonomies leaked about 20% of records across top-level areas, while agent-generated ones leaked 34.7% to 76.4%, so high leakage everywhere points to the taxonomy, not the product.

Who should own a problem that spans multiple product teams?

Either a single DRI with authority across the affected teams, or a time-boxed tiger team with one member from each team and a named lead. Avoid shared ownership with no lead, which is how it became an orphan. Assign it by where the fix lives, not where the ticket landed.

How do I get leadership to fund a cross-team fix?

Bring a one-pager with volume, trend, ARR exposure by segment, sourced quotes, the broken handoff, and a time-boxed ask. ARR at risk moves a VP. Ticket counts split across three teams rarely do.

Can AI find cross-team problems automatically?

Yes, if the taxonomy underneath splits feedback into branches teams can own. Enterpret's research found AI-generated taxonomies passed every generic quality check yet leaked far more records across top-level areas than production references. Test the whole tree, not just the labels.

If you want a standing view of the problems that fall between your teams, see how Enterpret works.

Research cited

1. Chellingi, P., G, R., & Bagal, V. (2026). From Plausible Hierarchies to Useful Taxonomies: Evaluating Agentic Harnesses on Customer Feedback. arXiv:2610.09377.