Chapter 11: The Evolution of Product Managers

In the Agent era, the value of product managers is no longer “communication and coordination,” but “defining the right problem.” If Agent Engineers are the fleet navigators, then product managers are the chart makers—even a pixel off on the chart, and the fleet might hit an iceberg.

The core transformation for product managers is evolving from “requirement translators” to “business logic architects,” shifting from writing PRD “essays” to “building models” with BDD language. When requirements are expressed through structured Given-When-Then format, Agents can precisely understand business rules and transform vague market needs into executable software systems.

When Agents become the main executors of code, the fundamental contradiction facing product managers has shifted from “development schedule too long” to “whether the precision of my product requirement description matches the speed of Agent generation.”

This is not a simple tool upgrade, but a reshaping of role essence. Product managers must evolve from “requirement translators” to “business logic architects,” from “writing essays” to “building models.” This chapter systematically elaborates this evolutionary path and how product managers can form an efficient duet collaboration model with Agent Engineers.

1 Core Transformation: From “Writing Essays” to “Building Models”

The work outputs of traditional product managers—PRD documents, prototypes, user stories—are essentially narrative texts. They rely on human readers’ comprehension and completion abilities, full of fuzzy spaces and implicit assumptions. When these documents are handed to Agents, problems are exposed: Agents lack human “common sense,” cannot脑补 unspoken boundary conditions, and cannot understand subjective descriptions like “user-friendly” or “premium feel.”

1.1 Abandoning Vague Descriptions

Strictly prohibit mystical vocabulary: “user-friendly,” “smooth,” “premium feel,” “fluent experience”—these terms are invalid information in the Agent era. They cannot be parsed into executable logic, only causing Agents to “imagine” on their own, thereby producing hallucinations.

Provide structured Product Requirement Specs (specifications): Product managers must learn to describe business logic with precise, unambiguous language. A qualified Spec should include:

• Clear inputs: What data does the user provide? What parameters does the system receive?
• Clear outputs: What results does the system return? How does the state change?
• Boundary conditions: How to handle null values? How to compete in concurrent scenarios? How to degrade in abnormal situations?
• State machine transition diagrams: What states does the system have? What events trigger state transitions?

1.2 Defining “Acceptance Cases” First

Before Agents start coding, product managers must first provide key business scenario test cases. These are not traditional “test cases,” but precise expressions of product requirements. Agent Engineers will transform them into automated Evals (evaluation scripts), serving as the “Definition of Done” for Agent work.

This “test-first” model is fundamentally different from traditional TDD (Test-Driven Development):

1.3 Participating in Top-Level Design of “Prompt Engineering”

Product managers must work with engineers to define Agents’ Persona and Value Alignment. This determines the tone of Agent-generated copy and interaction logic:

• Rigorous medical style: Agent-generated content must be conservative, precise, citing authoritative sources
• Lively social style: Agents can be moderately humorous, personalized, encouraging user interaction
• Financial compliance style: Agents must prioritize risk disclosure, compliance requirements, audit traceability

These top-level designs are not “icing on the cake,” but the first line of defense constraining Agent behavior.

2 Core Capability Reshaping: PM “Hardening”

Since code is no longer a barrier, logical rigor is the lifeline for product managers. Here are the three core capabilities that product managers must master in the Agent era.

2.1 Structured Thinking and System Modeling

Why important: Agent Engineers need to break down your requirements into Agent fleet tasks. If the logic you provide has holes, Agents will run wild on the wrong path.

Improvement path:

1. Master UML class diagrams: Able to abstract business entities and their relationships, define attributes, methods, and associations
2. Draw state machine diagrams: Clearly express states, events, transition conditions, and actions
3. Understand sequence diagrams: Describe message passing order between objects, identify synchronous/asynchronous boundaries
4. Business process modeling: Express business closed loops using BPMN or equivalent methods

Key cognitive transformation: Product managers must think like system architects. The foundation of software engineering is state machine transitions; you must be able to clearly define:

• What states the system has (e.g., pending payment, paid, processing, completed)
• What events trigger state transitions
• Entry conditions and exit conditions for each state

2.2 Technical Boundary Awareness (Technical Literacy)

Why important: You need to know what LLMs can easily do, what requires RAG support, and what are current Agent dead zones. Without this boundary awareness, you will make unrealistic demands or miss innovation opportunities brought by technology.

Essential knowledge checklist:

Improvement methods:

