Recently, I introduced Claude Code into my Product Management (PM) workflow, and it has been the biggest change in my way of working lately. Specs and prototypes that used to take days can now be done in a few hours, and the AI considers edge cases a hundred times more thoroughly than I do.

This isn't just about asking ChatGPT questions; it's about deeply integrating AI into the Workflow. As stated in Anthropic's Building Effective Agents guide, true productivity gains come from shifting AI from a simple "chatbot" to an "Agent" capable of executing complex tasks.

Core Process: One-Person Product Team

My new workflow looks roughly like this, a convergence process from vague to specific:

Requirement Intake → Claude Skills (SOP) Initial Analysis → Sub-agents (Multi-perspective) Review & Debate → Generate High-Quality PRD + Prototype → Cross-Department Communication → Spec Confirmation

It's like having a virtual team on call, ready to work for you at any moment. Rather than just a PM, I act more like the Commander of an AI Team.

---

1. Claude Skills: Writing Your SOP into the Brain

The concept of Skills is simple: write down the Standard Operating Procedures (SOP) in your head for the AI to strictly follow. This maps to the "Workflows" concept mentioned by Anthropic—guiding LLMs through predefined paths to ensure consistency.

Previously, when writing a PRD, we had to pay attention to naming consistency, formatting norms, team idioms, and remember to reference old documents. The human brain easily misses details; changing A but forgetting creating a bug in B.

Now, I encapsulate these rules into Skills. Here is a real-world requirement-analyzer Skill example:

# Skill: Requirement Analyzer

## Role
You are a Senior Technical Product Manager (TPM), skilled at converting vague business requirements into structured User Stories.

## Input
- Raw Input
- Target Audience

## Output Format (Markdown)
1. **Executive Summary**: One sentence explaining what this feature does.
2. **User Stories**: Format as "As a <role>, I want to <action>, so that <benefit>".
3. **Acceptance Criteria (Gherkin Syntax)**:
   - Given [Context]
   - When [Action]
   - Then [Expected Result]
4. **Edge Cases**: List at least 3 extreme conditions (e.g., Network failure, Empty data, Insufficient permissions).

## Rules
- Must use this format: `FE-[Feature Name]-001` as ID.
- Prioritize Mobile First experience.

When these rules are written as Code (or System Prompts), AI produces output according to preset standards, stable and consistent. Those time-consuming and error-prone cross-referencing tasks are all handed over to AI.

2. Sub-agents: Virtual Avatars for Perspective Taking

If Skills are the "Hands", then Sub-agents are the "Brain".

When writing specs alone, it's easy to fall into blind spots. According to Basecamp's Shape Up Methodology, the biggest risk in product development is rushing into development before the work is properly "Shaped".

To avoid this, I created different Agents to conduct "Self-Dialectics":

• User Researcher Agent: Questions if this flow is intuitive? Is there a better experience?
• Dev Agent: Evaluates technical feasibility, clarifies how to open the database schema, and how to connect APIs.
• QA Agent: Specifically looks for loopholes, listing all possible edge cases.
• Stakeholder Agent: Challenges the necessity of this requirement from a business value perspective.

Simulation Dialogue

Me (PM): "I want to build a 'One-Click Weekly Report' feature."

Dev Agent: "Technically feasible, but consider Context Window limits. If a user has over 500 tickets per week, the API might timeout. I suggest adding Pagination or handling it as an Async Job."

QA Agent: "Agreed. Also, what if there are absolutely no tickets this week? Should the report be blank or show default text? And if the API call fails, should there be a Retry mechanism in place?"

User Researcher Agent: "Wait, do users really want 'One-Click'? They essentially want to edit the AI output most of the time. I suggest the flow be: Generate Draft -> User Preview/Edit -> Save & Send."

In operation, it's like holding an efficient meeting inside the computer. Previously, these confirmations took several meetings back and forth; now, they can be completed within a few hours. This is the ultimate form of "Shift Left"—problems are discovered and solved before the first line of code is written.

3. Instant Prototype: No More Imagining in Communication

This is the most powerful part. Even precise text is not as good as a working visual.

Previously, specs were often written but the design wasn't ready. When discussing with engineers or bosses, everyone could only "imagine individually," leading to big misunderstandings discovered only after launch.

Now focusing on Claude Code combined with v0.dev or Tailwind CSS, I can directly generate frontend code, giving me a working Interaction Prototype.

• Before: "Clicking this button pops up a Modal with three options..." (Engineer: ??)
• After: "Just look at this HTML file, click it and you'll see." (Engineer: Got it.)

Communication efficiency is much faster, and technical details can even be verified before development. No picture, no truth; now I almost always bring a Prototype to meetings.

4. Git Flow: Docs as Code

The last key change is Git Flow. This aligns perfectly with Atlassian's Docs as Code philosophy.

Previously, documents were scattered across Google Docs, Confluence, or Slack conversations, eventually becoming unmaintained trash (Stale documentation). Now I try to put all outputs into Git version control.

Recommended File Structure

project-root/
├── src/                # Source Code
├── docs/
│   ├── adr/            # Architecture Decision Records
│   ├── prd/            # Product Requirement Documents
│   │   ├── 2026-02-feature-A.md
│   │   └── 2026-03-feature-B.md
│   └── specifications/ # Technical Specs
├── .claude/            # AI configurations
│   ├── skills/         # Defined Skills
│   └── prompts/        # Common Prompt Templates
└── README.md

The benefits are:

1. Single Source of Truth: Code changes, docs change right beside it.
2. Code Review: Documentation changes go through the Pull Request process, ensuring they are reviewed.
3. Traceability: Who changed what spec and when is clearly recorded in the Git Log.

Conclusion

Current applications are still very rudimentary, but they have significantly reduced the chance of "producing low-quality documents" and saved a lot of time reinventing the wheel.

Many PMs worry AI will replace them, but I believe AI replaces the "Doer", not the "Thinker". By handing over tedious work (writing docs, drawing charts, searching info) to automation, PMs can spend their time where it truly matters: Decision Making and Communication.

Future PMs might be more like commanders of an AI team, and your value will depend on how many AI Agents you can orchestrate to solve complex problems for you.