When AI Changes the Rules, Is It Time to Rebuild Your Product?

Most successful digital products are built through years of iteration. Teams learn from customers, refine experiences, introduce new capabilities, and gradually improve what they’ve created. It’s a familiar approach to product development, and for good reason. Continuous improvement is often what turns a promising idea into a product people depend on.

But what happens when the technology changes so dramatically that the assumptions behind those improvements no longer hold?

Artificial intelligence is creating that question for product teams across industries. As AI evolves from answering questions to completing tasks on behalf of users, the opportunity is becoming much bigger than adding a chatbot or automating a few existing workflows. It’s prompting teams to reconsider how their products should work from the ground up.

For established companies, that presents a particularly difficult challenge. Their products may be successful, their customers satisfied, and their existing workflows deeply embedded in daily operations. The question isn’t necessarily whether those products are broken. It’s whether the decisions that made them successful are still the decisions they would make today.

On the Product Builders Podcast, we explored this challenge with Taron Ghazaryan, Head of Product Design at Samsara, whose team is reimagining a mature enterprise platform for an AI-native world. Our conversation explored when iteration stops being enough, how to pursue a fundamentally different product experience without leaving customers behind, and why AI is also changing the way product teams work.

When iteration stops being enough

Most product teams operate on a familiar principle: build something, learn from customers, improve it, and repeat. Over time, those improvements accumulate into more capable, polished, and reliable experiences.

The limitation is that iteration tends to preserve the underlying structure of a product. Teams become very good at improving existing workflows without necessarily questioning whether those workflows still solve the problem in the best way.

When generative AI first became widely available, many companies responded by introducing conversational assistants into their products. Users could ask questions, retrieve information, or navigate existing functionality through a chat interface. These were useful improvements, but the underlying product often remained largely unchanged. As AI systems have evolved from answering questions to performing tasks, a more fundamental opportunity has emerged. Instead of simply helping people navigate a workflow more efficiently, software can increasingly complete portions of that workflow on their behalf.

Taron compares this shift to the arrival of smartphones. Early mobile experiences often reproduced desktop websites on smaller screens, relying on users to zoom and navigate interfaces designed for a different environment. Eventually, designers recognized that mobile required a different approach, one that reconsidered what mattered most and took advantage of the device’s limitations.

AI presents a similar moment. Adding new technology to an existing product may create immediate value, but it doesn’t necessarily take full advantage of what that technology makes possible. The opportunity isn’t just to make existing workflows faster. It’s to question whether those workflows should still exist in their current form.‍

The product isn’t broken. The assumptions might be.

There’s an important distinction between a product that needs improvement and one built on assumptions that may no longer hold.

A mature product may be successful precisely because it was designed around the right technology, customer expectations, and business realities of its time. Those decisions weren’t necessarily wrong, and the product doesn’t become less valuable simply because new technology arrives. But as the surrounding conditions evolve, the assumptions behind those decisions deserve revisiting.

At Samsara, Taron and his team are exploring what their platform might look like if they built it today, with AI capabilities considered from the start rather than bolted onto an existing structure.

One approach Taron uses to challenge established thinking is to imagine technology ten years into the future and work backward. AI-assisted coding, for example, has advanced considerably in a relatively short period. Capabilities that seemed unrealistic just a year earlier are becoming part of everyday workflows, creating new possibilities for what individuals and teams can accomplish. Projecting those capabilities further into the future helps teams move beyond the limitations of their current products. Rather than asking what they can improve over the next six months, they can consider what might become possible over the next several years and what that could mean for the experiences they create.

But Taron pairs that forward-looking exercise with something equally important: returning to the fundamental problems customers are trying to solve. The underlying needs may remain relatively consistent, even as technology changes how those needs can be met. Understanding that distinction helps teams avoid rebuilding simply because new capabilities exist and instead focus on whether those capabilities create a meaningfully better solution.

A few questions worth asking when evaluating an established product:

• What assumptions shaped the original experience? Consider the technological limitations, customer expectations, and operational requirements that shaped the product's design.
• Which of those assumptions still hold? Separate the decisions that remain relevant from those that new capabilities may have overtaken.
• Are we improving an existing workflow or reconsidering the problem? Explore whether AI could fundamentally change how customers accomplish their goals, rather than simply making the current process faster.
• What would we build if we were starting today? Imagine the product without its existing architecture, interfaces, and workflows, then evaluate which elements would still deserve a place.

The goal isn’t to discard years of learning. It’s to use that knowledge to distinguish what customers genuinely need from how we’ve historically delivered it.

Rebuilding the future without abandoning today

