fbpx
DigitalFeaturedMarketingOpinion

Why high-stakes digital products fail and why you’ll be blamed for it

November Five's Darius LaBelle calls for the empowering of product owners in the chair, measuring trust signals, task completion and recovery, and treating the operating model as part of the product.

Darius LaBelle, Managing Director – Middle East, November FiveDarius LaBelle, Managing Director – Middle East, November Five

When a bank’s new app crashes during a payment, when an airline’s check-in collapses on a Friday evening, when a telco onboarding flow breaks on the third step, the blame finds a face quickly. Product. Technology. Experience. Brand. Whoever’s name is closest to the thing gets the call.

That’s where the real frustration inside enterprises lives today. The people accountable for the outcome are rarely the same people who controlled the decisions that shaped it.

High-stakes digital products, the ones customers rely on when money moves, identity is verified, or a service has to work first time, are operating model decisions disguised as software. The customer experiences one app, one journey, one moment of truth.

Behind the screen sits a web of teams, vendors, compliance checks and service recovery paths that all have to hold together in real time. The product is the sum of how those pieces coordinate. Enterprises consistently treat the coordination as someone else’s problem and the app as the deliverable. That gap is where most of them go wrong.

The Gulf is feeling this acutely. PwC’s 29th CEO survey points to major state-led AI and digital infrastructure commitments across Saudi Arabia, the UAE, Kuwait and Qatar, all aimed at making the region a serious digital-services hub. Investment at that scale raises expectations. Every product that emerges will be tested against them.

Across MENA, the pattern repeats. A bank launches a polished onboarding journey, but the identity flow depends on fragmented back-end checks with no shared recovery path. A real estate platform promises a seamless resident experience, yet payments, service requests and access control sit in different systems with different owners. An airline relaunches its app, and customers immediately discover that booking, loyalty, disruption handling and refunds are still different products wearing one logo.

The output feels incoherent because the organisation is incoherent. The team didn’t build a product. They shipped the org chart.

That’s the structural mistake underneath most high-stakes failures in this region, and it expresses itself in three familiar ways.

They design around the organisation: Each function optimises its piece. Handoffs between vendors, teams and regulators become the sharp edges the user feels. The product looks coherent in a steering committee deck and fractured in the wild. No one owns the customer consequence because no one’s role was written to.

They confuse governance with decision-making: High-stakes products need clear trade-offs. Someone has to decide what matters more when friction, risk, regulation and commercial pressure collide. In many enterprises, that decision gets escalated, diluted, delayed, or turned into consensus theatre. The product becomes the residue of unresolved internal politics.

They treat launch as the finish line: The launch deck is polished, the press release goes out, the app is in market, everyone moves on. For high-stakes products, launch is where the real design work begins. It’s when internal assumptions meet edge cases, when exception volumes spike, when staff quietly build manual workarounds, and when trust either gets reinforced or leaks out of the system.

AI will not rescue any of this. The promise of AI-enabled delivery is that intelligent systems compress cycles and raise quality. Deployed onto a fragmented operating model, AI surfaces the fragmentation faster.

The organisations getting this right are doing something less glamorous than launching new platforms. They put an empowered product owner in the chair, with real authority across design, data, engineering, risk and service operations. They build exception handling with the same seriousness as the happy path. They measure trust signals, task completion, and recovery, alongside release velocity and adoption headlines.

They treat the operating model as part of the product. Because it is.

The people who get the call when a product breaks need to be the same people who shaped how it was built. Until that happens, enterprise teams will keep mistaking internal progress for external success.

By Darius LaBelle, Managing Director – Middle East, November Five