Enable javascript in your browser for better experience. Need to know to enable it? Go here.

Perspectives: Edition #38 | October 2025

 

From rescue to resilience: AI's role in product futures

 

In this edition of Perspectives, our experts examine how AI is reshaping product lifecycles — from rescuing underperforming offerings to building resilient, future-ready innovations.

 

Read time: 14 minutes | Short on time? View executive summary >

 


Contributors

 

Chris Westerhold
Global Practice Director - Engineering Excellence, Thoughtworks

 

Rickey Zachary
Global Engineering Platforms Lead, Thoughtworks

 

Ahmet Sakar
Global Head of Tech for CX & Product Innovation, Thoughtworks

Key highlights

 

  • AI is redefining product rescue — shifting it from last-ditch recovery to a proactive path toward resilience and growth.

     

  • Common product pitfalls like unclear goals, siloed teams and rushed processes can be prevented — if empathy, governance and shared vision are built in early.

     

  • The Loops framework helps diagnose where friction occurs (engineering, business processes, or customer experience) and guides targeted interventions.

     

  • Metrics matter — from engineering DORA benchmarks to business outcomes, transparent measures ensure teams focus on impact, not just output.

     

  • AI offers uplift across the lifecycle — from automation and better testing to customer insights, faster experiments, and tackling legacy complexity.


Pressure to create, and iterate 

 

From better apps to exciting new experiences, enterprises face massive pressure to launch, iterate and improve products as technology evolves, and customer expectations, channels and competition proliferate. An overwhelming need to accelerate is straining teams, capabilities and budgets, with one poll finding over 80% of those on the development frontlines are constantly seeking ways to compress timelines.

 

It’s perhaps no coincidence that consumers are increasingly frustrated by product failures.  

 

Product developers need speed

Source: Protolabs

The rise of AI is ramping up the stakes even further. “The cost of knowledge has essentially dropped to zero, and it’s never been easier to create a SaaS product,” says Chris Westerhold, Global Practice Director - Engineering Excellence at Thoughtworks. “As choices have exploded, the bar for quality and to get market share has gone up. Rightly or wrongly, many incumbents got complacent and let their products suffer, and are starting to lose share as a result.”

 

“What was valid in the 90s wasn't good enough in the 2000s because cloud started,” Ahmet Sakar, Global Head of Tech for Customer Experience and Product Innovation at Thoughtworks, says. “Now it's AI that means what worked in the past doesn't work anymore. You might have invested a lot of money and done everything right with your product development methodologies, but still have a product that requires rescue, simply because it’s not as valid as it once was.” 

 

AI-led shifts will make more product innovation, and rescues, essential – but will also provide new ways for organizations to supercharge development, track product performance and build better.

 

“If you're not able to secure your engineering foundations and use AI to mature your practice so you can get things into the hands of your customers as quickly as possible, you’ll quickly get out-competed by the other businesses in your industry vertical,” Rickey Zachary, Thoughtworks’ Global Lead of Platform Engineering, says. “The whole trend of hyper-personalization means you need to be able to collect the right user telemetry so you know your product is trending upwards from an impact perspective - or whether an experiment should be abandoned.”

If you're not able to secure your engineering foundations and use AI to mature your practice so you can get things into the hands of your customers as quickly as possible, you’ll quickly get out-competed by the other businesses in your industry vertical
Rickey Zachary
Global Engineering Platforms Lead, Thoughtworks

Preemptive problem-solving

 

One of the best ways to address product rescue is to ensure a rescue isn’t needed in the first place. Product problems are often embedded at the earliest stages of design, implementation or even both, and typically fall into a few categories: 

 

Design flaws rooted in poor communication. “Just like the telephone game, the more times you pass something on, the worse it tends to get,” says Westerhold. “Engineers, product managers and/or end users may all have different points of view on the problem the product is solving, or what it’s designed to do.”   

 

