In large organizations, it is very easy to look at a product through the systems that support it. CRM owns the customer, billing owns the subscription, the payment provider handles the money, middleware moves information around, and another system activates the service. Each component has its own responsibility, its own team and its own metrics.
From the customer's perspective, none of that matters very much. The customer does not buy CRM, billing or an integration. They buy an outcome. If they paid for a service and did not receive it, the product is broken - even if every system along the way reports success.
That is why I have become increasingly interested not only in whether individual systems work correctly, but whether the entire journey between them works.
Every System Can Be Right And The Product Can Still Be Broken
Imagine a simple scenario. A customer buys a service. The order is correctly created in CRM, the payment succeeds, billing creates the subscription, and then an event is supposed to activate the service in another system. The event never arrives.
From the sales perspective, everything worked. Payments also report success. Billing shows an active subscription. The integration layer may even confirm that the message was sent. The customer sees only one thing: they paid and nothing happened.
This is a good example of why technical success at the component level is not the same as product success. You can have five healthy systems and still have a broken customer journey.
"Done" Depends On Who Is Looking
In a complex landscape, even a simple word like "completed" can mean several different things. For CRM, an order may be completed once it has been created. For payments, success means the money was collected. For billing, the process may be complete once the subscription exists. For the team delivering the actual service, nothing is complete until access has really been activated.
All of those definitions can be correct within their own domains. The problem starts when there is no shared definition of success for the customer's entire journey.
This is one of the reasons why the product often does not live inside a single system. It lives between systems, in the sequence of events that together are supposed to produce the outcome the customer expects.
Who Owns The Whole Journey?
This may be the hardest question. In a large organization, it is relatively easy to establish ownership of individual components. One team owns CRM, another billing, another integrations, another payments. Each team has its backlog, roadmap and operational responsibilities.
But who owns this outcome: the customer bought the product, paid for it and actually received the service?
If the answer is "everyone", it can easily mean that nobody truly owns the whole thing. Every team can correctly complete its own part of the process without noticing that the customer journey has failed somewhere in between. That does not necessarily mean any team did poor work. The problem may simply be a lack of end-to-end ownership.
And that is often more of an organizational problem than a technical one.
Monitoring Systems Is Not Enough
Most engineering teams are reasonably good at monitoring applications and infrastructure. We know whether an API is responding, whether a queue is healthy, whether a database is available and whether a payment service is returning acceptable response times.
All of that matters, but it is not enough. From a product perspective, more interesting questions might be: how many customers have successfully paid but still do not have an active service ten minutes later? How many orders exist in CRM without a corresponding subscription? How many successful payments never triggered the downstream process? Where do customers most frequently get stuck between two stages?
That is a different level of observability. We are no longer monitoring only whether the system works. We are monitoring whether the product delivers the expected outcome.
Integration Is Part Of The Product Too
Integrations are often treated as technical plumbing. Something invisible to the customer that should simply work. That is true only until it stops working.
If activation of a service depends on a particular event, handling that event is no longer just a middleware concern. Retries, idempotency, reconciliation and error handling directly affect the customer experience.
You can therefore have an excellent frontend and perfectly healthy billing and still deliver a bad product if the flow between them is unreliable. This is also where technology and product become difficult to separate. Deciding how the system should behave during a partial failure is both an engineering decision and a product decision.
Eventual Consistency Has A Product Side Too
Distributed architectures often assume that different systems will not share exactly the same state at exactly the same moment. Technically, there is nothing unusual about that. Eventual consistency is a natural characteristic of many modern systems.
The problem is that customers do not think in terms of eventual consistency. If they paid, they expect something to happen.
We may know that the state will synchronize in thirty seconds, five minutes or an hour. Technically, the system may be behaving exactly as designed. The more important product question is: what does the customer see during that time?
Do they see a clear "processing" state? Do they know their payment was accepted? Can they accidentally click the button again and repeat the operation? Can customer support see exactly where the process stopped?
Suddenly, something as simple as a "processing" state becomes part of the product architecture, not just a detail of the user interface.
Customer Journeys Cross Team Boundaries
One reason this problem is difficult is the way organizations are structured. Systems have owners. Customer journeys often cross several of them.
The CRM team optimizes its area. Billing does the same. Payments does the same. Every system can have excellent KPIs and strong reliability, while the customer still experiences all of them as one product.
It is a little like a relay race. Every runner can perform their section perfectly, but if the baton is dropped during the handover, the team's result is still poor.
In enterprise systems, those handovers happen at the boundaries between systems, teams and responsibilities. And that is exactly where many problems appear that are invisible when we look only at individual components.
A Product Needs Its Own Definition Of Success
That is why, alongside system-level metrics, I believe we also need metrics for the product as a whole.
Not only API availability, payment success rate or the number of processed events, but also questions such as: what percentage of customers actually completed the entire journey? How long does it take from purchase to activation? Where does the process stop most often? How many cases require manual intervention? Did the customer ultimately receive the outcome they expected?
That changes the conversation. Instead of asking "Which system failed?", we can start asking: "Where did the product stop working?"
That is usually a much more useful question.
Final Thoughts
Architecture naturally divides the world into systems, domains and responsibilities. We need those boundaries because without them, large solutions would quickly become impossible to maintain.
Customers do not experience those boundaries. They do not care which team owns billing, where CRM ends or which middleware handled their order. They experience one service and one outcome.
That means a healthy CRM, a healthy billing platform and a healthy payment service can still combine to create a broken product.
The product does not live only inside the systems. It also lives in the journey between them.