Every integration looked different on the roadmap

Integrate made software for marketing teams at large B2B companies. Much of its value came from connecting to the many systems those teams used to generate and manage marketing and sales data. That created a recurring problem. A new customer might rely on a platform we didn't integrate with yet, and there was a long tail of smaller systems, far too many to build for in advance. We found out which one we needed when a customer signed.

When that happened, the customer couldn't finish onboarding until the integration was built, tested, and in production. Customers already had a configuration layer for managing their integrations themselves, but we couldn't offer it until we'd built the integration underneath. To shorten their wait, I'd pull the product team off its current work, including features we'd promised other customers and stakeholders. Sales and Customer Success felt it from both directions: new customers waiting to start, existing customers waiting on commitments that had slipped.

Everyone had come to accept this as the cost of winning new business. Nobody blamed product for it. People understood why we kept making these self-inflicted roadmap pivots, because each one came with a clear reason: a specific customer, a signed agreement, a start date. Each was worth doing on its own. Over about two years, they added up to more than six months of roadmap time.

It looked unsolvable because we treated it as a prediction problem. We couldn't know which system the next customer would need, so we couldn't get ahead of it.

What changed my view was ordinary. While researching new integrations, I'd used Postman a few times. It's a tool for sending requests to another system's API without writing code first, and a quick way to check whether the documentation matches what the system actually does. After a few hours of reading and trial and error, I could get an integration working by hand. That raised an obvious question: if I could do that in a few hours, why couldn't our engineers have tools that made building the real thing nearly as quick?

I went back through the last few integrations we'd built. The specifics changed every time, but the core steps were the same: authenticate, authorize, read data, write data. I took that to the engineer who led our integration work and asked whether we could separate those common steps from the details unique to each system. We agreed it was feasible, and that with the common steps handled once, the unique part of each new integration could come down to a few days of work.

We still couldn't predict which integration a customer would need next, but if every integration got cheaper, that mattered much less.

It also meant asking for another delay, this time to build a tool only our own engineers would use. I went to the leaders of Sales and Customer Success first. They were living with the consequences of the current approach, so their support would carry weight with everyone else. The people with the most reason to object to another delay also had the most reason to want this one. They agreed it was worth one more delay to get fewer delays afterward and new customers onboarded sooner. With their support, I took the proposal to the leadership team and got approval to change the product team's upcoming work. I called what we were building the integration builder.

As the first version neared completion, a new customer was about to be onboarded, and their agreement included an integration with a system we'd never connected to. We had a test plan for the builder. I asked the team to set it aside and build that customer's integration as the first real test instead. As a way to put the builder through its paces, it was hard to beat.

The team had a working integration far sooner than the old approach would have allowed. Over the following months, they took on more integration requests without pushing planned roadmap work aside, and Customer Success no longer had to tell new customers to wait for an integration before onboarding could begin.

Each system still had its own quirks, and that part still took real work. What went away was rebuilding the common steps every time.

I wouldn't turn every recurring request into a tool. A few things made this one a reasonable bet. We couldn't build ahead, because we couldn't predict the requests. The repeated part was most of the job. An engineer who knew the work thought the split was practical. And a real integration was on its way to test it against. Without conditions like those, "we keep doing this" can justify a lot of machinery nobody needed.

Looking back, it's interesting that the pattern was hard to see. The roadmap listed real customers and systems, but it described integrations by name, so every one of them looked new. It's a case where being very close to the work was a prerequisite for having the insight.