The invisible product: Why operational design matters as much as UX

Product teams spend a lot of time designing what customers can see. We debate layouts, navigation, copy, error messages, and the number of steps in a journey. We test prototypes, study abandonment, and optimize conversion.

All of that matters. But in complex products, especially in financial services, a big part of the customer experience is created somewhere the customer never sees.

It happens in decision engines, operational queues, servicing processes, policies, handoffs, compliance controls, payment systems, and the connections between them.

A customer can go through a beautifully designed digital experience and still leave frustrated because:

• An application moves into manual review with no explanation
• A document is requested twice
• A status does not change for several days
• One system does not seem to know what another already knows
• Support gives a different answer from the website

The interface may be working exactly as designed. The product is not.

This is what I think of as the invisible product: the operational machinery behind the customer experience. And it deserves just as much product thinking as the interface.

Customers experience one product

Earlier in my career, I tended to think about digital experiences mostly in terms of the journey the customer could see. Over time, especially through work on lending products and later large-scale integration work involving Capital One and Discover, that definition started to feel incomplete.

Take a lending application. From the customer's perspective, the journey may seem simple:

Apply -> get a decision -> provide information -> accept an offer -> receive funds

Behind those steps may sit identity verification, fraud checks, credit decisioning, pricing, document validation, regulatory disclosures, servicing, communications, exception handling, and manual operations.

Internally, those capabilities may belong to different teams and systems. The customer doesn’t care. If one piece fails, they don’t think, “The digital experience was good, but the operational workflow was poor.” They simply experience a frustrating product.

Companies organize around systems and ownership boundaries. Customers experience one product.

A good screen can hide a bad process

Consider a customer who sees this status:

Your application is under review.

That sounds reasonable. But internally, “under review” could mean an automated check is running, information is missing, a case is sitting in a queue, or the customer needs to take action.

The product challenge is not simply to improve the wording. It’s to translate operational complexity into something useful.

A good status experience should answer three questions:

• Where am I?
• What’s happening now?
• Do I need to do anything?

To answer those questions well, product teams need to understand what is happening behind the screen. That’s operational design.

Complexity has a habit of leaking

Most organizations don’t set out to create complicated products; complexity accumulates over time.

A new regulation adds a control. A new risk policy adds a verification step. A new vendor introduces another integration. An acquisition brings another set of systems and processes. Eventually, internal complexity starts leaking into the customer experience:

• Customers are asked for information the company already has
• Different channels provide different answers
• Simple processes take longer than expected
• Employees rely on manual workarounds
• Exception cases bounce between teams

At that point, adding another message or another process step rarely solves the real problem. Sometimes the operating model itself has become part of the product problem.

What integration work taught me

Large-scale integration work makes this especially visible. 

While working on integration efforts involving Capital One and Discover, one thing became very clear to me: integration is not simply a technology exercise. 

Teams have to examine customer journeys, policies, operational workflows, regulatory requirements, servicing models, data, and technology dependencies. At that scale, there can be thousands of individual changes, and it becomes impossible to treat each one as an isolated requirement.

You start asking different questions:

• Which changes materially affect customers?
• Which create operational or regulatory risk?
• Which processes depend on one another?
• Which differences actually matter?
• Which exist simply because “that’s how we’ve always done it”?

The most important question is often: What should the future experience actually be?

That question is easy to lose during a transformation. A team can become so focused on moving a process from one system to another that it recreates the old operating model on new technology.

Instead of asking only, “How do we migrate this process?”, product teams should also ask:

• Why does this process exist?
• Does the customer still need it?
• Does the business still need it?
• If we were building this today, would we design it the same way?

That turns integration into a product-design opportunity, not just a migration exercise.

Four layers of operational design

I find it useful to think about operational design in four layers.

1. Customer intent

Start with what the customer is trying to accomplish, not the screen they are on.

For a lending customer, the real questions may be:

• Do I qualify?
• What information do you need?
• How long will this take?
• What are my options?
• What happens next?

Those needs should anchor the design.

2. Decision logic

Next comes the machinery that determines what happens: eligibility, pricing, risk, verification, fraud controls, regulatory requirements, and exception logic.

The goal is not to make all of this simple. Some products are genuinely complex. The goal is to avoid transferring that complexity unnecessarily to the customer.

This is also where technology architecture becomes product strategy. Customers don’t care whether an API or event-driven service makes an experience faster. They care that they did not have to wait.

3. Operational execution

Operational employees are users of the product too.

When automation cannot complete a journey, someone has to handle the exception. That person needs the right context, the right tools, and a clear way to resolve the issue.

If an employee has to open six systems, reconcile conflicting information, and maintain a spreadsheet to complete a routine task, that is more than an operational inconvenience. It’s product debt. Eventually, the customer pays for it through delays, errors, repeated requests, or inconsistent answers.

4. Communication

Finally, the product needs to explain what is happening.

Customers don’t need to understand your systems or workflows, but they do need answers to a few basic questions:

• What happened?
• Why did it happen?
• Do I need to do anything?
• What happens next?

Customers can handle complexity better than we sometimes assume. What they struggle with is unexplained complexity.

Edge cases are still product experiences

Product teams naturally spend most of their time designing the happy path. But mature products are often defined by what happens when that path breaks.

What happens if verification fails? If information conflicts? If the customer comes back three days later? If a downstream service is unavailable? If additional review is required?

We often call these edge cases. At scale, that term can be misleading. Even 1% of customers can represent thousands of people.

Those customers often need more clarity, not less. Exception paths should therefore be treated as real product journeys, not as leftover scenarios for operations or QA to figure out later.

The goal is not to eliminate every exception. It is to make sure the product knows what to do when reality doesn’t follow the happy path.

Product managers should go behind the curtain

One of the most useful things a product manager can do is leave the digital journey for a while and follow what happens behind it.

Sit with operations teams. Listen to customer service calls. Follow a difficult case from beginning to end. Look at where work piles up. Find the spreadsheets and email chains people have created to keep things moving.

Those are often clues to the real product problems. Analytics can tell you where customers abandon. Operations can often tell you why.

Once you start looking at the product this way, operations stops feeling like something that happens after product design. It becomes part of product design.

The best operational design is invisible

Customers should not need to understand your org chart, which system owns their information, or where one platform ends and another begins.

A well-designed product absorbs that complexity.

When operational design works, information appears where it should. Decisions happen when expected. Employees have the context they need. Exceptions are explained. Customers know what happens next.

The machinery disappears, and that’s the point.

Product teams should not stop asking, “What should the customer experience look like?” But they should also ask: “What has to be true operationally for that experience to actually work?”

The best products answer both questions together, because customers don’t experience our systems, teams, policies, and workflows separately; they experience one product.