• Regularly read capability update notes of mainstream models
• Maintain close communication with Agent Engineers to understand technical boundaries
• Personally use Agent tools to complete small tasks, feel their capabilities and limitations

2.3 Data-Driven Decision Making

Why important: In the Agent era, iteration speed is hourly, with 10 features possibly launching daily. Without rapid data feedback and decision-making capabilities, product managers will become team bottlenecks.

Improvement path:

• Master basic SQL or data analysis tools (like Metabase, Tableau)
• Able to quickly design and interpret A/B Test results
• Establish “hypothesis-validation-decision” closed-loop thinking

3 BDD: The Product Manager’s “Intent Expression Language”

In Agent-Oriented Software Engineering, BDD (Behavior-Driven Development) is no longer just a testing tool, but has evolved into a high-level product requirement expression language for humans to “program” AI Agents.

The most representative language form of BDD is Gherkin syntax. Through highly structured natural language format (Given-When-Then), it precisely transforms human business intent into instructions that machines can parse, verify, and execute.

3.1 BDD Core Primitives

BDD language forcibly structures keywords to break down vague business requirements into system state transitions:

3.2 Case Comparison: Natural Language vs BDD Intent Expression

Traditional natural language (vague requirements):

“As a premium member, if I buy something over 100 bucks, I should get a 10% discount at checkout.”

Problems: What about regular members? Is exactly 100 bucks discounted? Is the discount calculated before or after shipping? Are promotional items included?

BDD language (precise requirements):

Feature: Shopping Cart Checkout Discount Rules (top-level business requirements)

  Scenario: Premium members enjoy 10% discount on purchases over 100 yuan (specific use case requirements)
    Given user "Zhang San" has membership level "VIP"
    And "Zhang San" has shopping cart total of "105.00" yuan
    And items are not promotional special-price items
    When "Zhang San" initiates "submit order" action
    Then the system's calculated final payable amount should be "94.50" yuan
    And the system's order status should update to "pending payment"

  Scenario: Regular members do not enjoy discount
    Given user "Li Si" has membership level "Regular Member"
    And "Li Si" has shopping cart total of "150.00" yuan
    When "Li Si" initiates "submit order" action
    Then the system's calculated final payable amount should be "150.00" yuan

In this example, product requirements are clearly anchored on “preconditions,” “trigger actions,” and “asserted results,” leaving no room for ambiguity.

3.3 Why BDD Effectively Expresses Product Requirements

Eliminating “Hallucination Space” of Natural Language

Large models fear “undefined states,” which cause them to imagine on their own (produce hallucinations). BDD forcibly requires requirement providers to exhaustively enumerate system states (Given) and results (Then). This declarative description method directly frames AI’s generation scope, constraining its divergent thinking.

Highly Isomorphic with LLM Prompt Paradigm

Large models’ optimal prompt structure is usually: [Context Setting] + [Execution Instruction] + [Output Requirements].

This perfectly maps to BDD structure:

Feeding BDD scripts directly to Agents, Agents can instantly understand what kind of system logic they need to build.

Perfectly Adapted to “Requirement-Driven Development” AI Closed Loop

In future development flows, humans only write BDD, not code:

1. Step 1: Humans write Given-When-Then product requirements
2. Step 2: Test Agents directly parse it into automated test code (like Python’s pytest-bdd or Java’s Cucumber scripts). At this point tests must fail (red light)
3. Step 3: Development Agents start writing business code, continuously self-running test code
4. Step 4: When development Agents’ code makes all Then assertions pass (green light), requirements are achieved, Agents stop working

BDD provides AI with objective “definition of work completion.”

Explicit State Machine Transitions

The underlying logic of software engineering is essentially state machine transitions. BDD syntax forces requirement providers to think in “State A (Given) → Event (When) → State B (Then)” manner. This makes it extremely easy for Agent architects to directly transform BDD into database design, domain models (DDD), and API interface definitions when parsing BDD.

4 New Toolbox: PM’s “New Three-Piece Set”

Product managers in the Agent era will no longer rely solely on Word and PPT; the tool stack must move toward the “developer edge.”

4.1 Logic Visualization: Mermaid.js / Excalidraw

Why: Flowcharts are programmers’ language. Using tools like Mermaid.js, you can write flowcharts directly with code syntax, making it easy for Agent Engineers to paste them into Prompts.

Example:

graph TD
    A[User submits order] --> B{Membership level?}
    B -->|VIP| C[Calculate discount]
    B -->|Regular| D[Calculate original price]
    C --> E[Generate order]
    D --> E
    E --> F[Wait for payment]