Design without empathy. Most people have experienced being irritated by a product that demonstrates a fundamental lack of consideration for the end user, whether it’s an app that makes constant permission requests or website with excessive pop-ups. Yet for whatever reason, “we often don’t remember these bad UX experiences or pain points when we design or update something ourselves,” Sakar notes. 

 

In successful product management, empathy is often the missing ingredient. “Some companies run customer empathy sessions with developers so that they can understand how users are feeling,” Sakar explains. “That’s meant to prevent something from needing rescue. If you don't know the end user, you're always going to be stuck in tech innovation, rather than holistic business or product innovation.”  

If you don't know the end user, you're always going to be stuck in tech innovation, rather than holistic business or product innovation.
Ahmet Sakar
Global Head of Tech for CX & Product Innovation, Thoughtworks

Limited vision and leadership – and a lack of clear targets as a result. In some businesses, there is an absence of real direction from a product perspective – “things like lean value trees, clarity on the vision, the goals that you want to hit and the metrics associated with them,” says Westerhold. 

 

If the overwhelming incentive is to build to a certain budget or timeline, developers are likely to focus on getting the project done within those boundaries, with little thought given to business value. “In the project mindset, you get a scope, you build it, then you’re successful; the focus is on the output rather than the outcome,” Sakar explains. “But in the product mindset, success is about product metrics based on a longer-term vision.”  

 

Westerhold notes that product goals and metrics should be tied directly to the goals of the business, and as concrete as possible. Targets like ‘improving customer satisfaction’ or ‘creating a better customer experience,’ can result in what he terms ‘OKR theater,’ where developers have few tangible outcomes to pursue. The outcome? “They work hard to ‘do better’ but rarely hit any strategic goals and the product suffers from it, leading to a rescue.”

 

Failure to follow due process, especially as engineers and product managers face more pressure to speed up, and (perhaps implicitly) to cut corners. “It boils down to the classic risks: desirability, usability, feasibility, viability,” Sakar notes. “If you skip all of the considerably cheaper steps of validating or mitigating those risks early on, and jump to building as quickly as possible, it becomes more expensive to pivot later. That results in products that need rescuing – and sometimes, solutions that nobody wants to use or pay for.”

Cycling through the ‘classic’ product risks

Source: Thoughtworks

A lack of joined-up thinking. In many organizations product and engineering are separate disciplines, with different incentive structures. This can be the genesis of turf wars that serve only to slow the enterprise down. “If something is delayed or broken, product wants to blame engineering,” Westerhold says. “Engineering wants to blame product. Everybody wants to blame the CFO because they don't have enough budget, but they don’t really care about being efficient. An organization is really only as good as its slowest part.” 

 

“A lot of organizations treat the business and the product strategy as independent of the engineering strategy – and on the tactical level, treat engineering as a cost center instead of a generator of value,” agrees Zachary. “They believe if they just throw requests over the wall to engineering, or throw money at a problem, things somehow magically get done.”   

 

Overall, “even if you have the best product in the world, if you don't have engineering that can keep up, and infrastructure, governance and reliability along with that, you end up with corporate churn that spends a lot of money but doesn't really provide much value,” Westerhold adds. “You’re chasing your tail instead of innovating, trying to stay in front of the market.” 

 

Creating and evolving great products depends on integrated teams and shared goals, which may require deep organizational change. As Sakar puts it: “A lot of times rescues can be mitigated, but you can’t expect different results with the same culture, organizational structure and tools.”  

 

“Especially with the advent of AI, it’s time to stop thinking of the software development life cycle,” notes Zachary. “Now it's a product development life cycle where there's full interconnectedness, from the business having an idea, all the way to the delivery and the telemetry you want to get from users. Product and digital leaders need to make sure they’re not just solving one problem, but understand the upstream and downstream implications.” 

 

This interconnectedness should be evident in a governance structure that enables product and engineering teams to rapidly evaluate ideas from different stakeholders, and bring the most viable and important to life through well-established engineering, data and execution practices. “That loop is how we’re seeing the most successful companies drive AI-powered product recoveries and/or scale their AI investments,” Zachary explains. 

 

