A friend of mine wants to switch to the position of AI Product Manager, and I advised him not to rush to revise his resume for the time being.

An old friend who has worked in retail for seven or eight years wants to switch to being an AI product manager, and his resume is stuffed with terms like RAG and Agent. I advised him not to modify it first, but to read the job description carefully first. The position only requires three things: a demonstrable work, a clear evaluation standard, and metrics you have been responsible for. No AI project? Just build one on your own.

A while ago, an old friend asked me out for dinner.

He has worked in retail operations for seven or eight years, having managed physical stores as well as regional marketing campaigns. Halfway through the meal, he pushed his phone over to me, showing his newly revised resume on the screen: "Help me take a look, I want to switch to being an AI product manager."

I glanced at it and felt a jolt in my heart.

The skills section was neatly written: Familiar with large language models, RAG, Agent, and Prompt Engineering. An extra line was added to his work experience: "Participated in the AI-enabled store operation project".

I asked him what this project was specifically about. He froze for two seconds and said that the company launched an AI customer service system last year, and he assisted with its go-live.

I couldn't help laughing. He looked a little embarrassed, so I quickly explained: This kind of resume is all too familiar to me. In the years I have been working on AI products, I often sit on the interviewer's side, and most of the resumes I receive look exactly like this.

Then he said something that made me feel quite bad: "Am I unable to make the switch? I have never worked on an AI project, never written code, and never even been a proper product manager."

I said it is possible, but you have to throw this resume away first.

Do not modify your resume before reading the JD carefully

I asked him to open Liepin on the spot, save two job descriptions, and read them from beginning to end.

The first one is for a C-end AI Product Manager position at McDonald's China, based in Shanghai, requiring 5-10 years of work experience, with a salary range of 25-40k * 16 months.

The second one is for a Product Manager position in the Meituan Flash Purchase Agent Product Team, based in Beijing, requiring less than 1 year of work experience, with a salary range of 25-40k * 15 months.

One sells hamburgers, the other operates instant retail services. One requires experienced practitioners, the other also accepts candidates with less than 1 year of experience.

But when you read the job requirements side by side, they are asking for the exact same thing. McDonald's writes "Candidates with hands-on experience building AI products independently, such as experience in building AI product prototypes, are preferred", while Meituan writes "Able to develop demos that real users can actually use, rather than only staying at the PRD prototype stage".

He looked up at me after finishing reading: "That's all?"

Yes, that's all. After reading through both JDs, there is no requirement asking you to understand model structures, training data ratios, or to publish academic papers. The employers only want three things: a demonstrable work, a set of clearly explainable evaluation standards, and a performance metric that you have been responsible for.

That line of "Familiar with RAG, Agent" on your resume will not be believed by any interviewer. If they ask you two follow-up questions, you will immediately expose your lack of real experience.

He has actually been doing this kind of work all along

I asked him to take a closer look at the McDonald's JD. It requires candidates to "define efficiency improvement process standards and effect evaluation metrics", "establish a core AI product indicator monitoring system, drive product iteration through data, and output business value assessment reports", and also "lead the end-to-end implementation of AI products... optimize functions through gray testing".

He stared at it for a long time and said that this is exactly the set of workflows we use for activity post-mortems.

More or less. First find the part of the process that can be simplified, then track it with metrics, finally test it on a small scale and gradually expand the coverage. Calculate how much time is saved, how many people no longer need to do repetitive work, and whether customer experience has deteriorated. He calculated these metrics every day during the years he managed physical stores, no one ever told him that this is called evaluation standards in the AI product field.

I felt quite emotional at that moment. Many people switching from traditional industries hold the most valuable assets in their hands, but they think they have nothing at all. They rush to sign up for training courses, memorize jargon, hide their real skills, and put the most superficial and empty content at the top of their resumes.

I myself switched from a business role, and I did exactly the same stupid thing in my first year of transition. I hid all my past work experience and filled my resume with newly learned terms. After reading my resume, the interviewer asked me: What did you do in those years before? I couldn't answer, and the interview ended in just twenty minutes. Later I realized that those years of experience are exactly the most valuable content I can talk about.

The Meituan JD has narrower but deeper requirements. "How to trigger the task, how to provide fallback solutions when it gets stuck, when human intervention is mandatory, and how to deliver the results" — four actions in one sentence, which is essentially an Agent design checklist. There is another line later: "Identify its failure modes and breakpoints through evaluation and monitoring; attribute Bad Cases, and turn the vague feeling of 'it doesn't work' into clear conclusions of 'where it doesn't work, why, and how to fix it'". The last line "Take responsibility for online task completion rate and core business indicators" is the most important part of the entire JD.

These are exactly the questions that applied AI product managers are asked: Whether this task should be handed over to the model, who will take responsibility when errors occur, how to set the metrics, and whether the cost is affordable. Model structures, data ratios, and leaderboard rankings are the concerns of research-oriented positions, which he does not need to touch.

When you put the two JDs together, you can also see the difference in work experience requirements. Meituan accepts candidates with less than 1 year of experience, as long as you have relevant hands-on experience and can clearly explain every bottleneck point. McDonald's requires more than 5 years of experience, and in addition to hands-on capabilities, you must also have experience in setting standards, building monitoring systems, and calculating business benefits.

If you have no AI project experience, just build one on your own

Back to the sentence that made him most anxious: "I don't have AI project experience."

Then build one. You don't need approval from the company, and you don't have to wait for the IT team. Just pick one thing you are most familiar with.

