380+ integrations, and most users never finished setting one up

The context

A product that connected advertising platforms to business tools. When a potential customer came in from Facebook, Google, or TikTok Ads, the product moved their information to the right place automatically. No code, no manual work, no lost leads.

380+ integrations, a growing base of marketers and agencies who relied on it daily. To set up a connection, users went through five steps: pick the source, pick the destination, log into both, match the data fields, and activate. The product worked well. The problem was that too many users never made it through the setup.

The challenge

Users came in with a clear goal — they knew what they wanted to connect — but a disproportionate number gave up before finishing. The two biggest walls were logging into the platforms (every integration had a slightly different authentication process, each with its own ways to fail) and matching the data fields (a flexible but overwhelming screen where every field could be manually paired with any other).

Advanced users loved the flexibility. Everyone else stared at the screen and left.

The product had grown feature by feature, adding options at every step to satisfy the loudest requests. The result was a setup flow that could technically do anything — and practically scared off most users before they reached the end.

The approach

The first step was understanding where people actually got stuck. Not where we assumed they got stuck. I mapped the full funnel with completion rates at every step, cross-referenced with support tickets and session patterns. The data confirmed what the numbers suggested: configuration and mapping were the walls. But it also revealed something less obvious — users who completed their first bridge went on to create an average of three more. The activation barrier was the only barrier.

Then came the counterintuitive decision: remove features. The advanced options panel — conditional logic, custom transformations, multi-step field processing — was visible to every user on every bridge. It added cognitive load to a flow that most users needed to be simple. The proposal was to hide it entirely from the default experience and surface it only for users who explicitly needed it.

The resistance was immediate. The advanced options were a selling point in demos. Sales used them to differentiate from competitors. Support had built documentation around them. Removing them from the default view felt like removing a feature. The argument that won: we're not removing capability, we're removing friction. The options still exist. They just stop punishing users who don't need them.

Field mapping got the same treatment. Instead of presenting an empty canvas where users manually connected fields one by one, the redesigned flow proposed automatic mappings based on field names, types, and common patterns across the integration catalogue. Users could review and adjust — but the starting point was a working configuration, not a blank screen.

This wasn't just a UI change. It required rethinking the data layer. The auto-mapping engine needed to understand field semantics across hundreds of integrations with different naming conventions. I worked with engineering to build a matching algorithm that used field metadata, historical mapping patterns from successful bridges, and type compatibility. The technical work made the simple UI possible.

The rollout was gradual. We didn't flip a switch for everyone. The new flow went to new users first, while existing power users kept the original experience. We measured completion rates, time-to-first-bridge, and — critically — whether the simplified flow produced bridges that actually worked in production. They did.

The results

What I learned

The hardest product decisions look like you're taking something away. Removing visible options from a flow feels like regression — especially when those options exist because customers asked for them. But there's a difference between what users ask for and what users need to succeed. The data was unambiguous: most users needed a simpler path, and the minority who needed complexity could handle one extra click to find it.

The second lesson was about defaults. A blank field mapping screen and a pre-filled one lead to the same place. But the pre-filled version communicates "we understand your use case" while the blank one communicates "figure it out." The product's job is to encode knowledge, not just provide tools.

The third: working as a Product Owner under a founder who gave real autonomy was the best possible training ground. I owned the full cycle — research, design, specs, delivery, measurement — with a senior partner who challenged assumptions but didn't override decisions. That dynamic taught me more about product judgment than any framework.

Transferable patterns