Which integrations should we build first?

The ones where two independent sources point at the same connection — named in a lost-deal write-up and asked for in a security questionnaire, say — and where somebody has agreed to own it for the years after launch. Evidence without an owner is the harder case: the demand is real, no team's plan has room for the upkeep, and shipping it regardless produces a connector that degrades quietly until a customer finds the break. When that is the situation, the answer is not yet, and the work in front of you is finding the owner rather than building the connection.

How do we prioritize integration requests?

Rank by how many independent sources name the same connection, not by who is asking or how loudly. A quiet request backed by three lost deals outranks a loud one backed by a single enthusiastic customer. Two refinements make the ranking sturdier. Age the evidence: a lost deal from two years ago describes a stack the buyer may have replaced since, while a questionnaire from last quarter describes the one they run now. And weigh each source by whether the person had a reason to be precise — a questionnaire answer is a procurement artifact somebody had to defend internally, and a hallway comment is not.

A large customer wants an integration written into the contract — does that change the test?

It changes who is deciding, not what the thing costs. A contractual commitment settles the corroboration question by force: you are building it whether or not a second source ever names it. What it does not settle is the upkeep or the displacement, so the negotiation is where those belong — a delivery date that reflects the standing cost rather than only the build, an explicit answer on who maintains the connection once that account's champion moves on, and a term covering what happens if the partner on the other side deprecates the API. One account can buy an integration. It cannot buy the years afterwards, and those still come out of somebody's capacity.

Which integrations deserve your roadmap

Q: What does an integration really cost to maintain?

More than the build estimate suggests, because the cost continues after launch: the partner's API changes on its own schedule, security reviews repeat whenever either side ships a material change, and support absorbs the gap when the two products drift out of sync. A related piece, titled In mature markets, integration depth beats feature count, argues that deepening a connection the buyer base already relies on can be higher-leverage roadmap work than shipping another feature — an argument about where build effort goes, not a claim that the upkeep is cheap. Both point the same way: take on fewer connections and hold them properly.

Guide · Market Growth · 5 min read · last verified 2026-08-11

Reviewed before publication Editorial board Independent commercial review

In shortIntegration requests arrive as enthusiasm, but the ones worth building are the ones backed by evidence: lost deals that named the missing connection, security questionnaires that asked for it by name, and buyer questions that keep…

Build the integrations that remove a 'no' from a deal you can name, and defer the ones that only add a 'maybe' to a roadmap slide. That test sounds obvious. The harder part is that the loudest integration request in a roadmap meeting is not automatically the one with evidence behind it. Volume tells you who pushed hardest — a partner manager, one vocal customer — and advocacy is easy to mistake for evidence.

Evidence, in this context, is not a feeling shared by several people in a room. It is something you can point to: a named account that said no over a missing connection, a security questionnaire that asked for it by field name, or a buyer question that keeps recurring in front of your own product. The roadmap decision gets easier once those are separated from everything else competing for the same slot.

Start from evidence that already exists, not enthusiasm

Three places already hold the evidence, and none of them require a survey to collect. Lost-deal write-ups name the missing integration directly, when sales discipline is good enough to record the real reason rather than a euphemism for price. Security questionnaires ask for specific connections by name, which makes them a blunt but reliable count of what enterprise buyers consider table stakes. And buyer questions — asked of your sales team, typed into a support chat, or put to an AI assistant researching your category — point to which connection someone expected to already exist. A Magrios scan gives that third source a fixed form: you put the integration question on the benchmark yourself — does this product connect to that tool — re-run it against the assistants, and read which vendor the answers name and what they cite as the source. That is a reading of how your category is described at the time of the scan, not a count of who is asking. It will not tell you that demand exists. It will tell you whether the connection your buyers wonder about is currently attached to somebody else's name in the answers they get, which is a different question and the one a scan is able to answer.

Lost-deal reasons are also the raw material behind how to turn lost-deal reasons into content — same evidence, a different output. There, the reason becomes an article. Here, the same reason becomes a line on a roadmap, and the two uses are not in tension; a single lost deal can justify both at once.

What the slot costs the rest of the roadmap

That a shipped connector keeps costing after the ship date — regression runs on every release, a partner's API moving on their schedule, support absorbing the drift when the two products fall out of step — is the standing commitment argued in not every partnership deserves a yes, and none of it changes because the request came through product rather than through a partnership pitch. What changes is what the cost gets weighed against. That piece is deciding whether to accept a relationship at all. A roadmap is deciding what to displace.

Displacement is the part that goes unwritten. An integration on a roadmap is never competing against doing nothing; it is competing against whatever else would have taken the slot, and both candidates arrive at the meeting priced as a build. Only one of them also books a standing claim on the same engineers for as long as it exists. Compared on build cost alone, the connector comes out cheaper than it is, by exactly the part that never ends.

Two things follow from that. Price it against a team's ongoing capacity rather than against one quarter's budget, because ongoing capacity is the account it will actually draw from. And settle the comparison while the alternative is still available: once the connector ships, the thing it beat is gone from the plan, the customers depending on it are real, and the choices left are keeping it or taking something away from someone.

Where the integrations page and the roadmap decision split

A page can only describe integrations that already exist, and says nothing about which one gets built next. That page-level craft has its own reference in how to build integration pages that answer buyer questions, worth reading once there is something to list — but no amount of page craft substitutes for the build decision itself, which happens earlier and depends on evidence the page cannot generate.

Depth versus breadth, once something is worth building

Deciding an integration deserves a slot is only the first decision; the second is how deep to build it. A badge and a paragraph on the integrations page cost little and satisfy a security questionnaire's checkbox. A real two-way sync costs a great deal more and is the version that can actually remove a 'no,' so ask which of the two the buyer meant before estimating either: a badge and a sync answer different questions and carry different bills. The broader case for depth as a category matures is the argument in In mature markets, integration depth beats feature count; the roadmap question here is narrower — which specific integration has accumulated enough evidence to justify the deeper, more expensive version, rather than whether depth matters at all.

A one-page test before it goes on the roadmap

A short test keeps enthusiasm from quietly becoming a roadmap slot:

Evidence: how many lost deals cite this integration by name in the write-up?
Verification: how many security questionnaires ask for it by name?
Demand: does the question show up with your sales team, your support queue, or in how AI assistants answer questions about your category?
Displacement: what comes off the roadmap to make room, and does that trade still read as right once it is written down?
Depth: does removing the 'no' require a badge, or a real data sync?

A single yes on the demand line is not enough by itself: a request that no lost deal and no questionnaire corroborates is a preference somebody stated, and a slot costs more than a preference is worth. The displacement line is the only one whose answer costs somebody something today, which is what makes it easy to leave blank. Going out and sourcing partners deliberately, rather than reacting to whatever arrived, is a separate exercise with its own checks, set out in how to choose ecosystem partners — it starts a step earlier than this test does, before there is a specific connector to argue about.

None of this removes judgment from the roadmap meeting. It just makes sure the judgment gets applied to evidence that would survive being written down, rather than to whichever request arrived most recently, or most loudly.