4.2 Prototype/Interface Instant Generation: v0.dev / Claude Artifacts

Why: Before handing requirements to engineers, product managers should first “self-test” ideas with these tools. If the AI-generated prototype differs from what you want, it indicates description problems—this is early validation of requirement quality.

Workflow:

1. Describe interface requirements in natural language
2. AI generates interactive prototype
3. Discover problems → optimize description → regenerate
4. After confirmation, hand the description as part of Spec to engineers

4.3 Knowledge Base Management: Notion / Obsidian (Markdown-driven)

Why: All PRDs must be structured Markdown for Agents to quickly parse and index. Traditional Word documents are “black boxes” to Agents, while Markdown is “white boxes.”

Best practices:

• Use unified Markdown templates to write PRDs
• Establish clear directory structures and tagging systems
• Version control: Incorporate key documents into Git management

4.4 Collaboration Platform: Linear + Slack/Discord

Why: Use highly integrated tools to track Agent fleet task status, achieving the transformation from “person watching person” to “system autonomy.”

5 The Duet with Agent Engineers

In atomic teams, the relationship between product managers and Agent Engineers is not the traditional “raise requirements-accept requirements,” but deep collaboration of jointly defining product requirements and jointly verifying results.

5.1 Collaboration Model Comparison

5.2 Three Principles of Efficient Collaboration

Principle 1: Product Requirements are Code

BDD Specs written by product managers are “business code,” and Agent Engineers compile them into “technical implementation.” The two are a compilation relationship, not a translation relationship. Product managers must be responsible for Spec precision, just as engineers are responsible for code correctness.

Principle 2: Instant Verification Closed Loop

When product managers modify a Given condition, Agent Engineers should immediately verify its feasibility in the test environment. This “say-try-adjust” micro-cycle replaces the traditional “review-modify-review again” big cycle.

Principle 3: Errors are Assets

Every time Agent output doesn’t meet expectations is an opportunity to improve product requirement expression. Product managers and engineers should jointly analyze: Is the description not precise enough? Or are constraint boundaries unclear? Then沉淀 learning outcomes as product requirement templates to prevent the team from repeatedly stepping into the same pitfalls.

6 Quick Start: 21-Day Transformation Plan

If you want to start evolving immediately, here is an actionable training plan:

Week 1: Mindset Transformation

Day 1-2: “Pseudocode” Training Try writing a functional requirement you’re most familiar with without using any adjectives, purely with If...Then...Else... logic.

Day 3-4: Prompt Reverse Engineering Find an excellent AI product and reverse-engineer what business logic constraints might be included in its system prompt behind it.

Day 5-7: Participate in a “Code Review” Although you don’t write code, ask Agent Engineers to show you the structure of Agent-generated code. Understanding logic behind code is more important than understanding syntax.

Week 2: Tool Mastery

Day 8-10: Mermaid Flowcharts Draw all core business processes you’re responsible for using Mermaid syntax.

Day 11-14: BDD Practical Application Choose an upcoming development requirement, write complete BDD Spec using Gherkin syntax, and work with engineers to transform it into automated tests.

Week 3: Deep Collaboration

Day 15-17: Prototype Self-Testing Use v0.dev or Claude Artifacts to independently transform an idea into an interactive prototype, validating clarity of requirement description.

Day 18-21: Full Process Closed Loop Pair with an Agent Engineer to complete a complete small feature from product requirement definition to acceptance launch, experiencing the duet collaboration model.

Chapter Summary

Product manager evolution in the Agent era is a paradigm leap from “soft skills” to “hard logic”:

Core contradiction shift: From “development schedule too long” to “whether requirement description precision matches Agent generation speed.”

Deliverable upgrade: From narrative PRD to structured BDD Spec, from “writing essays” to “building models.”

Key capability reshaping:

• Structured thinking and system modeling capabilities
• Technical boundary awareness (Technical Literacy)
• Data-driven decision-making power

Collaboration model evolution: Form a duet of “product requirement definition-verification closed loop” with Agent Engineers, rather than traditional “raise requirements-accept requirements.”

BDD as core language: Given-When-Then structure is both precise expression of business requirements and Agent acceptance criteria, and the “magic spell” for humans to control AI development armies.

Transformation golden quote: If Agent Engineers are the fleet navigators, then product managers are the chart makers. Even a pixel off on the chart, and the fleet might hit an iceberg.

In the Agent era, the value of product managers is no longer “communication and coordination,” but “defining the right problem.”