AI Product Manager's Responsibilities Are Completely Changed in the AI Era

In the past, we as AI product managers were all trying to use AI in our workflows as much as we can. As AI has coding capability, our work and responsibilities also started to change.

A while ago, when I was working on an AI video product, it took me just over a week to go from defining the product features, to vibe coding a demo, to running through the entire workflow. That genuinely surprised me. If AI products can be built so quickly, then where is the product moat?

This article is mainly about the practical methods I have summarized after several weeks of thinking and hands-on work. It covers effective ways to build demos, and also how AI product managers need to transform our capabilities in this era: what the new job reponsibilities are, how to promote products, how to find paying users, and how to improve product retention and business returns.

1. Building Product Demos

As AI product managers, we need to get hands-on and build demos ourselves.

In the past, a product manager's work was mainly about writing PRDs, communicating details with engineers and designers, and gradually refining the PRD. Whether it was requirement communication or documentation, the essence was to clarify what the product should do and how it should work.

But now, a functional demo already contains most of the answers that a PRD is supposed to provide. Below are the methods I have found effective through repeated vibe coding practice.

Clarify the requirements first, then start building.

First, when collaborating with AI tools, I describe the requirements clearly. For example, when talking to Claude Code, I may ask it to record my requirements first. Installing the superpowers skill can make this more efficient. The requirements do not need to be perfectly thought through all at once. I can continue thinking while talking to AI. Step by step, I add more context about the product plan, product scope, and boundaries. The AI records and learns bit by bit until it has collected a complete set of requirements.

Second, and this is critical, I ask the AI to repeat the requirements back to me. Sometimes it executes quickly and starts working as soon as it receives my requests. If the details are unclear, the implementation is not valuable, and I will have to fix it later. Even in Plan Mode, the requirements themselves still need to be clarified. It's like making an agreement with AI on what and how to build. If I am using an AI tool inside an IDE, I can add a constraint to the CLAUDE.mdfile. The content it “repeats back” is essentially the PRD once it is cleaned up.

Third, I take the organized PRD and ask another AI tool, such as Codex, to review it. Yes, I mean reviewing the requirements themselves. The goal is to make sure the product framework is reasonable and the details can be implemented. If the review finds no major issues, I then let the AI begin demo development.

Run through the core product path first, then build the frontend container.

In traditional internet product development process, teams often build the frontend functions first, then debug the backend APIs. For AI products, we can use a different approach: run through the backend API first.

For example, in AIGC products, the priority is to successfully complete content generation through the API. Only after that should we think about how to provide users with a good experience through a frontend functions on UI.

First, clarify the orchestration of large models. For an AI video product, this includes how to generate the video script, which large language model to use, what content the video model should receive, such as system prompts, scripts, and skills, how the video API processes the content, what the API input and output requirements are, and how to control the quality of the generated video. This also includes choosing which API gives better results, what type of result the API returns, and whether any post-processing is needed. Only when this core path is complete and the demo can successfully generate content can the demo be considered working.

Second, build the front-end functions. Based on an understanding of the business, user habits, usage scenarios, and brand visual style, complete the frontend development. The product should be both easy to use and valuable to the business.

During development, if I encounter an unfamiliar model, I usually solve it in two ways.

One way is to look for tutorials online and learn the process. The other way is to try it myself. No matter how good other people's examples are, they are still other people's experience. Only the experience gained through hands-on practice becomes my own. That is how I learn how to use a large model well and help it create the most value.

If I am not familiar with the capability boundaries of a certain model, I go directly to the official API documentation. I first clarify its usage requirements before developing with it. Every demo test consumes tokens, and tokens are not free. If I clarify the requirements in advance and avoid possible problems, I can save cost. Of course, I can also run many attempts first and slowly discover the patterns that work for me.

It is also possible to throw the model documentation to AI and let it learn first then execute. But I have found that it is more efficient when I understand it myself first and then guide the AI. When hallucinations cause problems, I can also locate them quickly and instruct the AI to fix them.

When I build demos, I do not hand over all of my thinking to AI. AI assists me by helping me learn technical knowledge and explaining things to me. This process of learning first and then practicing helps me accumulate experience and build my own judgment.

Choose the most appropriate technical architecture.

When I build demos, I do not only rely on vibe coding only. I also think about product architecture. Sometimes I use workflows, skills, or even agents to run through the core path of the product. No matter which method I choose, the goal is to run it through first, get the business result, and then adjust the technical solution.

For areas I have not worked in before, I may even find an existing approach and adapt it directly so that I can get results as quickly as possible. Once the product direction is confirmed, I can work with the engineering team to adjust the architecture.

