What Can We Learn From Successful AI Products?
Companies are waking up to the reality that advanced AI alone isn’t enough to meet customer needs. To fill the gap, we must take a more practical approach.
In this article, I will explore why so few AI products meet customer needs and what we can learn from products that have seen mass adoption.
Juniper Networks sponsored this article, and I use Juniper as a case study to explain an AI-native approach. Juniper is one of the few companies that went all-in on building AI into its product architecture. Instead of adding AI to existing products, it built an AI platform from the ground up, focusing on solving actual experience challenges.
That raises an uncomfortable question that should have been asked upfront: Why are we using AI in the first place? Not every use case is an AI use case, so it should only be used when it delivers more value than an alternative approach. Bolting AI onto a legacy platform delivers incremental value, but the development cost often exceeds the value it creates for customers.
I’ll explain how an AI-native design changes that.
How Is This A Design Problem?
AI products must be designed to take advantage of the technology’s novel capabilities. Bending a model to support the conventional paradigm squanders much of its value. We must adapt product design to a technology that does more than software can and does it differently than legacy apps. Tools should be designed to be intuitive to use. We should fit the tools to the workflow so they support the person who needs to get a job done rather than make the person fit the way they do the job to the tools.
One of the most time-consuming tasks for a network tech is troubleshooting, and it’s even worse when the problem isn’t a complete failure condition. Here’s the workflow to discover a bad cable (performance degradation vs. complete failure) from the legacy product design perspective:
Identify Symptoms: Ask users to describe the issue and check the logs.
Basic Troubleshooting: Are devices on and connected? Does the network dashboard show green indicators? Ping/Traceroute/etc. if necessary.
Validate Device Configurations & Network Settings: Has anything been changed or updated recently? Is there a new device that wasn’t configured?
Run A Network Test: Isolate the slow route and drill down to find the bad cable.
Legacy apps are disconnected, each serving a narrow intent by supporting a task (e.g., network status dashboard, command line, device configuration utility, network test app, etc.).
Here’s the bad cable workflow from the AI-native product design perspective.
Open The AI Interface: Juniper uses Marvis, which is where I got the image below.
Follow The Recommended Action: Replace the bad cable.
AI-native delivers a more intuitive user experience, and the tools leverage AI to be more proactive. The application is built to support workflows, not tasks. Models know the jobs to be done, so the platform is designed to anticipate user needs and manage the tasks required to meet them. The result of each workflow is aggregated on a single interface.
The prescriptive model (Recommended Action in the image below) was trained with contextual data from network techs completing the workflows with the old paradigm. Recommendations are the most common step in resolving issues with similar characteristics.
AI-Native Is Customer-Centric
Juniper’s AI-Native approach is rooted in understanding the end-user experience. This is the basis for its large experience models. Juniper uses experience metrics in all its case studies. For example, they discuss how automating simple network fixes resulted in the Gap sending fewer technicians to its stores. In the bad cable example, the platform monitors for performance degradations because they impact user experience.
Customer utility, outcomes, and experiences also drive the need for change. Legacy apps focus on tasks, and the user is responsible for turning the tasks into outcomes. AI-native products are partners in achieving outcomes. GenAI supports a new type of user interface and can detect a user’s intent.
Intent maps in 2 directions: the workflow that must be completed and the user’s desired outcome or experience. Every product is built incrementally, but what’s the starting point? An AI-native approach sounds like it would start with what the technology can do. If a business starts with technology, the only guarantee is more technology.
Will customers use it, and will they pay for it? Just because something is built with AI doesn’t mean it’s automatically valuable. The AI label is a great marketing tool. GenAI products that launched with high expectations and hype are experiencing equally high churn rates. The glow quickly wears off.
Juniper’s products make excellent case studies because it developed an AI-native platform and took a customer-first approach. Take Dartmouth College—a campus environment that sees a deluge of new devices (mobile, computers, connected devices) flood the network at the start of the academic quarter. Dartmouth’s CIO shared how this varied BYOD environment, combined with students’ high expectations for uptime, made for a unique networking challenge.
A legacy platform that leverages AI can’t target those outcomes. It can only support tasks.
A student in the library is having trouble connecting to the network.
The student opens a support ticket and reports a lag in connecting to Wi-Fi.
An IT support technician looks at the network logs and attempts to diagnose the problem.
Sometimes, the logs don’t have enough information, and the ticket must be escalated to the network services team.
An AI-native platform supports outcomes. It reduces the number of tickets created and decreases the number of escalations to the network services team.
Service level thresholds are set based on student, faculty, and staff experience. If a device takes longer than 2 seconds to connect, a ticket is automatically created and sent to the service desk.
The ticket contains information about where the failure occurred. Was it with the device’s authentication or the network?
If Juniper had built a legacy platform with AI bolted on, the task-based workflow would still be in place. Users would have access to data, and some tasks would be augmented or automated. However, the solution would be constrained by the most efficient legacy workflow. Using the AI-native approach, the workflow is optimized to be the most efficient one that AI can support.
Justifying AI & Unlocking Its Value
AI has novel capabilities that no other technology does. AI is implemented using a customer value-first approach because it supports unserved or underserved customer needs. The legacy paradigm manages value by tasks, and the AI-native paradigm manages it by outcomes.
Legacy platforms are collections of useful tools, like a hammer or a nail gun. AI-native platforms are like an intern or junior team member. Delivering outcomes is a collaborative process, but the platform doesn’t take autonomy away from the people using it. People interact with AI differently, and platforms must take that into account to be widely adopted.
Businesses that have been working with data, analytics, machine learning, and AI for years have a massive advantage. They have learned through iteration to deliver AI products that work and deliver customer value. Juniper developed its AI-native approach over 9 years of iterative delivery and learning.
Too many AI products fail because businesses are at earlier maturity levels. They have the technical capabilities to deliver AI but not the experience to move away from legacy patterns.
Thanks, Vin.
Just trying to understand if the library use case really needed AI. It sounded like a rules-based workflow engine to monitor performance, create tickets if SLAs weren’t met with details of the issue etc., even at scale.