Max Headroom 
In my recent Live with Tim O’Reilly interview, I spoke with Marily Nika, author of Building AI-Powered Products and one of the most thoughtful voices at the intersection of AI and product management. We talked about what it means to build products in the age of AI—and how the role of product manager is being redefined in real time. This is a subject that’s near and dear to me as I work with the O’Reilly team to take the bitter lesson to heart and rethink all of our processes and products in light of the new capabilities of AI. (For additional perspective, see also Drew Breunig’s critique of the bitter lesson as applied to corporate AI strategy.)
Marily started in AI product management at Google back in 2013, before most of us even called it that. Today, she argues, this is no longer a niche skill set. It’s becoming THE job. “All product managers will be AI product managers,” she said. But she also warned against what she called the “shiny object trap”—using AI just to keep up with the hype. Good PMs must stay grounded in user pain points and product strategy. AI should be used only when it’s the best possible solution. “Use cases haven’t changed,” Marily noted. “People still want the same things. What’s changed is how we can solve for them.”
Marily’s Rapid Prototyping Workflow
One of the most exciting parts of our conversation was hearing about Marily’s rapid prototyping workflow using Perplexity for user research, custom GPTs for spec generation in her own voice, and v0 for UI mockups. With these tools, she can go from idea to functional prototype in hours, not weeks. “Every week I block time on my calendar just for AI experimentation. It’s made me a much better PM,” she said.
I hadn’t thought about limiting a search to Reddit to mine for user pain points. That’s brilliant.
One of our live attendees asked a thoughtful question: Is there such a thing as “vibe PMing”? Here’s Marily’s answer:
We also discussed when to prioritize polish over speed—and whether AI can help us do both. “AI is a slider, not a switch. You have to decide how much to use it at each stage,” she noted.
Marily also laid out three emerging product manager archetypes:
- AI builder PMs, who work on the models themselves
- AI experience PMs, who craft novel UX with those models
- AI-enhanced PMs, who use AI to amplify traditional product work
That’s real food for thought, and something that we’ll have to dig deeper into as we continue to develop our O’Reilly live training curriculum for AI-centered product management.
Strategy Meets Implementation
We talked about a theme close to my heart: the PM as translator between strategy and implementation.
I’m very influenced by my wife Jen Pahlka’s work on government transformation, as described in her book Recoding America. In her telling, product management is the skill of shaping not just what to do when developing a product but also what not to do. Government is in many ways an extreme case, with mandates developed by nontechnical members of Congress and their staff, or by administrative agencies, with little attention given to the details of how those mandates will be implemented, whether the implied implementation will work, or even if the specifications are implementable! But those lessons are also often surprisingly relevant for those of us in the corporate world.
Two stories stick in my mind. The first is about a PM at the Centers for Medicare & Medicaid Services who was faced with a spec that she thought was unimplementable. Conflicting mandates from Congress meant that doctors would be required to sign up for a program three months before they’d receive the information they needed to make that decision. Changing the spec would have been next to impossible. So she made the bold decision to override it, reasoning that Congress had specified quarterly reporting because they didn’t understand that it would be possible to create an API to provide real-time updates. The second is about a project leader who recognized that the project as specified wouldn’t work but said, “If they tell us to build a concrete boat, we’ll build a concrete boat.”
In her response to my extended tirade, Marily emphasized that while PMs don’t run day-to-day delivery, they must understand the trade-offs between latency, cost, UX, privacy, and feasibility—especially in AI development. You don’t need to build a concrete boat just because someone told you to.
Shared Tools and Team AI Adoption
One of the best attendee questions of the hour—one that was so good that I am using it as part of the framing of a longer post I’m working on about AI for groups—was “What are some tips on dealing with the fact that we are currently working in teams, but in silos of individual AI assistants?” (This question was from someone identified only as DP. For some reason, many of our corporate customers don’t want their employees to be identified by name or affiliation in the chat for our live events, which is too bad. DP, if you happen to read this post, please reach out. I’d love to chat with you more about this idea. If you know my name, you know my email.)
As you can see from the video excerpt, Marily completely agreed that this is a problem. AI use is still often siloed and secretive in teams—people afraid they’re “cheating” by using it, she noted. She called for teams to be open and collaborative about their AI workflows: create shared prompt libraries, use group tools like NotebookLM, and normalize AI use with shared agents and systems.
It occurred to me based on her response that NotebookLM may have a good start as a platform for shared AI work by nondevelopers, because it inherits many of the collaboration features from Google Drive and the associated family of Google productivity apps. In a similar way, AI for developers relies on GitHub for most of its “groupware” capabilities.
But that highlights just how LLMs themselves are really weak in this area. Leaning on external infrastructure is not a substitute for native features. For example, how might an LLM instance have a group memory, not just user memory? How might it include version control? How might we share an AI workflow versus just sending around links to outputs, much as we used to send around Word and Excel files before 2005, when Google Docs taught us there was a better way.
The Rise of AI-Native PMs
In response to another audience question, we talked about Andreessen Horowitz’s claim that the world’s largest company might well be an AI healthtech company. How might someone in healthcare get into AI product management? Marily gave a powerful reminder: You don’t need to be an AI expert to get started. Now is the time. No matter what your job is today, you can learn, experiment, and build with AI. Lean into your healthcare expertise. She told a story from one of her product management live courses on the O’Reilly platform that illustrated how one user had made the transition from a small hardware company into an AI healthtech opportunity at Apple.
We both agreed: We’re still early. Despite all the hype about the current market leaders, today’s AI is barely scratching the surface. Some of today’s dominant players may not survive. So many killer AI-native applications haven’t been invented yet. The future of AI is still up for grabs, and it’s up to us to build it.
Thanks to Marily for sharing her expertise with us, and to all of the O’Reilly customers whose questions are such an important part of our live events, including this one.
AI tools are quickly moving beyond chat UX to sophisticated agent interactions. Our upcoming AI Codecon event, Coding for the Future Agentic World, will highlight how developers are already using agents to build innovative and effective AI-powered experiences. We hope you’ll join us on September 9 to explore the tools, workflows, and architectures defining the next era of programming. It’s free to attend.
Register now to save your seat.
Commentary
Radar