“Say I own a mobile app, and I've got this grand set of enhancements planned,” says Westerhold. “All of that needs technical expertise under the hood. If I don't have that, it doesn't matter how good my ideas are. If engineering teams are inefficient or constantly fighting architecture problems and outages, so it takes eight months to build a new feature, the product people are going to go to the product manager and say: you're not fast enough. You end up with a spiral of finger-pointing. It’s death by a thousand paper cuts.”   

 

Zachary recommends product leaders “focus on getting the most out of their engineering organization first, and then correcting and improving decision-making within the product organization.” 

 

“You need a framework to identify what's going to drive the most value, so you can tell a stakeholder you’re not going to invest in neural networks or make a big purchase of a new third-party data platform tool, that another product is worth pursuing instead because it’s going to unlock more capabilities,” he says. “A product-led organization understands that ideas are infinite. The actual implementation of those ideas is what matters.”

 

A product-led organization understands that ideas are infinite. The actual implementation of those ideas is what matters.
Rickey Zachary
Global Engineering Platforms Lead, Thoughtworks

A framework for AI acceleration

 

When a product is struggling, ultimately organizations will need to decide how to intervene – and this may involve difficult questions. Is a rescue even viable, or worth the resources required? Is it the product itself that needs to be changed, or should the entire strategy be reexamined? Where should the rescue effort start? 


In working with product and engineering teams, Thoughtworks experts have developed the Loops framework to help diagnose where friction may be occurring and product optimizations need to take place. This envisions the development of AI and other products taking place across three distinct, yet connected, dimensions:

The loops that map product development 

Source: Thoughtworks

Bottlenecks in the inner loop typically mean design and engineering teams can’t deliver new product capabilities or fixes into the hands of customers fast enough. “That might require engineering and architectural fixes - for example, helping decide whether components need to be mobile-native, or can be web-reused,” says Zachary.   

 

When clients face issues in the middle loop, “their engineering is great, they can get products out into the hands of their customers, but they ultimately don't have the data assets to effect changes that the customer wants,” Zachary explains. He gives the example of retailers that are unable to accurately reflect inventory on digital channels, disappointing some customers who expect to find items in stores. In such cases improvements need to target areas like inventory or supply chain management.

 

With outer loop problems, by contrast, “you’ve built all of these things, you’ve got the right data, but the experiences are not landing with customers,” says Zachary. Rescues can be affected along this loop by analyzing customer data and using it to inform new experiments. 

 

In this sense, the Loops framework not only provides a way to approach product rescue – it can also inform the development of new AI-powered products. “We have a set of clients where we're doing prototypes of new interfaces in less than three months, getting them into the hands of customers, using AI initiatives and capabilities to gather on usage and iterate based on that,” Zachary says. 

 


Reimagine your products with AI-first software engineering


From diagnosis to cure

 

By laying metrics over the Loops framework, teams can track the quality of processes, product impact and performance, and potential signs of distress. This positions the business to make smart decisions about what needs to be addressed first. 

 

Overarching business metrics will be the ultimate consideration, but each segment of the loop may have metrics of its own. In engineering, for example, DevOps research and assessment (DORA) metrics are typically the gold standard – tracking factors like deployment frequency, change failure rate, and the mean time to recovery. “These give you a baseline as to whether the engineering organization is creating and maintaining products that are going to be impactful to the business – and if not, how to start intervening,” Zachary says. 

 

Sakar notes regardless of where they’re applied, metrics should be transparent, and distributed as widely as possible. “You can pick the ideal metrics, but what if your marketing department are the only people getting reports about how happy your customers are?” he says. “Even engineering teams need to be put in the shoes of the customer. If keeping people accountable and invested in metrics is not part of the culture and people continue to work in silos, metrics won’t trickle down to product teams.” 

You can pick the ideal metrics, but what if your marketing department are the only people getting reports about how happy your customers are? Even engineering teams need to be put in the shoes of the customer.
Ahmet Sakar
Global Head of Tech for CX & Product Innovation, Thoughtworks