He has plenty of materials at hand: store shift scheduling, display inspection, activity post-mortem, supplier account reconciliation. Each of these tasks has its own process, metrics, and a bunch of annoying repetitive operations. Pick one, use existing tools to build a minimum viable demo that can run, and can demonstrate "what input you put in, what output you get, where errors may occur, and who will take over when errors happen" — that is more than enough.

When talking about shift scheduling, one person says "I have researched several AI shift scheduling tools"; the other opens the page and says: "I imported the historical passenger flow data and working hours data of the store, the schedule generated by the tool has three conflicts, and I added three rules to make it work properly."

If you were the interviewer, which candidate would you pick?

He asked me how long it would take to build this. I said one weekend is enough to build a relatively rough version. It doesn't matter if it looks ugly. What the interviewer cares about is where you got stuck and how you solved it, no one cares if the interface looks good or not.

I made this point very clear to him: Do not forcefully fit your business experience into an AI project. "I organized the store shift scheduling rules into judgment conditions and used tools to run a prototype version" is your real experience. If you write it as "Responsible for the launch of the AI shift scheduling product", that is fabrication. If the interviewer asks one more question "Has it been launched? Who is using it?", you will not be able to justify yourself.

That line "Participated in the AI-enabled store operation project" on his resume was deleted that same night.

Every line on your resume must pass three rounds of verification

After years of working as an interviewer, my deepest insight is: every line written on your resume will be followed up with further questions, usually three rounds. What decision did you make, why did you make that decision, and what did you do when the result was not as expected.

If you can answer all these questions, the interview will continue. If you cannot, the interview ends and we move on to the next candidate.

I am used to dividing supporting evidence into four levels. The strongest level is demonstrable work plus data: a demo that can be opened with one click, and a change in task completion rate. The medium level is post-mortem review: the product may not be fully operational, but you can clearly explain how you made judgments at that time, which solution was rejected, and how you fixed the problem after failure. The weak level is responsibility description: "Responsible for AI product planning and implementation", after reading which the interviewer has no idea what decisions you have actually made. The worst level is jargon piling, which is exactly the version he showed me at the dinner table.

The thing I hate seeing most is "efficiency improved by 30%". Every time I can't help asking: What is the baseline? Which specific step you took led to this 30% improvement? What other changes were made at the same time? After these three questions, most people cannot give a valid answer. The number itself is not wrong, but without baseline and control group, it is just a meaningless decoration.

I asked him to take a piece of paper, copy the original sentences of the target JD on the left, and write down which part of his experience matches the requirement and what specific data he can cite on the right. For content that does not match, either delete it, or rewrite it to describe "what judgment I made at that time".

He was reluctant to delete the content.

I said, writing down content that you cannot answer is more harmful than not writing it at all.

Taking the Meituan JD as the standard, a piece of experience can be split into four lines (example writing):

Work: "Handed over three tasks in merchant account reconciliation to Agent: automatic verification, exception marking, and to-do list generation. Demo is available via the link."

Workflow: "Where are the trigger conditions, failure retry rules, and human intervention thresholds set, and why are they set at those values."

Attribution: "The vague feedback of 'it doesn't work' was finally found to be caused by missing fields returned by the tool. We fixed the schema instead of modifying the prompt."

Metrics: "The task completion rate increased from X to Y, and this was the only variable we modified during the same period."

When all four lines are supported by real experience, you will not panic when facing three rounds of follow-up questions.

All interview questions are actually written in the JD

Many people think interview questions are randomly selected. In fact, the JD in your hand is the question bank.

Scene trade-off: Should this task be handed over to the model? Don't rush to give a solution, first explain the judgment basis: How high is the cost of one mistake? Can the operation be rolled back? How much does it cost for a human to complete this task once?

Metrics: How to define the task completion rate? Which metric should we prioritize when two metrics conflict? You need to give one main metric plus one guardrail metric, and clearly explain which one to prioritize in case of conflict. I once failed this question myself. Back then I only reported the main metric, and when the interviewer followed up and asked "What if the user experience deteriorates?", I got stuck on the spot and my face burned.

Fallback mechanism: Which step must be taken over by a human? Write down the takeover as specific conditions, and specify what signals will trigger the transfer to human intervention. Vague statements like "human intervention when necessary" are completely useless.

Cost and latency: How much does one call cost? How many seconds of delay will start to cause user churn? This question requires specific numbers as the answer.

Large companies like McDonald's will ask additional questions: How to verify the efficiency improvement? Is it really reducing working hours, or just replacing the tool? How many users will be included in the first gray test, and under what circumstances will you roll back the version? If you cannot answer these questions well, the demo you showed earlier will be regarded as a toy rather than a practical product.

There are four things I advised him never to fabricate: data, personal responsibilities, launch status, and team size. Gray testing is not full release, and the team's achievements are not equal to your personal achievements. Once you say something wrong, everything you say afterwards will be questioned.

If you have no relevant experience, just say so, and then explain how you will solve the problem. This is much more reliable than making up a fake process, and far more useful than saying "I have strong learning ability".

After that dinner

We ate very late that day. When he left, he said he would go back and build the shift scheduling demo first, and would not submit any resumes for now.

Some days later, he sent me a screen recording. The shift scheduling demo was running, but there was still one conflict that had not been resolved. I said that is perfect, you can talk about this unresolved conflict in the interview, explain what you have tried, and why it has not been fixed yet.

I forwarded a line from the Meituan Flash Purchase JD to him: "Even if you do not meet every single requirement, you are welcome to come to talk with your Agent work."

This article is from the WeChat Official Account "Everyone is a Product Manager" (ID: woshipm), author: Donggua, published with authorization from 36Kr.