From Six-Month Sprints to Drag-and-Drop

Most customer journey platforms don't use product data. They use marketing data. Open rates. Click-throughs. Maybe a segment based on what plan someone's on. That's not a journey. That's a drip campaign with extra steps.

I know this because I spent years doing it the hard way. I was embedded at Yahoo, helping architect growth programs that actually used product behavior. Not email opens. Not click-throughs. Real in-product signals, stitched into flows that responded to what people did across a portfolio of properties with hundreds of millions of users.

It worked. It was also a lot to get it out the door. Every flow needed solutions architects, eng sprints, daily standups, and months of coordination before a single notification went out. The notification logic was the easy part. The organizational overhead was the bottleneck.

What "behavior-based" actually meant

Our team had something most teams didn't: deep first-party product data across a massive portfolio of properties. We weren't guessing what users cared about based on email engagement. We had real behavioral signal, and we could build growth loops around it. Branch on content affinity. Session frequency. Cross-property behavior. Time-of-day patterns. The decisioning was genuinely sophisticated.

But every one of those growth patterns was a project. I'd help scope the strategy and messaging architecture, then hand it to engineering to wire up the data pipelines and build the triggers. A single program could take months from concept to first send. Change the branching logic? That's another sprint. Add a new channel? Start the coordination cycle over.

The team was ahead of its time in what it could do. The gap was in how long it took to do it.

The rest of the market was worse

Most teams were running what they called "customer journeys" on marketing platforms. Those platforms are good at sending batch campaigns. But what they do for journeys, is decision off marketing engagement data and profile attributes.

Did they open the last email? What segment are they in? When did they fill out the form? That's the data driving the flow.

There's nothing wrong with that for marketing campaigns. But it's not a product journey. Marketing platforms see the marketing layer. Product behavior lives somewhere else, and connecting the two has traditionally been an engineering project.

So most teams pick one: marketing engagement flows that are easy to build but shallow, or product-aware flows that are powerful but take months and a dedicated team to ship.

What changed

Two things happened.

First, the data layer matured. CDPs like Twilio Segment made it dramatically easier to collect product events and route them wherever they needed to go. Behavioral data stopped being locked inside product databases. It became portable. But it only solved half the problem. Most platforms on the receiving end weren't built to do anything meaningful with that event feed beyond triggering off a single event.

Second, the orchestration layer caught up. Notification platforms started treating product events as first-class triggers, not just webhook payloads you have to transform and pipe into a separate system.

Courier's Journey builder is the clearest example of this I've seen. You define your product events, your user profile attributes, your channel preferences, and then you build flows on a visual canvas. Drag in a trigger. Add a branch based on user behavior. Set a delay. Send to email, push, SMS, in-app, Slack, or whatever makes sense for that phase of the user flow. The logic that used to require eng sprints and solutions architects is now a drag-and-drop workflow that a PM or growth manager can build and iterate on without filing a ticket.

And it handles product notifications, marketing messages, and transactional alerts in the same system, across the same channels, with the same routing and preference logic. One platform that treats all of those as notification types with different rules, not fundamentally different infrastructure, eliminates an entire category of coordination work.

What actually matters now

Branch on product data. Product behavior, preference signals, cross-channel engagement history. That used to be a data engineering project before you could touch the flow. Now the orchestration layer ingests product events natively and the conditions actually have something to work with.

AI in the flow. Drop an AI node into the workflow to enrich profiles in real time, drive branching decisions based on behavioral patterns, and generate bespoke content per user, per channel, per context. Not "insert first name." Actually personalized messaging, at scale, without a team of people manually segmenting and writing variants.

Channel orchestration with fallback. Send push first. Wait an hour. If they didn't open it, fall back to email. If email bounces, try SMS. That routing used to be custom code.

BYOP. Courier sits on top of your existing providers. You're not ripping out existing delivery systems. You're adding orchestration on top of what you already have.

The real shift

The story of customer journeys isn't about better UIs. It's about who has access to the right data and who can act on it without a standing meeting.

When I was at Yahoo, the data existed. The strategy existed. What didn't exist was a platform that let non-engineers build and iterate on flows powered by product behavior. So we staffed up and built impressive programs slowly.

The infrastructure layer now handles the hard parts: data ingestion, channel routing, provider management, preference logic, delivery guarantees. Teams that used to need months and a cross-functional squad to launch a lifecycle program can do it in days. Not because the problems got simpler, but because the tooling absorbed the complexity.

That's what I would have wanted back then. Not a better marketing platform. A notification infrastructure layer that understood product data natively and let the people closest to the user experience build and ship the flows.

That's what Courier built.