The Product Trio Just Became a Jazz Band
Why sequential handoffs are dead and what replaces them
Henry Modisett’s Figma workspace is nearly empty. Not because he’s new to design—he’s Perplexity’s VP of Design. It’s because his team designs primarily in React, building working versions of interfaces so they can use the product while shaping it. “Rather than designing in Figma like most mortals, he and his team design in React,” observers noted when he shared his approach.
This isn’t aesthetic preference—it’s necessity. Static mockups can’t capture AI’s dynamic, conversational nature where each response varies based on context, user history, and the inherent randomness of LLM outputs. When your product’s behavior is probabilistic, the traditional assembly line (PM writes spec, designer creates mockups, engineer implements) breaks down completely.
The teams shipping the best AI products have figured this out. They’ve stopped passing documents down the line and started improvising together. The product trio hasn’t disappeared—it’s just learned to play jazz.
When the assembly line breaks
The traditional model made sense for deterministic software. A PM could specify exactly what should happen when a user clicks a button. A designer could mock up the precise screen that would appear. An engineer could implement it pixel-perfect. The output was predictable and repeatable.
But what do you specify when the output changes every time? How do you mock up a conversation that adapts to context? How do you implement behavior that’s defined by a prompt, not code?
Anthropic’s Artifacts feature shows what happens when teams embrace this reality. Research scientist Alex Tamkin built the first prototype in March 2024 after getting frustrated with the tedious cycle of prompting Claude for HTML, copying to an editor, saving as a file, and opening a browser. His scrappy Streamlit prototype showed Claude on the right with real-time output rendering on the left. Within two weeks, product designer Michael Wang transformed this into a polished prototype using Node.js and shared it internally. The entire Anthropic company dogfooded it, providing immediate feedback.
By June 2024—just three months from initial prototype to production—Artifacts launched publicly with Claude 3.5 Sonnet.
Three months. From frustration to shipped feature.
The speed came from collapsing the handoffs. Wang describes using Claude itself throughout development: “I’m almost always using Claude in my development process. I use it to scaffold out code, have ongoing conversations about implementation details, and transform code as needed.” When Claude 3.5 Sonnet became available, the capability jump changed their ambition level entirely. “Folks were demoing entire Three.js or WebGL apps created by Sonnet in one shot. That’s when I knew we could be a lot more ambitious.”
The team adopted what Wang calls a “minimal backend approach” where “a huge chunk of Artifacts is ‘just’ presentational UI—the heavy lifting happens in the model itself.” The product specification wasn’t a PRD—it was the behavior of the model, shaped through prompts that the entire team refined together.
The new collaboration model
Microsoft’s teams underwent a parallel transformation. Yannis Paniaras, who leads design for Microsoft’s AI products, describes the evolution: “It used to be research, ideas, prototype, build, test—more linear. Now designers work concurrently with PMs and engineers to design prompts.”
Read that again: designers work concurrently with PMs and engineers to design prompts.
The prompt essentially becomes the product specification for non-deterministic systems. Content designers and UX designers jointly develop guidance for engineers to scale Copilot responses, creating consistent, reliable tone and timing. The design no longer flows through sequential handoffs. Instead, all disciplines shape the AI behavior simultaneously through collaborative prompt refinement.
Aman Khan, who writes about AI product management, describes what he calls “pair programming for prompts.” In his framework, PMs and AI engineers collaborate on evaluation criteria the same way engineers pair on code. The PM defines what “good” looks like from a user and business perspective. The engineer defines how to measure it technically. Together they own the “why”—the reasoning behind what makes the AI’s behavior acceptable.
This isn’t just about prompts. It’s about recognizing that for AI products, behavior is the interface. You can’t hand off behavior definition the way you handed off screen designs.
What actually changes
The artifacts are different. Ravi Mehta, who advises AI product teams, describes what he calls “vibe coding”—using tools like v0 to create working prototypes that serve as the new PRDs. Instead of writing a document that describes what should be built, you build a working version that demonstrates the intended behavior. The prototype becomes the specification.
Intercom learned this lesson building their Fin AI chatbot. The team discovered that colorful mockups with placeholder text couldn’t validate whether AI-generated answers met quality standards. Early prototypes required real customer questions paired with actual help center articles to evaluate answer quality. “Lorem ipsum is your enemy” became the operating principle.
This led to extensive backtesting—running the algorithm against historical support data at scale before building the full product envelope. Sometimes the MVP was simply “a spreadsheet of outputs” to validate the AI behavior worked before investing in interface development.
The responsibilities haven’t disappeared—they’ve just shifted. Marty Cagan and Bob Baxley from Silicon Valley Product Group provide the clearest framework: product discovery is fundamentally about judgment, not documentation. PMs still own value and viability. Designers still own usability. Engineers still own feasibility.
But for AI products, these dimensions interweave more tightly than ever because the AI’s behavior is the product experience itself.
Here’s what that could look like in practice:
Product managers ensure features create customer value for both users and buyers, assess business viability across legal/compliance/sales/marketing stakeholders, understand data implications and constraints, know the competitive landscape, and make tradeoffs between AI capabilities and business limits.
Product designers design how AI communicates with users including tone, personality, and conversation flow; are crafting interaction choreography that make AI capabilities discoverable and integrated into existing flows while introducing new AI-related mental models to users. Designers should be partnering with engineers to iterate on behavior quality: understandable, learnable, and usable across an infinite universe of edge cases and AI limitations.
Engineers (and increasingly, AI engineers specifically) own the technical implementation of prompts, build evaluation frameworks to measure behavior, integrate AI capabilities into production systems, optimize for performance and reliability, and stay current on techniques and model capabilities.
The difference is that these roles now work concurrently on the same artifacts—prompts, evaluation criteria, behavioral specifications—rather than sequentially on separate deliverables.
New roles emerging
This concurrent model has spawned new specializations. Conversation designers have become distinct practitioners who design dialogue flows, define conversational personality, write scripts or prompt LLMs appropriately, ensure linguistic correctness, create consistent voice across interactions, and test conversational experiences. They typically report to or work closely with product designers, specializing in the conversational interface layer.
Prompt engineers occupy the engineering-focused counterpart. They craft and optimize system prompts, build prompt templates and libraries, test and iterate on prompt effectiveness, integrate prompts into production systems, optimize performance, and stay current on techniques. The relationship flows logically: conversation designers define what the AI should say and do, prompt engineers implement the technical how of making AI behave that way.
But here’s what matters: these aren’t replacements for traditional roles. They’re expansions. Microsoft’s job posting for “Principal Product Designer” in AI emphasizes “shipping world-class AI applications with emphasis on craft, quality, trust, and positive user and societal impact” and requires “understanding user needs and behaviors, defining product requirements” for “zero-to-one consumer products” with AI capabilities.
This isn’t a new role—it’s product design with additional knowledge requirements: understanding AI capabilities and limitations, designing for non-deterministic outputs, managing user expectations about AI, understanding training data implications, and addressing ethical AI considerations.
The jazz metaphor is real
Here’s what I mean by “jazz band”: In traditional software development, each role plays their part in sequence, like an orchestra following a score. The conductor (PM) sets the tempo, each section (design, engineering) comes in at the right time, and the output is predictable.
In AI product development, you’re improvising together. The PM sets the key and the general direction. The designer suggests a melody. The engineer riffs on it. Someone tries a variation. You listen to how it sounds, adjust, and keep playing. The output emerges from the collaboration, not from following a predetermined score.
This doesn’t mean chaos. Jazz musicians practice scales, learn theory, and develop deep expertise in their instruments. The product trio still needs specialized skills—product sense, design judgment, technical expertise. But the way those skills combine has changed.
The teams that master this new rhythm will ship better products faster. The teams that keep trying to play from a score will keep discovering their sheet music doesn’t match the music their product is making.
References
Khan, A. (2024). “How AI PMs and AI Engineers Collaborate on Evaluations.” Aman Khan’s Newsletter.
Mehta, R. (2024). “How to Work Like an AI-First PM.” Ravi Mehta on AI Product Management.
Modisett, H. (2024). Perplexity design process. Referenced in multiple industry discussions of code-first design approaches.
Paniaras, Y. (2024). Microsoft AI design process evolution. Microsoft Design team interviews and presentations.
Silicon Valley Product Group. (2024). Cagan, M. & Baxley, B. Framework on product discovery and AI product roles.
Wang, M. (2024). “Building Artifacts: From Prototype to Production.” Anthropic product development case study.