Building Complex Products Made Me Think Differently About Solutions and User Journeys

One thing I continue to think about while working on complex products is how differently organizations and customers experience software.

Organizations naturally create structure. Teams form around ownership, roadmaps form around capabilities, and products eventually become collections of solutions. This makes sense. Ownership creates accountability, helps teams scale, and creates clearer boundaries for investment and decision making.

Customers rarely experience products this way.

Customers experience problems, workflows, frustrations, and goals. They are usually trying to accomplish something, and in many cases, they do not necessarily care which product area, solution, feature, or team boundary they crossed along the way.

The larger and more complex the system becomes, the more visible this tension becomes.

I started noticing this while working on experiences that crossed multiple workflows, reports, controls, policies, and data sources. Sometimes what looked like a single customer goal on paper involved multiple experiences underneath it, each with their own assumptions, terminology, dependencies, and navigation patterns.

At some point, I realized that what customers were trying to accomplish rarely resembled how the experiences themselves were organized.

The customer journey did not resemble the navigation.

The customer journey did not resemble solution boundaries.

Instead, it felt more like nested systems where solving one problem naturally revealed another layer underneath. A workflow opened another workflow. One decision introduced new dependencies. Completing one task often required understanding systems that were never originally intended to feel connected.

That observation changed how I think about user journeys.

For a long time, I viewed journeys primarily as alignment artifacts. They were useful for research synthesis, storytelling, or helping teams align on flows.

Increasingly, I think they are much more foundational than that.

A good journey forces uncomfortable questions.

Where does the customer actually begin?

Where does complexity become visible?

Where are customers required to understand organizational structure simply to accomplish a goal?

Where do ownership boundaries accidentally become product boundaries?

The places where these seams leak the most are usually the navigation shell and the cross-surface action — which is why I keep coming back to two specific artifacts. The Three-Tier Shell Navigation Prompt is about giving the chrome a structure that does not force customers to map team ownership onto the left rail. The Idempotent Bulk Action Pattern is about the moment a single customer goal — upgrade this, enroll that, apply baseline — gets surfaced from six different places by three different teams, and ships as five different buttons. Both are small artifacts. Both exist because the organizational seam is the part customers feel first.

I do not think organizing around solutions is inherently wrong. Complex products require structure. But I increasingly wonder whether the more important challenge is ensuring customers do not need to understand the structure we created internally.

That turns out to be much harder than simply creating another solution.