From Products to Customer Needs. How Teams Change the Way They Work

The earlier redesign addressed autonomy. The mobile bank had to become a superapp for several business lines. With one team and one queue of priorities, a business line had to wait for its changes to reach the top. A common platform gave product teams more freedom, while platform teams continued to look after the shared components.

I use this as an example of the inverse Conway maneuver. We started with a business goal, worked out what architecture could support it, and used that to draw team boundaries. Once the new setup was working, we could follow changes across those boundaries and revise decisions when we ran into constraints. The next redesign addressed a different problem. Product teams could work more independently, but some customers needed several teams' products to work together.

Several banks can offer a cashback card, a loan, or a way to invest. Even inside the same bank, deposits and investments can compete. A customer sees both as ways to use their savings. Two managers may each count the same money toward a different product goal.

A car purchase makes the dependencies easier to see. The customer saves for a down payment, chooses a car, finances the rest, and buys insurance. Each team sees one step. An insurer might turn down an expensive car or quote a high premium because its model predicts a loss. That can be sound for the insurance business and still derail the purchase other teams have helped the customer put together.

In a connected journey, the selected car, its price, and the down payment carry over from one step to the next. The company has to decide where that context lives and who can make a decision when the interests of one product diverge from what the customer needs to complete the purchase.

A product team that once delivered a standalone service now needs to make parts of that service available to a wider journey. The integration needs time on the team’s roadmap. The technology platform has a different job. Even when all steps are connected behind the scenes, changes in interface patterns and confirmation steps can still make the customer feel as if they are moving between separate products.

In my unit, client interfaces and the digital ecosystem already had separate responsibilities. One group provided shared capabilities for the application and the other worked on how customers moved through it. An end-to-end journey needs both. Architecture determines what can connect, process determines how teams agree on the work, and team boundaries determine who can take it on.

The 2025 redesign introduced segments to account for differences between customers with similar needs. Someone who needs a car immediately may take out a larger loan. Someone who can wait may save a bigger down payment and reduce the monthly payment. Segmentation matters when it changes the offer. The company also needs to be able to manage the number of distinct offers it creates.

I use a separate hypothetical example to explain the economics. A deposit with a 60% chance of take-up and a net present value (NPV) of 5,000 if taken up contributes an expected 3,000. An investment product contributes 2,000 at 25% of 8,000. A life insurance policy contributes 1,500 at 10% of 15,000. In this simplified model, they add up to 6,500 in expected lifetime value.

This estimate changes how much a business might spend to acquire or serve the customer. One product can earn less if it helps the customer use others. The probabilities also need revisiting when conditions change. A restriction on lending or a narrower choice of investments can reduce the estimated lifetime value even if the customer’s underlying needs stay the same.

I rotate a projection of a four-dimensional cube on one slide. At one point it brings together families with children, the need to preserve savings, deposits as a product, and mobile banking as a technology platform. Each area has its own managers. Someone still needs to decide what the combined offer looks like and whose agreement they need to put it in place.

What I saw in 2025 and 2026 was a long discussion after the reshuffle about what each manager owned and whose help they needed to deliver specific work. Changes on the business side led to changes in engineering. Several management habits carried over, and some decisions took more negotiation. The complexity of the model showed up in the cost of doing everyday work.

I would go back to one journey and ask three questions. What customer need can we see more clearly now? Which decision can we make faster, more easily, or with fewer approvals? What changed in the way teams work together and in what the customer experiences?

To answer those questions for a car purchase, trace whether the selected car carries over to lending and insurance, who handles a refusal, and who can make a decision for the purchase as a whole. That gives you something concrete to study before making another change to the structure.