An integrations strategy that fits starts with mapping where your product sits inside the customer's workflow graph — as the system of record, the system of engagement, or the system of intelligence — and then honestly testing whether that position makes you a hub other tools must connect to, or a spoke one Zapier flow away from replacement.
Map your product's position in the customer's tool stack before you build a single connector. If you're not the system of record for a workflow that matters, you're a spoke — and spokes are one integration platform away from being routed around.
Stop Asking "Which Connectors Should We Build First"
The connector-request backlog is the wrong starting point because it treats integrations as a checklist instead of a positioning decision. The real question isn't which app to connect next — it's whether your product anchors a workflow that other tools orbit around, or whether you're an interchangeable node customers could route around with middleware.
Most integrations roadmaps get built the same way. Sales asks for the top-requested app. Support tickets pile up around a broken sync. A competitor announces a marketplace and someone panics. Eighteen months later you have forty connectors, a support burden nobody budgeted for, and no clearer sense of whether customers would notice if half of them vanished tomorrow.
That's a symptom, not a strategy. Geoffrey Moore's concept of the whole product, from Crossing the Chasm, is useful here: customers don't buy your core product, they buy the complete solution — your product plus the tools, data, and services that make it actually work in their world. Moore's insight was that markets get won by deliberately assembling that whole product, not by reactively bolting on whatever the loudest customer demands this quarter.
An integrations strategy applies the same discipline one layer up. Instead of starting from "what should we build," start from "where do we actually sit." That's a mapping exercise before it's a roadmap exercise — and it's the exercise most first-time integrations PMs skip, because a spreadsheet of connector requests feels like progress and a workflow map feels like busywork. It isn't.
If you're new to the role entirely, our complete guide to the integrations PM role covers the day-to-day mandate in depth. This piece assumes that ground and goes straight at the strategic question underneath it: not what to build next, but where you fit.
Map the Customer's Workflow Graph Before You Map Your API
A workflow graph is the set of tools a customer touches to complete one job, drawn as nodes with arrows showing which tool triggers the next step and which tool holds the data of record. Map three or four core jobs this way before you touch your integration backlog, and your product's real position becomes visible fast.
Borrow the lens from Jobs to Be Done, the framework Clayton Christensen popularized and Bob Moesta operationalized into practical interview technique. JTBD asks what the customer is actually trying to get done, not what feature they're requesting. Apply the same question to the stack: what is the customer trying to accomplish, and which tools do they touch, in what order, to accomplish it?
Take a common job: "get a new employee productive." The workflow graph might run identity provider, to HR system, to your product, to Slack, to a ticketing system. Which node initiated the workflow? Which node has to be correct or everything downstream breaks? Usually that's the identity layer — which is why SSO and SCIM provisioning are existential integrations for identity tooling long before they're a growth feature. Teams building in that space should also read our guide to the security PM role; identity is almost always the root node other tools graph off of.
The same logic holds in infrastructure stacks, where the workflow graph runs from code commit to CI/CD to observability to incident response — a chain our infra PM role guide covers in more depth. In both cases the specific tools matter less than the pattern: mapping the graph reveals a root node, a set of pass-through nodes, and a terminal node. Your product is one of them, whether you've decided which one or not.
To map your own graph:
- List every job a customer hires your product to help with — three to five jobs, no more.
- For each job, list every other tool involved, in the order it's touched during a normal week.
- Draw an arrow from each tool to the next, and mark which tool the resulting data ultimately lives in.
- Circle the node that would break the most other nodes if it disappeared tomorrow.
That circled node is usually the system of record. It's rarely the newest tool in the stack, and it's rarely the one with the prettiest interface. It's simply the one everything else has to agree with.
Three Positions That Decide Your Integration Depth
Your product occupies one of three positions in any given workflow: system of record (owns the authoritative data), system of engagement (owns the daily interaction and workflow), or system of intelligence (owns the insight layer that reads across other systems). Each position demands a different integration depth, and confusing them is the single most common integrations-strategy mistake.
| Position | What it owns | Classic examples | Integration depth required | Failure mode if misjudged |
|---|---|---|---|---|
| System of record | The authoritative, durable data | Core banking ledger, ERP, HRIS, CRM contact database | Deep, bidirectional — others must write back to you | Shipping shallow read-only integrations and losing the data war to whoever actually owns it |
| System of engagement | The daily workflow and interaction | Collaboration tools, ticketing systems, field-service apps | Broad, high-frequency, embedded in the UX itself | Becoming a pretty front end that's easy to route around with a competitor's front end |
| System of intelligence | Cross-system insight and recommendation | Analytics platforms, forecasting tools, AI copilots | Wide read access to many sources, light write-back | Being treated as a report generator instead of a decision-maker's daily tool |
System of Record: You Win by Being the Truth
If you're building in fintech, this is the position worth fighting hardest for. Owning a core ledger, an account balance, or the system that reconciles money movement earns a kind of gravitational integration depth nothing else can match — every other tool has to ask you what's true before it acts. Our fintech PM role guide goes deeper on why ledger ownership is the single highest-leverage position in that vertical.
System of Engagement: You Win by Being Where Work Happens
Engagement layers earn their keep through frequency and habit, not data ownership. That's real leverage, but it's fragile leverage — customers can and do run two competing engagement tools side by side while a migration completes, something they'd never do with two systems of record. Depth here means embedding actions, not just notifications, so the workflow actually finishes inside your product instead of just starting there.
System of Intelligence: You Win by Seeing Across Boundaries Nobody Else Can
Intelligence layers win by synthesizing what no single system of record can see alone — supply against demand, spend against outcome, behavior against churn. A marketplace's matching or recommendation engine is a good example: it typically sits across two-sided supply and demand data as a system of intelligence rather than a record of either side. Our marketplace PM role guide covers the two-sided dynamics that make this position especially delicate to hold onto.
The Stack-Mapping Exercise: Put Your Product on the Whiteboard
Run this exercise with your team before your next integrations roadmap review: for one real customer, list every tool in their stack for a target job, score each on data ownership and switching cost, then mark where your product sits relative to the tool that would be hardest to remove. It takes about ninety minutes and it will reorder your backlog.
- Pick one real customer and one real job — not a persona, an actual account with actual tools.
- List every tool touching that job, including the ones you don't integrate with yet.
- For each tool, score data ownership 1-5: does it create the record of truth, or just display it?
- For each tool, score switching cost 1-5: how painful, in time and risk, would it be to rip it out?
- Plot your product against the highest-scoring tool. Are you above it, below it, or beside it?
- Repeat with two more customers in different segments — position shifts by segment more than most PMs expect.
A filled-in row looks something like this:
| Tool in the stack | Job it performs | Data it owns | Switching cost (1-5) | Update frequency |
|---|---|---|---|---|
| HRIS | Employee record of truth | Legal identity, comp, org chart | 5 | Low, event-driven |
| Identity provider | Access control | Login credentials, group membership | 5 | Continuous |
| Point solution X | Adjacent task | Task-specific working data | 2 | Medium |
| Your product | Target workflow | Depends on the position you occupy | ? | ? |
The uncomfortable part of the exercise is the question mark in your own row. Most teams have never scored their own product on the same scale they'd apply to a vendor they're evaluating — and that's exactly why the exercise is worth ninety minutes of a leadership team's time.
The Hub-vs-Spoke Test
Ask four questions about any workflow you're part of: who has data gravity, what's the switching cost if you're removed, are you the trigger or the recipient, and do customers comfortably run you alongside a direct competitor at the same time. Answer "yours" to three or four and you're a hub. Answer "yours" to one or none and you're a spoke.
- Data gravity. Does your product create data other tools depend on, or do you mostly consume data someone else created? Hubs create; spokes consume.
- Switching cost. If a customer removed you tomorrow, how many other workflows break immediately versus eventually? Immediate breakage signals a hub; "we'd probably notice within a quarter" signals a spoke.
- Trigger position. In the workflow graph, are you usually the tool that starts the sequence, or the one three hops downstream reacting to someone else's webhook? Starters skew hub.
- Multi-homing. Do customers comfortably run you next to a direct competitor for the same job — two analytics tools, two chat apps? Products that get multi-homed are, almost by definition, spokes. Nobody multi-homes their system of record.
Economists Carl Shapiro and Hal Varian, in Information Rules, described how switching costs and lock-in determine who captures value in networked markets. The same dynamic plays out in miniature inside a customer's tool stack every time you ship, or decline, an integration.
| Signal | Hub indicator | Spoke indicator |
|---|---|---|
| Data gravity | Other tools write to you | You mostly read from others |
| Switching cost | Removal breaks workflows the same day | Removal is noticed weeks later |
| Trigger position | You originate events | You react to others' events |
| Multi-homing | Customers run one of you | Customers comfortably run two or three |
Build for Your Position, Not Your Backlog
Once you know your position, integration priorities stop being a debate.
- If you're a system of record (or credibly want to become one): invest in outbound
webhooks, a public API, and a partner program before you invest in more inbound connectors. Your job is to become the platform others build on top of — the mindset shift our piece on treating the app marketplace as an ecosystem, not a connector list argues for directly. It's the same instinct investor Chris Dixon captured with "come for the tool, stay for the network." - If you're a system of engagement: prioritize deep, bidirectional sync with whatever holds the system of record. That tool is trusted more than you by default, and it will win any dispute over "what's actually true."
- If you're a system of intelligence: prioritize broad, low-friction read access —
OAuthscopes, read replicas, data warehouse connectors — over deep write-back. Your value is synthesis, not becoming one more place someone has to update a field.
Seeing the Feedback Loops That Make You a Hub or a Spoke
Positioning isn't static — it's reinforced or eroded by feedback loops. Every integration you ship changes switching costs, which changes your leverage with adjacent tools, which changes whether the next integration request comes to you or goes around you. That's a systems problem, not a features list, and it rewards diagramming more than guessing.
This is the one place in an integrations strategy where a causal-loop map earns its keep. Prodinja's Systems Engineering workspace lets you place your product, the adjacent tools in a customer's stack, and factors like switching cost or data gravity onto a canvas, then draw the reinforcing and balancing loops connecting them — so you can see, concretely, whether the loop you're building compounds toward hub or erodes toward spoke before you commit a roadmap to it.
Key Takeaways
- An integrations strategy starts with positioning, not a connector backlog — map where you sit in the customer's workflow graph before deciding what to build next.
- Your product occupies one of three positions — system of record, system of engagement, or system of intelligence — and each demands a different integration depth.
- Run the stack-mapping exercise on real customer accounts, not personas: list every tool, score data ownership and switching cost, then plot your product against the highest-scoring tool.
- Use the hub-vs-spoke test — data gravity, switching cost, trigger position, multi-homing — to diagnose whether you're a hub worth building a platform around or a spoke at risk of being routed around.
- Systems of record should invest in outbound APIs and partner programs; systems of engagement should invest in deep sync with the record layer; systems of intelligence should optimize for broad read access.
- Positioning compounds through feedback loops, not single decisions — the integrations you ship today change the switching costs and leverage you carry tomorrow.
Frequently Asked Questions
What is an integrations strategy in product management?
An integrations strategy is a deliberate decision about where your product sits in customers' tool stacks and how deeply you connect to adjacent systems, rather than an ad hoc list of connectors built in response to sales or support requests. It sets priorities for API depth, partner programs, and which integration requests to decline.
How do I decide which integrations to build first?
Map the workflow graph for your top three customer jobs, identify whether you're the system of record, engagement, or intelligence for each, then prioritize integrations that deepen your position in the role you actually occupy — rather than matching a competitor's connector count feature-for-feature.
What's the difference between a system of record and a system of engagement?
A system of record owns the authoritative version of the data — the one everything else has to agree with — while a system of engagement owns the daily workflow and interaction layer that touches that data without necessarily owning it. Core banking ledgers and HRIS platforms are typically records; collaboration and ticketing tools are typically engagement layers.
What is a hub-and-spoke integration strategy?
Here, hub and spoke describes a product's structural position, not a technical topology. A hub is a product other tools must connect to and defer to; a spoke is a replaceable node customers can swap out through middleware like an iPaaS without disrupting the broader workflow around it.
How many integrations does a typical SaaS product need?
There's no fixed number worth chasing — Okta's annual Businesses at Work report has tracked large enterprises running upward of 100 SaaS applications in a single stack. The relevant question isn't a count; it's which handful of workflow-critical tools you must integrate deeply with versus which long tail you can safely leave to a generic connector platform.