Product managers who can only write documents have no future. AI programming agents are ending the era of "translators".

God Translation Bureau is a compilation team under 36Kr, focusing on fields such as technology, business, the workplace, and life, with an emphasis on introducing new technologies, new ideas, and new trends from abroad.

Editor's note: The era of translation-style product management is over. When AI eliminates the execution cost, profound problem definition and unique product taste have become the only moat for this profession. This article is a compilation.

Last week, I wrote about how I use AI agents in my work. Unexpectedly, this article sparked a bigger topic - the ongoing transformation of the role of product managers (PMs) themselves.

For example, how "context curation" has become a skill that no one talks about but that all efficient people have mastered. Another example is how I used AI Studio and Claude Code to transform scattered ideas into a runnable prototype within just a few hours.

I clicked "Publish" on X, closed my computer, and woke up the next day to find thousands of notifications.

Within just a few hours, this article went viral. Many of you resonated with it, shared your own stories, and further promoted this discussion.

In the past, the essence of a product manager's job was "translation."

You communicated with customers, summarized the problems they faced, wrote requirements documents (specs), and then handed them over to engineers. You were the bridge between "user needs" and the "actual product." And the value of a PM was reflected in this translation level.

Now, this layer is being compressed.

When an agent can receive a clearly defined problem and generate runnable code, the focus of a product manager's work shifts. You are no longer translating for engineers but rather refining your intentions to be clear enough for the agent to take direct action based on them.

Requirement documents are becoming the product itself.

I've seen this change in myself and dozens of other product managers. In the past, a product manager had to write a detailed document, hand it over, wait for questions, clarify, wait for development, conduct reviews, give feedback, and then iterate. The entire cycle took weeks. Now, they just need to write a clear problem statement with constraints and hand it over to the agent. They can review the running code within an hour.

The time difference between "I know what to do" and "the thing is done" has disappeared. However, the work of "determining what to do" has not become easier; instead, it has become more important.

You don't need to write code yourself, but you must clearly know what you want, so clearly that the agent can directly develop it. Requirement documents and prototypes are merging into one. You just need to describe the requirements, watch it take shape, correct the deviations, and then iterate. The bottleneck is no longer at the execution level.

Moreover, the pace of product release will only get faster.

I've worked at Google for about three or four months, and it feels like the products we've released during this time are equivalent to the AI progress of the past few years. Just within this window period, we've launched Gemini 3 Pro and Flash, the Multimodal Live API, Nano Banana Pro, the Deep Research Agent, the Google Interactions API, and the Java/Go/TypeScript versions of the ADK, etc.

Thanks to AI programming agents, AI companies of all sizes are advancing at this speed. The product development cycles that once defined the industry - from quarterly planning, monthly sprints to weekly releases - are being compressed into a state closer to "continuous deployment of creativity."

As the threshold for implementation drops so rapidly, the bottleneck starts to shift upstream. The scarce resource is no longer the engineering development ability but the ability to judge what is truly worth doing.

The New Skill Set for Product Managers

Problem shaping: The best product managers I know have always been good at this, but in the past, it was just one of many skills. Now, it's the "core" skill. Can you shape a vague customer pain point clearly enough for an agent or a group of agents to act on it? Can you identify the truly critical constraints? Can you clearly articulate what the success criteria are?

A requirement document is no longer just a document but a well-defined problem with clear boundaries.

Context curation: This is a skill that no one talks about, but every product manager who is good at collaborating with agents has mastered it. The quality of the agent's output is directly proportional to the quality of the context you feed it.

When I first started working with agents, I would give vague prompts: "Help me create a customer feedback dashboard." The thing I got was technically feasible but completely missed the point. Because it didn't understand our users, our constraints, or our definition of a "good product."

Now, I maintain a "context document" and feed it to the agent before starting any project. Over time, I've figured out the truly critical content in these documents:

• Specific, real users. Not fictional user profiles but real details: who they are, what they care about, what would make them give up, and what would attract their attention.

• Describe the problem in the users' own words. Directly quote call records, work orders, or sales records. Use their language instead of your summarized language. This can anchor the agent to the real pain rather than an abstract one.