Once a business has zeroed in on where product challenges rest, it might seem like the choice comes down to pursuing incremental improvements or attempting a complete turnaround – but often the best approach is somewhere in between. 

 

"Change doesn't need to be all or nothing,” Zachary points out. “We advocate thin-slicing larger transformations into small chunks of change. That's an additive part of the decision-making framework: How do you chunk up the product rescue so it’s not going to require a six-year roadmap until you see actual business impact?  

 

To further aid decision-making, especially in an environment where AI is mandating faster action, Thoughtworks advocates the decision factory framework – a defined process to embed business and customer data into the multiple choices an organization has to make each day, and quickly make decisions that support business strategies.   

 

In current client projects, Zachary credits this structure with helping companies decide whether and where to make AI investments, when many face significant pressure from upper management to adopt AI and no shortage of possible options. 

 

The decision factory has also ensured some clients steer clear of “agent washing.” Fed by the hype around agentic AI, this is the increasingly common phenomenon of businesses applying agents (or generic chatbots billed as agents) to problems that might be better solved by traditional engineering methods. 

 

“We’re seeing more and more products, particularly on the mobile side, that aren’t AI ready,” Zachary explains. “But because there wasn’t a decision factory in place, the client adds chatbots or agentic capabilities into their mobile application, and it actually breaks the product design. There’s a dip in customer NPS, and more people go to the website or in store, instead of using the mobile application that was meant to be a way to drive revenue share and business outcomes.” 


To advance, remember the basics

 

“Agent washing” is an example of how AI can create more products in need of rescuing. But Zachary also highlights the technology’s positive, and transformative, implications for development.

 

“Product rescues are being extended beyond the traditional definition,” he says. “In the banking space, more and more companies are looking at legacy engineering and product assets with AI added into their toolbox, and using modernization as a recovery technique. They’re starting to make investments now so they can explore hyper-personalization, new wealth management and lending solutions, and compete against fintech startups.” 

 

There are several ways Thoughtworks experts see AI uplifting product development and recovery practices: 

 

Elevating engineering through automation. “First and foremost, use AI to mature your existing engineering processes so that you can create and validate value,” says Zachary. “The ‘uncool’ thing that I'm advising clients is to start using AI to improve your testing capabilities. Boost automated testing to determine whether something’s going to work once it gets into the hands of customers.”  

 

Providing deeper insights into the customer base, and the likelihood of product success. “It depends on how much control you’re willing to give it, but it’s now possible for AI to understand user behaviors, understand the metrics you’re trying to increase, and not just recommend experiments but run multitudes of them in real time,” Sakar says. “However, you need to have the appetite to take controlled risks.” 

 

“Once you have the engineering foundations in place, you can start doing trendier, more experimental things, like using AI as a way to approximate user segments,” Zachary agrees. “We're seeing that more and more in the retail space, where AI agents are in the loop to provide early feedback. They’re not a 100% approximation to users. But if I'm just doing a quick prototype using no code solutions that may not make it to production, I've got a bunch of agents now that can tell me whether it will resonate with a 60-year-old.” 

 

Opening new product design possibilities. Product managers and designers are already getting accustomed to exchanges with text-based interfaces like ChatGPT and Gemini, but can now map out and evaluate user journeys and interfaces with AI tools visually, Sakar notes. 

 

Westerhold sees AI’s vast information-gathering capabilities as both a powerful additive and new complexity for product design and ideation. “The bar is rising for the expert to be able to come in and take all the information AI provides, leverage their knowledge and all of the processes that come into product development, and design a system that actually works in the real world,” he says. “It's easy to look at things within a narrow scope and decide they work, but that may not be the case in the broader systems or organizational context.”  

It's easy to look at things within a narrow scope and decide they work, but that may not be the case in the broader systems or organizational context.
Chris Westerhold
Global Practice Director - Engineering Excellence, Thoughtworks

