Solve Real Workflows That Cross Multiple Product Markets

The other day, I was looking into a company I’m interviewing at and happily noticed that their primary BaaS product did two things I admire: they prioritized complex permissions, and they supported holistic, cross-product-market user journeys. Those two traits usually signal a team that actually understands how the work moves, not just how the market is divided.

It struck me that it was a pretty rare accomplishment considering how treacherous API relationships can be… fragile, slow, and always one vendor update away from breaking.

The trouble starts much earlier, in the way companies structure their thinking: segments become use cases, use cases become product categories, categories harden into markets, and then those markets end up reinforcing the segmentation all over again.

It’s a cycle that makes organizational sense, but it often gets in the way of developing for human use; an outcome of silos, scale, and the gravitational pull of shareholder demands.

Think about something simple like registering your car. Even though each step is defined by a different institutional domain (insurance, state systems, emissions testing, payments, ID verification), you still experience it as one task. The workflow crosses markets because the work itself crosses domains, but most products behave as if each domain were a sealed world of its own.

It’s so tempting to constantly optimize for perfection inside “known” problem spaces instead of coherence across the workflow. Designing to chase depth even when users urgently need reach. You see this everywhere: CRM tools adding more advanced reporting while ignoring the handoff to billing, or project-management platforms perfecting task hierarchies while leaving resource planning untouched. And later, they’re surprised when a different product grows around them simply by following the real direction of user motion.

The strongest growth advantage today is solving the real workflows that cross multiple product markets. Because that’s where the real friction lives, and where users feel the difference immediately.

Collaboration is rarely the default in environments shaped by ownership lines, team boundaries, and competing incentives. But cross-market workflows align with how people actually live inside their work. The seams between markets are where users feel the most fragmentation, carry the most cognitive load, and lose the most time. These seams are also where no single vendor “owns” the experience, so whoever clarifies that seam first wins trust, momentum, and, importantly, adoption.

Stripe is a good example of this. It began in payments, a neatly defined category. But the moment you collect a payment, you trigger a sequence that crosses half a dozen markets: identity verification, fraud inspection, tax calculation, billing logic, payout workflows, revenue analytics, treasury management. 

Image from 2023 WhiteSight.net


Stripe expanded to users already moving through adjacent surfaces. It followed the workflow, not the product category, and in doing so, it became infrastructure.

Users want coherence across the workflow far more than they want perfection of kind. I’ve seen this in research for years. Teams deprioritize onboarding, permissions, billing, role management… anything that lives in the seams between systems. Fixing them requires crossing institutional boundaries. Yet these are the very pain points users raise repeatedly and urgently. They don’t care which team or vendor “owns” the surface. They just need the work to make sense end-to-end. Whether the boundary is organizational or architectural, users experience it the same way: as friction.

The point of a service is to reduce the burden. In this case, what users carry stitching their own workflows together out of tools that were never designed to cooperate. When companies do that well, market dominance follows as a consequence, not the strategy. Cross-market expansion works when it removes friction between the domains users already have to move through. Anything else just adds more surface area without reducing the load.

Cross-market expansion is not automatically good, of course. Misapplied, it’s one of the fastest ways a product loses its internal coherence. You see this in project-management tools that bolt on CRM-lite features; the surface area grows, but the user’s burden doesn’t shrink. Expansion for the sake of “more market,” to match a competitor, or to fill an empty roadmap isn’t a strategy…  it’s drift. 

The distinction is simple: cross-market expansion works when you understand the motion of the work. It fails when you chase markets instead of workflows.




Next
Next

I Wrote This Myself: How to Mean It in the Age of AI