• Define what is "good." Provide examples that the team considers well-designed. Your past works, competitors' products, or related products. Show directly rather than simply describe.

• What has been tried and why it failed. The organizational experience that usually exists in people's minds. The solutions you've rejected and the reasons.

• Shape the constraints of the solution. Not all restrictions but those that will truly change the final form of the product.

• How to judge if it works. Specific, not vague. Some metrics that you can truly measure or observe.

Now, when I ask the agent to create a prototype, it doesn't start from scratch. It knows who we're developing for, what the users actually said, what the good standard is, and which paths are dead ends. Because the input information is specific enough, the output result fits perfectly.

Evaluation ability and taste: Taste has always been underestimated. But when agents can produce quickly and in large quantities, taste becomes the most important skill. Does this really solve the problem? Does it handle those critical edge cases? Is this the version we should release, or is it just a runnable version?

This is more difficult than it sounds. Agents will very confidently generate things that seem correct but are actually completely off the mark. You need to develop this taste through continuous practice (reps).

There is no shortcut: You must do it yourself, evaluate it, and feel the difference between "meeting the release standard" and "being technically feasible."

The Shift in Mindset

This is how I think now:

Old model: PM thinks about what to do → writes a document → engineers develop → PM reviews → iterates

New model: PM thinks about what to do → PM collaborates with the agent to develop → PM evaluates → rapid iteration → (after being satisfied) hands it over to engineers to launch in the production environment

Product managers in the AI era are no longer just handing over requirements. They will do the "atmospheric programming" for the first round of iteration themselves, getting real feedback on runnable software instead of just giving instructions on slides or Figma prototypes. The role of engineers also changes accordingly. They are no longer the translators of your intentions but the collaborators on how to make the product better and more production-ready.

This changes your relationship with the product. You are no longer just describing the requirements and hoping they will be correctly implemented. You are shaping it in real-time and directly.

Have an iterative mindset. Allow the first version to be wrong. Don't try to think it through perfectly in your head before starting. Provide rich background information to the agent and let it make a draft first. Look at the output, react, and then iterate. You can learn more from "this doesn't seem right because..." than from trying to think through every edge case in advance.

I often ask the agent to try two or three completely different solutions at the same time just to feel which one is the most suitable in use. In the past, this was very costly. Now, it's just a matter of starting a few parallel agents on a Tuesday afternoon.

Tolerate ambiguity for a longer time. In the past, a PM's instinct was to quickly turn vague ideas into documents. Now, the instinct is to stay in the ambiguous zone for exploration. Don't lock in a solution too early. Let the agent help you fully understand the possible solution space before making a decision.

How to Get Started

If you're a product manager who hasn't tried this way of working yet, you can start here:

Pick a small problem you're really facing. Not a fictional problem but something that's bothering you right now. For example, a report that has to be manually summarized, a cumbersome workflow, or a prototype you wish existed.

Spend 30 minutes writing a context before inputting the prompt. Refer to the complete list in the "Context curation" section above.

Direct the agent to this problem and see what happens. Don't expect perfection. Treat it as a starting point. Give feedback to it, guide it, and keep iterating.

Repeat this ten times. For different problems with different complexities. You'll gradually develop an intuition: what methods work, what background information is important, and how to evaluate the output. This intuition is the new skill for product managers.

The product managers who can stand out are those who understand the problem so thoroughly that the solution is obvious to them and the agents they use.

I switch between AI Studio, Cursor, Antigravity, and Claude Code depending on the task. The tools themselves are not important. What's important is to develop the habit of collaborating with agents every day and exercise this "muscle memory."

Finally, here's a message for everyone...

If your job is mainly about translating customer requirements into documents for engineers, it's just a workflow. And workflows will eventually be automated.

If your job is to "deeply understand the problem so that the correct solution will naturally emerge," then you'll be more valuable than ever. Agents will turn this deep understanding into a launched product at a speed far faster than any previous team.

Every product manager should ask themselves: What's left when the "translation layer" disappears?

For the best product managers, the answer is: everything that truly matters.

Understanding the problem, empathy, judgment, and taste. These have always been part of a product manager's job. And now, they're becoming the whole job!

Translator: boxi.