For mature products, reinvention comes with a challenge that startups don’t always face: customers already depend on what exists. They have familiar workflows, established processes, and responsibilities that don’t disappear simply because a better experience may be possible.Taron describes this as one of the central tensions facing established enterprise software companies. Move too slowly and risk being overtaken by more innovative competitors. Move too quickly and risk disrupting the customers who helped make the product successful.

At Samsara, one approach is to identify customers already interested in experimenting with new technology and partner with them early in development. These select customers become development partners, helping the team explore and validate new experiences before introducing them more broadly. This approach creates room to innovate without expecting every customer to embrace unfamiliar workflows at the same pace.

The transition itself is equally important. Taron describes introducing new experiences while letting customers return to familiar ones when needed. If someone switches back, that decision becomes an opportunity to understand what didn’t work and where further refinement may be needed. Maintaining both experiences during a transition requires additional investment, but it also gives customers time to adapt and gives teams valuable feedback.

For product teams navigating a similar transition, several principles are worth considering:

• Start with customers who are ready to experiment. Early adopters can help validate a new direction without requiring an immediate change across the entire customer base.
• Introduce change gradually. Give customers opportunities to explore new experiences while maintaining access to familiar workflows.
• Treat resistance as an opportunity to learn. When customers return to an older experience, understand what kept them from adopting the new one.
• Validate the benefits before scaling adoption. Use real customer experiences to demonstrate the value of a new approach before introducing it more broadly.

Reinvention doesn’t have to mean abandoning the people who made the original product successful. It means finding a thoughtful way to bring them into its next chapter.

Let customers reveal the problem, not prescribe the solution

Reimagining an established product also requires a different approach to customer feedback. When people have spent years using a particular product, their expectations are naturally shaped by what they already know. Ask someone how to improve an existing workflow, and they’ll often describe a better version of that workflow. But what happens when the workflow itself is no longer necessary?

Taron emphasizes understanding what customers ultimately want to accomplish rather than treating feature requests as instructions.

At Samsara, that can mean challenging assumptions about what matters most to an operations manager. A team might initially believe reducing fuel costs is a customer’s primary concern, only to discover through deeper conversations that delivering goods on time and maintaining customer satisfaction matter more.

That distinction can fundamentally change the solution being considered.

It also reinforces why rapid prototyping has become increasingly valuable. Taron describes using AI-assisted tools such as Claude and Cursor to create working concepts quickly, sometimes incorporating real customer data to make those experiences more tangible.

Instead of asking customers to imagine an unfamiliar future, teams can put something in front of them and watch how they respond. Some ideas won’t work, while others may reveal opportunities customers hadn’t considered.

AI is changing the builders, too

Another dimension of Samsara’s transformation makes this moment particularly interesting. AI isn’t only changing what the company is building. It’s also changing how that work gets done.

Traditionally, digital product development has involved distinct responsibilities across product management, design, and engineering. Designers create interfaces, engineers translate those designs into code, and teams collaborate through reviews, handoffs, and rounds of refinement. Those boundaries are beginning to shift.

Taron describes designers increasingly contributing production-ready front-end code, product managers creating sophisticated prototypes, and engineers taking on responsibilities that previously sat outside their traditional roles.

A recent Samsara rebrand offers a concrete example. The company needed to bring its new visual identity into a mature web and mobile product. Rather than relying on large implementation teams for every change, one designer led the web work, and another led the mobile work, using AI-assisted development tools to implement and test changes directly.

The work still required engineering infrastructure, established standards, and code review. But the required coordination and handoff were significantly reduced. What might previously have involved repeated cycles between designers and developers could increasingly be handled by the person responsible for the design itself.

For product organizations, that raises questions that extend beyond productivity. If individual contributors can take ideas further into implementation, how should teams be structured? Which responsibilities will overlap? And which skills become more valuable as execution becomes easier?

There may not be definitive answers yet, but the implications are already becoming visible.Faster execution creates more opportunities to experiment, validate, and build. It also increases the importance of knowing which ideas deserve that effort in the first place. Technology may change how much an individual can produce, but it doesn’t eliminate the need to understand customers, make thoughtful decisions, or recognize when a product is solving the wrong problem.

Building for the world we’re entering

The most interesting part of this transformation isn’t necessarily how quickly AI is advancing. It’s what those advances force product teams to reconsider. A successful product represents years of decisions about how people work, what they need, and what technology can reasonably accomplish. Those decisions may have been entirely appropriate when they were made, but the conditions that shaped them won’t remain the same forever.

Rebuilding a mature product for the AI era doesn’t mean discarding everything that came before. It means separating the customer problems that still matter from the assumptions about how those problems should be solved. Sometimes iteration will remain the right answer. Other times, technology and customer expectations will have shifted enough that a more fundamental rethink is warranted.

The challenge is knowing the difference. And perhaps the most useful question established product teams can ask themselves isn’t whether their product still works. It’s whether they would build it the same way if they were starting today.