Dhwani Soni is a product, design, and transformation leader whose career has spanned enterprise software, security, communications, customer experience, analytics, and AI. At 8x8, she holds portfolio-level leadership responsibilities across product management, design, research, operations, and AI-powered experiences — building on earlier design leadership roles at MobileIron, SAP, Dell Services, and Samsung Electronics.
Her perspective is grounded in a central conviction: as AI lowers the cost of building software, features alone will become increasingly difficult to defend, and durable differentiation will come from the context, semantic infrastructure, workflow intelligence, and trust systems that let products understand a business and evolve with it. In this conversation, Soni discusses what it means to make an enterprise legible to AI, why products must earn the right to become invisible, how personalization can remain transparent and controllable, and why the products that endure will be the ones that continuously increase their value to customers.
Beyond features: The new durable moat
With tools like Claude Code dramatically lowering the cost of implementation, many products are starting to look remarkably similar. What still creates durable differentiation?
Durable differentiation is moving away from the feature itself toward more infrastructure, context, and the semantic layer that sits underneath it. Features are already copyable. I like to think of them more like menu cards. One vendor introduces a feature capability, the other can copy it fairly quickly, and it’s another version of it that is sitting with a different prompt, different model, maybe slightly different implementation approach. Now, as the cost of building falls, the shelf life of the standalone product differentiation is reducing significantly.
What’s becoming really hard to replicate is the system that enables the AI to understand the business environment, like the relationships between the data, the meaning of the workflow, the users’ context, what decisions are being made. What are the decisions that the customer cares about? What are the outcomes that they’re driving for? The semantic and the contextual layer is what makes the entire enterprise legible to the AI.
Once you have that, you can enable the model to make smarter decisions, orchestrate across workflows, and deliver an experience that is relevant to the end user, rather than simply generating a generic response to them or building a generic feature. And the second part of the differentiation is the infrastructure itself. The ability to connect systems, the right systems, preserve the context over a multithreaded set of information, govern the actions, and create the feedback loops, so the product can learn from the usage and the outcomes itself.
So I believe that the products that will win will be self-evolving systems, honestly. They will not simply ship a fixed set of features. They will continuously become more intelligent and valuable as they understand the customer’s environment better. Otherwise, we’ll be just building point solutions with increasingly similar capability, and that’s really not differentiation. So as the features start to become a commodity, the advantage is the context graph, the orchestration and the infrastructure underneath, and a self-healing, self-evolving system for the product to evolve with the customer’s needs.
If feature parity is becoming inevitable, where should teams invest to create experiences that are difficult for competitors to replicate?
Teams should invest in understanding the customer’s environment deeply enough that the product becomes connective tissue within it. That starts with listening carefully to the customer — not just to the feature being requested, but to the outcome they’re trying to achieve, the systems they already use, the workflows they depend on, and the friction preventing them from realizing value.
From there, the opportunity is to build the semantic layer and contextual intelligence that let the product fit naturally into that environment, rather than sitting beside the customer’s infrastructure as another isolated tool. Teams also need to invest in curation and adoption: providing a capability isn’t enough. You have to configure it for the customer’s context, help embed it into the way they work, and make sure they’re realizing the intended outcome.
A competitor may be able to replicate the visible feature. It’s much harder to replicate the accumulated understanding of the customer’s environment, the integrations, the adoption model, and the trust that develops over time. That’s when a product becomes more than software — it becomes part of the customer’s operating infrastructure, and therefore much harder to replace.
The paradox of invisible design
Sometimes the best products are those that become “invisible.” What does invisibility actually mean from a product design perspective?
I think it’s such a powerful moment when a user lets you put your product that is almost invisible to them on their mobile phone. A product earns that right to become invisible when the user trusts it deeply enough to depend on it without having to constantly manage it. My perspective is drawn from my earlier work in security. The best security systems are often the ones that recede to the background, that do the work for you but you don’t need to worry about them, because they only surface when there’s a threat or an anomaly or an insight that really requires attention.
I think the same principle applies more broadly today beyond the security industry. A product becomes invisible when the interface is no longer the center of the experience, but the solution is, the outcome is. The user continues to receive the outcome that they care about, while the system blends naturally into their workflow or the work routine.
The customer should be able to define the problem, or you sit down and understand the outcome clearly that the customer’s driving for. The product should almost become so frictionless, the way we deliver it, that it becomes a part of the routine, whether they need an interface, or they need a recommendation, or they need an automated action or no visible interaction at all. What do they care about, and how can we deliver that in a very orchestrated manner, in a more trustworthy manner? That’s where a product can really be invisible, but I do not mean invisible to mean opaque. The user must still understand what the system is doing, retain control over the important and consequential decisions, trust the product, and understand the business context in which it is operating.
Ultimately, invisibility is really not the absence of the product, but it’s an evolution of the experience that you bring to the user and the presence of value, without the burden of operating the product or the product requiring the user’s constant attention. In short, a product becomes invisible when trust is high, friction is low, and the outcome stays visible even when the interface doesn’t.
Personalization without complexity
As products become more personalized to each user’s context, how do you keep that from becoming overly complicated or error-prone?
Personalization, again, has to start with a deep understanding of the problem the user is trying to solve. Personalization should not require users to reorganize their work around the product. The product should adapt to their context and working model. This was valuable in the pre-AI era as well.
The first principle for a product to get personalized or to be adopted in a personalized manner is to show the work, especially early in the relationship. The AI should make reasoning, assumptions and proposed actions, visible enough such that the user can understand how it reached the conclusion. Over time, as the system improves itself, the user may choose to delegate more authority, but that trust at the beginning has to be earned. That’s where human-in-the-loop comes in.
The second principle in personalization is more about inspectability. Let’s say the product goes more invisible, but the user should always be able to go back, query what happened, why a certain decision was taken, and understand if or why the AI may have taken a wrong turn. It should be reversible, because that’s what is sometimes needed. That makes the system more stable, because when it’s imperfect, it’s not inscrutable.
The third principle is flexibility, like how I was talking about being able to revert back, but it’s the flexibility in how the outcome is delivered. Personalization should not be limited to the way that the interface has to change. Different users may need the same outcome, same capability, but delivered to different experiences. It could be a mobile experience, it could be a web interface, it could be an automated workflow, it could be an MCP-enabled interaction. It could be as simple as, “Pull it into a Google Sheet for me.” That’s the flexibility of personalization. That model hasn’t changed. So it’s not about personalizing the interface, it’s about personalizing the experience by leveraging the workflow that works for a user’s mental model, and it’s deeply rooted in the user’s problem. Again, transparent enough to be able to earn the trust, flexible enough to fit the workflow, and controllable enough that the user never feels that they are not in control or the product is unstable. Ultimately, the AI has to earn the right to make decisions on the user’s behalf.
Products people don’t want to leave
Switching costs are often framed around data lock-in or integrations, but there are also emotional and behavioral switching costs. How do you design products a user doesn’t want to leave?
This is actually my favorite question, because the premise hasn’t changed between pre-AI and post-AI. That has always been the core challenge: how do you build something that people just love to stay in, day in and day out? I think, again, it goes back to understanding their mental model, how they work, how they make decisions, what they trust, and where friction appears for them. The product has to fit naturally in their mental model, rather than asking them to get out of it and continuously adapt again and again to the product that you have built for them, and that’s challenging. That’s complete friction right there.
The second part is trust. Customers stay when the product is reliable, it’s understandable, and it’s consistently helping them achieve the outcomes that they care about. Then the third, which is increasingly important — this is the part that gets me really excited now that it’s possible — is evolution. The context today is already evolving. The data is always fresh. It’s real-time. The priorities are always getting updated. Workflows are getting really flexible and real-time adaptable as well. The insights available to them are getting generated. It’s learning and it’s feeding you information. What if the product evolved with the context? The product should not remain static.
I think the strongest products now will need to become increasingly self-healing and self-evolving. So they will detect where something has changed, adapt the experience or the workflow, automate what can be automated, request permission when appropriate, continuously improve, without requiring the user to go elsewhere to fill minor feature gaps. Because you’ve got the right context which is constantly updating. You’ve built it over time. You’ve built a connective tissue where it works with your infrastructure. All you need is the product to evolve, and you’ve already set the experience in the way that you want to deliver it. That creates a much stronger form of retention for the customer and customers want to stay. This way the product understands their environment, reduces their effort, and becomes more valuable over time.
I think the goal is not to create a dependency through lock-in. The goal is to create confidence that it’s continuously relevant and it’s working for you, not the other way around.
Enterprise UX in an AI-native world
With AI, has the definition of “consumer-grade experience for enterprise” changed?
I think if you root the definition of a good enterprise experience in deeply understanding the problem, then you’re fine either way, with AI and pre-AI. What has really changed is the evolution of what experience means. Good enterprise UX was once largely defined by making complex software easier to use: clearer navigation, more coherent information architecture, fewer steps, and less training. Those qualities still matter, but they are now table stakes.
What has changed is the unit of experience. Enterprise UX is no longer confined to a screen or device. It now spans workflows, roles, data, integrations, automated decisions, and interactions across multiple systems.
A beautifully designed interface inside a fragmented workflow is not a good experience. If users must reconstruct context, repeat information, move between disconnected systems, or manually coordinate decisions, the underlying problem remains unresolved.
AI expands the remit of design further. We are now designing how systems interpret intent, communicate uncertainty, request approval, take action, and learn from outcomes.
Good enterprise UX is therefore no longer simply about making complex software usable. It is about designing coherent, intelligent, and trustworthy business systems. Screens still matter, but they’re no longer the primary measure of the experience.
If voice and natural language become the primary frontend interface, how does that change the role of product design?
The experience and the way you deliver it is definitely changing. Previously, you had to go gather the intel. You would go to solutions engineers, you’d go to customers, you’d set up labs, you’d look at competitors’ information, you’d look at documentation. You were gathering context. Now that context is automated for you, so how do you automate the ingestion of context? I like to call it the ExperienceOS. So you’re now building an ExperienceOS first, the ingestion of that customer feedback, the competitive intel, how products are being used, and behavioral data together, creating an AI-ready to read an automated .md file with full context of the product experience.
Once you have that, leverage a design system that is AI-ready that can read natural language and an .md file for AI-dev creation, and now you’ve got end-to-end. You’ve got context, a prompt, and you’ve got your natural language input that pulls it all together. Your design is now fed by voice, natural language, and with the context inputs. Again, the work needs to be done on the context layer, semantic layer, pulling information from so many different sources and making sure there is no hallucination. That’s one place where you put a human in the loop or a learning system there.
The second is if it’s spitting out automated experience, whether it’s screens, whether it’s MCP, whatever that might be, how is that being checked? There needs to be a person who’s reviewing that, or an agent that has learned what it needs to deliver. So I think that’s how product design is evolving, from the overall ingestion of an evolving contextual layer of multiple sources, rooting it into the business outcome, rooting it into the experience that you want to deliver holistically as a company, as a vendor, and then using natural language prompts. A lot of work needs to go on the prompting itself. You do that work, and then it leads to a much more streamlined model of delivering product experience.
This can make it feel a little like design is not important, but I think a lot of work now goes on building the right systems design, building the right libraries, rooting it into the right decisions such that a single command, even from a designer, can fix the system completely. So a lot of focus goes on the platform layer, context layer, and it’s not about tweaking one screen at a time. It’s tweaking the system, making it more intelligent at the same time. The visible frontend may increasingly become language, but the real design material is the behavior of the system.
What survives the commodity trap
If every company can generate code, ship features quickly, and access increasingly similar AI capabilities, what will separate the products that endure from the ones that become commodities?
I think products that will endure are those that are rooted in business outcomes — products that customers can trust, that they can almost have a relationship with. That’s because the product is compounding in value for them; self-healing is one example of that. Then why would I buy from you versus somebody else? Because you have an infrastructure that it’s rooted in, that you understand my business, and that together both of them become a connective tissue. I think that’s the one that endures.
Products that become commodities will just provide feature-level capabilities, point solutions. Enduring products will help lead organizations through their own transformations — continuously providing that transformation to customers is what endures. Commodity products provide capability; enduring products continually expand what the customer is capable of achieving.
Many valuable product metrics today weren’t measurable just a few years ago. How is AI changing what product leaders should be measuring?
AI is changing product measurement in two ways. First, it allows us to measure signals that previously existed only in unstructured conversations. Second, it allows us to connect those signals to product behavior and business outcomes. Product leaders no longer have to rely exclusively on surveys, interviews, support tickets, and manually synthesized field feedback. AI can analyze customer conversations, implementation notes, sales commitments, product usage, support interactions, and behavioral data together. That creates entirely new measures. We can identify which promises were made during the sales cycle, whether the product delivered on them, where adoption stalled, which customer problems are becoming systemic, and what interventions are most likely to improve the outcome.
These capabilities also make measurement more dynamic. Once an organization identifies and resolves one source of friction, the next constraint emerges. The KPI itself may evolve as the business becomes capable of seeing and solving new problems. That is particularly important for CIOs and transformation leaders. Many know they need to lead change but are looking for partners who can help determine what to measure, interpret what the signals mean, and identify the next action.
The most valuable product organizations will not simply report what happened. They will continuously identify what is changing, explain why it matters, and recommend what the business should do next.
As AI becomes more embedded in how products work, how do you see the role of product and design leadership evolving?
The role of product and design leadership is expanding. For years, we largely designed software that waited for users to operate it. We are now designing systems that interpret, recommend, act, learn, and increasingly participate in the work itself.
That requires a broader form of leadership. Product strategy, design, AI, customer experience, go-to-market execution, infrastructure, and organizational transformation can no longer be treated as separate disciplines.
The opportunity is not simply to ship more capability. It is to design the complete system through which a business becomes more intelligent, more adaptive, and more capable. The leaders who shape the next generation of products will be those who can make complexity coherent, make intelligence trustworthy, and make transformation adoptable.
What does LogRocket do?
LogRocket’s Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.