> ## Content Index > Fetch the complete content index at: https://www.davidcost.com/llms.txt > Use this file to discover other available public pages before exploring further. # How Does an AI Product Evolve After You Put It Into Production? - URL: https://www.davidcost.com/how-does-an-ai-product-evolve/ - Published: 2026-10-07T14:00:13.000Z - Updated: 2026-10-07T14:00:12.000Z - Description: Some of the most valuable capabilities in an AI system cannot be specified in advance. They emerge after people begin using the product, learning what the technology can do, and redesigning the work around those new capabilities. - Author: David Cost - Tags: AI Transformation, Product Management, David Ness, Ecommerce, Enterprise AI **Some of the most valuable capabilities in an AI system cannot be specified in advance. They emerge only after people begin using the product, learning what the technology can do, and redesigning the work around those new capabilities.** In my previous article, [Why Does AI Need Product Management, Not Just Project Management?](https://www.davidcost.com/why-does-ai-need-product-management/), I described an approach to systems development that my Wharton professor David Ness called **Middle Out Design**. The basic idea is straightforward: users often cannot fully specify what they need before they have something they can see, use and react to. That makes Middle Out particularly relevant to AI. When the capabilities themselves are new, neither users nor developers necessarily understand at the beginning how the technology will ultimately change the work. Our experience building a custom AI image generation system is a good example. ## We Started With the Task Our original objective was straightforward: **replace our existing manual image generation process with one driven by AI.** That was a problem we understood. We knew the existing process, its constraints and what we wanted AI to accomplish. We built the capability and accomplished the objective. But once we had a working product, our understanding of the opportunity began to change. The first version solved the problem we knew we had. Using it began to reveal problems we hadn't realized we could solve. ## Then We Started Rethinking the Process As part of the system, we created a **digital closet**. Users could select a main item, supporting items and accessories to compose an image. That created an opportunity that hadn't been part of the original image generation problem. One persistent challenge in ecommerce is displaying merchandise that is no longer available for sale. In a traditional photography process, products and accessories exist on physical racks and in closets. Keeping everything used in a photograph synchronized with current inventory is difficult. A digital closet doesn't have that limitation. We connected the closet to inventory so products with insufficient inventory can be removed from consideration before an image is generated. The AI system wasn't simply generating an image differently. Moving the process into a digital environment gave us an opportunity to improve the underlying merchandising process. ## The System Already Knew What Was in the Image The digital closet revealed another opportunity. A common ecommerce frustration occurs when a customer likes an outfit but can't easily find the other products or accessories shown in the image. Solving that problem with traditional photography requires someone to keep track of every item used in every photograph and maintain those relationships as the imagery moves through the ecommerce process. Our system already has that information. An image is generated from a main product plus supporting products and accessories selected from the digital closet. Because the system knows exactly which products were used to compose the image, it can preserve that information and attach the complete product list to the image. That enables us to create detailed **Complete the Look** merchandising for every image on the website. Again, this wasn't part of the original requirement to generate images with AI. It was an opportunity that became visible because we had built the product. ## Eventually AI Began Changing the Work Itself The next stage was more consequential. The system initially had only one or two users. As adoption grew, we needed workflows that could coordinate a larger group. We could not have specified those workflows correctly at the beginning. The reason wasn't simply that we didn't know how many people would eventually use the application. **We didn't yet know how the new AI capabilities would change what we needed our people to do.** As we learned what the AI could do well, the human roles evolved with it. That allowed us to design workflows around what people actually needed to do rather than around assumptions we would have made before the system existed. This is where the distinction between **AI adoption and AI transformation** becomes important. Adoption could mean giving more people access to the AI application. Transformation asks a different question: **Now that this capability exists, how should the work itself be organized?** The larger opportunity isn't simply to make each individual more productive. It's to rethink what the technology should do, what people should do, and how the group should work around both. ## From Task to Process to Organization Looking back, the evolution followed three levels: **Task:** Can AI replace the manual image generation process? **Process:** Now that the process is digital, can we improve merchandising by making image generation inventory aware and automatically supporting Complete the Look? **Organization:** Now that AI changes the work itself, how should we organize the people doing that work? None of those later capabilities were part of the original problem we set out to solve. **They weren't requirements we missed. They were opportunities and requirements we couldn't fully see until we had a working product.** That's why treating an AI implementation solely as a project can be limiting. If success is defined as delivering the original specification, the organization may accomplish exactly what it set out to do while missing much of the value the new capability makes possible. A product mindset assumes that what you learn after deployment can be as important as what you knew before development began. ## You Can't Specify What You Haven't Learned Yet This is what Middle Out Design gets right. Build enough to make the solution real. Put it into use. Learn from it. Then let what you've learned change what you build next. With emerging technology, implementation isn't simply execution against what you already know. **Implementation is also a mechanism for discovering what you don't know.** We started by asking how AI could improve a task. **Building the product eventually led us to ask how AI could improve the system around the task.**