AI features become a sideshow when companies let technology drive product strategy instead of starting with customer problems.
2
Teams can move from embedded AI assistance to contextual copilots and then to autonomous, interoperable product experiences.
3
A crawl, walk, run approach lets organizations build AI capability inside existing products while they learn how to manage reliability and risk.
Summary
Eliza Cabrera and Jeremy Silva argue that companies should stop treating AI as a separate strategy attached to the main product. Chat interfaces, retrieval, multimodal inputs, copilots, and agents helped teams learn what the technology could do, but these patterns are now common and rarely create differentiation on their own. The alternative is to integrate AI planning, evaluation, testing, and risk management with normal product work. Teams should begin with customer problems, give product groups room to prototype, and build upward from embedded features. Their crawl, walk, run model moves from back-end assistance, to contextual and personalized experiences, to agents that operate across a product suite. Cabrera illustrates the model with Workday's employee service products, moving from AI-generated knowledge content and translations, to a contextual assistant, and then to more autonomous agent behavior. The long-term goal is a dynamic product that responds to its environment and solves problems without making AI the main event.
Common AI patterns helped teams learn the technology but do not create a differentiated strategy
Cabrera describes the progression from chat UIs and content tools to multimodal inputs, vector databases, retrieval-augmented generation, larger context windows, memory, copilots, and agents. These approaches helped teams test model boundaries, improve access to information, and automate work. Silva and Cabrera are not dismissing them. Their point is that most companies now use the same patterns, so building around the latest capability does not by itself produce a distinct product strategy. The technology should be understood as an ingredient in product development rather than the reason the product exists.
A centralized AI strategy often creates a separate sidecar instead of integrated product work
Silva says enterprise companies often respond to the need to prioritize AI by creating a centralized AI strategy. That strategy can run beside the core product strategy, with separate initiatives and sometimes separate teams. The result is a spread of bolt-on AI features that do not fit the main product experience. Companies quarantine AI to certain corners to reduce perceived risk, but this does not remove the reliability problem. They still have to determine whether an AI feature works reliably enough to create customer value.
Customer problems should determine where AI is used
Teams can become a hammer searching for a nail when they prioritize the technology over customer needs. Silva gives predictable examples: chatbots built to demonstrate AI capability rather than address a support problem, and document summarization built without evidence that users suffer from information overload. He also criticizes purely top-down solution design. Leaders should set the broad priority, while product teams close to customers discover and test the specific solutions.
AI risk belongs inside product planning, supported by evaluation and testing
The speakers recommend integrating AI and product strategy instead of quarantining AI in a separate team or feature area. This requires new working habits and systems for evaluation and testing. Good prototyping and testing help teams understand the reliability risks and decide how to handle them. Product teams should start with a customer problem, experiment with possible solutions, and fail fast. Their work should fit within a top-level strategy, while discovery happens close to the people and workflows being served.
The crawl phase adds embedded AI without creating much new product surface
In the crawl stage, teams add AI to existing functionality rather than starting with a major redesign. The customer support example uses semantic search to surface similar past questions inside a shared inbox. This helps a support worker ground a response while preserving the existing workflow. The speakers stress that even this early stage should be embedded in the product. Crawl does not mean creating a separate AI destination that customers must learn to use.
The walk phase adds contextual and personalized experiences
During the walk phase, teams begin creating new product surface and more contextual assistance, although they may not need to rethink the whole application architecture. In the support example, the product prepares a draft response before the user arrives, giving them a starting point. Cabrera applies the same idea to Workday Assistant, which offers contextually aware suggestions based on the page and task. This stage also raises stronger data concerns when employees work with sensitive information such as pay or compensation.
The run phase requires an architectural and UX rethink because AI works across the product
Running means building dynamic, interoperable AI experiences across a product suite. In the support example, an autonomous agent can triage issues and respond to customers across multiple features. That scope requires changes to core product surfaces, user experience, and application architecture. The stages build on one another, though. Teams do not throw away earlier functionality as they move forward. They extend embedded capabilities until the product can support broader autonomous behavior.
Workday's employee service example moves from content generation to autonomous assistance
Cabrera describes Workday's progression in HR service delivery. The initial crawl features helped content authors turn a long policy document into an employee FAQ or manager talking points, then translate the content into supported languages while managing versions. In the walk phase, Workday Assistant helped an employee complete a location change with context from the current page. In the run phase, agentic behavior behind the assistant could listen for policy changes and proactively notify users with suggestions. The work had to align across HCM, financials, benefits, procurement, and core HCM.
Dynamic products respond to new inputs and environments instead of merely accelerating an old roadmap
Cabrera says organizations can use the crawl, walk, run stages to learn how to build useful AI experiences, eventually reaching dynamic products. She questions whether teams are simply solving yesterday's roadmap with more powerful technology. As products gain new data and inputs from their environments, the problems they address can expand. She sees multimodal, frictionless experiences that interoperate with one another as part of this next stage, where products respond to their surroundings rather than presenting AI as a separate feature.
"Our users don't necessarily want to know or have the sort of technical expertise around agents, but we still have that work happening behind the scenes."15:22
Who should watch
Product leaders who have created a centralized AI initiative and are seeing disconnected features appear across the product.
Teams deciding whether their next AI feature should be an embedded assistant, a contextual workflow, or an agent that works across the application.
Enterprise product groups that need a practical way to introduce AI while testing reliability, handling sensitive data, and coordinating work across a suite.