Tightening product feedback loops, by enabling engineers to rapidly spin up experiments and get them into the hands of users in the form of medium to high fidelity prototypes. “AI is going to allow organizations to do more with less - or as I like to say, do more with more,” says Zachary. “A lot of clients talk about reducing their engineering footprint. But what if you kept your engineering footprint the same, did four or five times more, and were able to out-compete other organizations as a result?”   

 

Refining product development and recovery by helping teams penetrate the near-impenetrable legacy code bases and systems that have built up at some organizations over time, which can make it tough for engineers to discern where problems or sources of friction originate. 

 

By strengthening reverse engineering with AI-powered analysis tools such as Thoughtworks’ CodeConcise, teams gain a better understanding of those systems and their constraints. “It brings a hefty improvement to one of the biggest problems engineering organizations have, which is a lack of documentation,” says Westerhold. “Even if it's 80% correct, you’ve got a far better ability to understand your systems than before.” 

 

“As LLMs and agents mature, we'll have a much greater understanding of the assets in the existing engineering organization, and how to expose those out to internal engineers, product owners and product managers through conversational interfaces,” Zachary says. “We may also find new ways to ‘product-ize’ nontraditional knowledge within the organization, and get that into the hands of end-users.” 

 

For all the potential, Thoughtworks experts caution against AI ‘FOMO,’ and counsel a measured approach – even if, as Sakar notes, “the disruptors are just going to go all in.” 

 

“With AI, whether it's a product or an application rescue, a lot of people are trying to skip the hard stuff,” Westerhold says. “The thinking sometimes is ‘I might not have particularly good testing, pipelines or architecture – but if I just sprinkle a little CoPilot on it, it’ll work really well.’ Of course it doesn’t turn out that way. Instantaneously doubling your ability to write code doesn’t solve deeper problems.” 

 

Also, just because AI may allow companies to churn out more product upgrades doesn’t mean they should. “Some of the SaaS products that I use push out updates every day - and it’s annoying,” says Westerhold. “We’ve developed this over-fixation on moving fast and breaking things. In some cases that's fine, but you need to understand where you are, what you’re trying to do and the impact your changes are going to have.”  


AI excesses can be avoided through a sustained focus on best practices and the outcomes that matter to the organization. To assist clients on this journey, Thoughtworks has forged a partnership with DX, a platform enterprise that collects both quantitative and qualitative engineering metrics to measure the impact of AI initiatives; and developed accelerators like Haiven, which embed best-in-class product and delivery processes that reduce time spent on day-to-day operations, and unlock more resources for innovation.

Accelerating engineering excellence with Haiven

Source: Thoughtworks

“We have differentiation in terms of being able to connect all of these things together through platform strategy, from a data engineering and product platform lens,” Zachary notes. 

 

Regardless of how AI evolves, Westerhold notes there will ultimately be no substitute for the caliber of ideas and practices that leading product and engineering teams, and high-performing businesses, exhibit. 

 

“I've had clients worry their SaaS product is being attacked by something someone vibe-coded over a weekend,” he says. “But people quickly realize there’s a lot of time, effort, energy, effectiveness and security needed that vibe coders just can't do. Success is not just about AI; it also has a lot to do with good engineering. That's a big part of how you actually go about improving and transforming an organization, and solving product risk.” 

 


Next steps

 

Ready to build resilience into your products?

Chris Westerhold

Global Practice Director - Engineering Excellence

 

Chris has a strong focus on building scalable engineering teams, engineering metrics strategies, developer platforms, platform engineering and technical product management.

Rickey Zachary

Global Engineering Platforms Lead

 

Rickey guides global clients in creating self-service capabilities, implementing platform governance models, and measuring platform effectiveness through DORA and SPACE metrics.

Ahmet Sakar

Global Head of Tech for CX & Product Innovation

 

Ahmet is a passionate advocate of intertwining product thinking and technology, a technologist who weaves compelling narratives that illustrate the journey and highlight the intrinsic business value.


Subscribe to Perspectives to stay ahead of the curve.

 

Get timely business insights, expert analysis, and industry updates delivered to your inbox when you need them—no noise, just value.

Marketo Form ID is invalid !!!