For something like a system prompt, I can quickly build a local evaluation page, run five cases, and check the results. If I find a relatively stable version, I can put it into the demo first and optimize it later as part of the whole system.

A demo is the way we as AI product managers turn product ideas into reality by leveraging the capabilities of large AI models. We are responsible for model orchestration, for giving direction and defining architecture, and then ask AI to execute. But the results generated throughout the process still need human control. AI provides evidence and implementation details, but we are the ones ultimately responsible for the product direction and outcome.

2. Helping AI Products Achieve Business Results

In the AI era, once a large model is connected to a product, implementing functionality is no longer the hard part. In other words, the moat at the basic capability level has already disappeared. Almost every product can access SOTA-level model capabilities.

So how can a product show differentiation?

After trying this many times at work, I found that the real difference is whether the product truly understands users.

Every product ultimately serves end users. The real product moat is understanding users' needs and pain points, knowing how to provide the right services and support inside the product. At the core, it is about building trust with users. And that trust is based on sincerity and respect.

Build channels for communicating with users.

When I was building products before, I often encountered situations where we had several seemingly good solutions after analysis, but could not make the final decision. In that case, the demo needed to be put online. Users could try it, then give feedback based on their actual experience, which helped the team make the final decision.

If the product can be launched directly and judged through real data, that is even more effective.

  • Broad-channel communication.

To get user feedback, I went to different platforms and directly looked for users to talk to. For example, on Reddit, I invited users to try the demo and give feedback. I also posted discussions about different features and user preferences. Sometimes I would take AI-generated content from the product and post it publicly as a showcase. Interested users would leave comments, and then I would continue the conversation through private messages. While collecting demo feedback, I also found that users would comment on the generated content itself, and some would even ask the prompts and what AI models I used. When communicating in public channels, it is important not to be too transactional. Focus on discussing the content itself with users. The purpose of communication is not to drive traffic or sell the product. If we put ourselves in the user's shoes, it is similar to seeing a salesperson on the street. We naturally want to avoid being sold to. The intention should be to open-minded and collect different perspectives on the product, not to grab users and pull them in for a quick sale.

  • Niche-channel communication.

If the users belong to a specific customer group, communication can happen on specific platforms. Through reverse thinking, I found platforms where AI content creators gather. I contacted them one by one and scheduled in-depth interviews by offering gift cards as rewards.

These users are almost like domain experts, and they enjoy talking about professional topics. If the communication is objective, rational, and genuine, it is often easy to move them. Sometimes I found that they are actually quite picky. Even if I paid to talk with them, some of them still rejected to share their experience with me. Professionalism and honesty are the foundation of collaboration. The ideal state is to become the user myself. If I can become a KOL in a specific niche market, I can experience the user's feelings directly.

  • Build personal channels on social media.

Product updates and iteration cycles are becoming faster. It is not realistic to conduct user research every time a key product decision needs to be made. A/B testing alone only provides quantitative feedback, not qualitative insight. Therefore, building personal channels is an effective way to reach target users and collect feedback. While doing research, I found that before the official launch of the Gemini 3 model, it would be put into a core user group for small-scale testing. In a public interview, the founder of Gamma also mentioned that they created a Slack group for core users. Before launching new features, they would share them in the group to collect feedback.

A product director of Dify also occasionally schedules interviews with users in their product community. Once an official channel mechanism starts working, it can ultimately improve the efficiency of product launches.

Product moat: serve the core customer group well.

The AI creators I have met have both the ability to pay and the ability to learn. Their pain point is how to use AI tools well to create high-quality AI videos, such as product promo videos and product advertisements in e-commerce industry. They need both examples and workflows that can reproduce those examples.

The gap between AI products and actual content or results needs to be bridged by AI product managers. Helping users generate high-quality content, and accumulating the methods and data used in the process, will make the product understand users better.

These methods can then be solidified into specific rules and written into skills. By continuously polishing them according to user needs until they can reliably help users achieve results, the product moat will gradually grow.

Building trust with users takes a long time. Destroying it may take only one moment. Any product becomes better by helping users achieve effective results. When users succeed and gain value from the product, the value of the product also increases.

3. Work and Learning Methods in the AI Era

The working methods of AI product managers have been completely changed by the improvement of large models. We need to adjust the way we work around the characteristics of these tools. Everyone is learning from zero.

If AI can write code, we need to learn how to use it to develop demos. If large models update faster, our learning ability must follow their steps.

The half-life of knowledge is accelerating.

Traditional industries such as finance and law have existed over decades. Their core knowledge changes slowly and requires long-term accumulation. But AI and the internet industry are emerging industries, where knowledge updates and iterates very quickly.

This requires practitioners like us to accelerate our learning process. Sometimes it feels impossible to keep up with everything. Based on my own work and learning experience during this period, I cannot catch every iteration and update. But I do need to learn as much as I can based on my judgment.

For example, in the AIGC field, I need to learn about iterations and updates in multimodal large models. In addition, industry-level events like OpenClaw must be followed and practiced hands-on. For other industry news, it is enough to find reliable information sources and browse them every day.

The learning method is changing.

In the past, learning new knowledge could happen through offline sharing sessions, books, or communities. Now, AI can assist with our learning process.

For example, I ask AI to explain technical concepts and knowledge, help me build thinking frameworks, and expand my cognition. Also, in this era, the most important thing after learning is to practice. The value of hands-on work is far greater than the value of reading materials.

If I only read without doing, my head may be full of methods and ideas. But unfortunately, maybe none of them can be implemented, and no result will be achieved.

Real value is extracted and summarized during the process of practice and iteration. It cannot be gained simply by reading books or taking online courses. In fact, the value of personally taking action and getting results was also important in the past. AI has simply amplified that value exponentially, making the gap more obvious.

Over the past six months of learning and practice, I have found the most effective method is simple: just do it.

In the past, changing a product feature required meetings and discussions among multiple teams for half a day. Now, as long as I know where the problem is, I can directly solve it and push it online. Even when building my own startup product, once the backend runs through, I launch it first and then optimize the frontend bit by bit.

AI narrows industry differences and dissolves job boundaries. With AI tools, everyone can actually do this. The key is whether willingness is strong enough, and whether the person has truly taken action.

I even feel that in a high-value team, everyone can become an OPC, a one-person company. The collaboration model of the industrial era no longer has to define everyone by a single specialized role. In the past, collaboration was used to reduce domain barriers and make the business model work.

Now, each person can combine AI with their own field and independently run through a business model. When people collaborate, the goal is to exponentially amplify each person's business value.

4. Physical and Mental Health Matter More Than Work

When I was building my own startup product, I worked with AI at high intensity every day. When Claude Code ran out of tokens, I immediately switched to Codex and continued development. I did not want to waste even one minute. I just wanted to get the product online within a few weeks and push it to users as soon as possible.

As a result, in the final week of development, all kinds of problems and bugs exploded at the same time. After I fixed one bug, three more appeared. Even though development problems that AI could not solve, I still felt overwhelmed. I could only hold my temper and modify things bit by bit. It was so exhausting that I felt like my soul was burning out.

After the product finally launched successfully, I not only did not want to work, I did not even want to touch my laptop. I had to spend two weeks slowing down my life, getting sunshine everyday, and meditating to relieve mental exhaustion and tension.

High-intensity AI use can amplify negative emotions.

Using AI tools at high intensity for a period of time can amplify anxiety.

On one hand, because AI is so capable at solving problems, I start to feel that it must solve the problem for me. If it does not solve it, that is unacceptable. If it does not solve it, I become anxious.

On the other hand, the smarter it gets, the higher my expectations become. If it can produce a result in one second this time, then next time I want it to produce a result in 0.1 seconds. If it fails to meet my expectation, my mindset collapses, and I may even want to yell at it, although that does not help.

This quickly consumes my patience and keeps me mentally tense for a long time without enough rest. Without realizing it, I may also transfer my expectations of AI onto people. My basic patience disappears. When collaborating with colleagues, if they cannot solve a problem, my emotions may explode instantly.

AI exists to make human life better.

AI can work without sleep, but humans cannot.

I have always believed that using AI at work is about letting it support me and help me solve problems. When I use AI in life, it is also to solve problems and improve my quality of life afterward. It is not meant to replace my job, and it must not destroy my life.

If these negative phenomena appear because of AI, then the way I am using it is wrong.

Adjusting physical and mental health cannot be completed in a moment. It requires long-term, conscious change.

If we have demands for AI but no patience, does that reflect the fact that we may treat people the same way, and AI has simply amplified the issue? If our expectations of AI keep rising, are we also using the same standard to demand more and more from ourselves and from people around us?

AI is a mirror. There is still more work to do.

In different eras, the content and methods of work will continue to change. But mental health is the foundation of inner stability.

In the AI era, we need to keep learning, keep taking action, and adapt to the trend. But we also need to adjust ourselves. We need introspection and inward seeking. We need to understand ourselves deeply: what we are capable of, what kind of environment allows us to perform well, and what kind of life makes us feel more enjoyable.

Paying attention to our mental health and inner energy is more important than paying attention every day to what is happening in the outside world.

<- olderReflections on Technical Architecture Analysis for AI Productsnewer ->How an AI Product Manager Can Use AI to Run High-Quality User Research