Be the PM Who Ships, Not the One Who Documents

The Documentation Trap

There is a version of product management that is mostly documentation: the week-long PRD that never fully aligns anyone, the ticket backlog that grows faster than it shrinks, the roadmap that gets revised before it gets used. This version of the job feels productive because it generates visible output, but it is often a delay mechanism between good ideas and shipped features.

The PM who ships has a different default. They bias toward getting something in front of engineers and users faster, using documentation as a communication tool rather than a gatekeeping ritual. AI makes this shift dramatically more accessible because it compresses the time between "I understand the problem" and "here is a clear enough spec to build from" from days to hours.

The Ship-First Workflow

The ship-first workflow has three stages that replace the traditional two-week documentation cycle. First, a 30-minute discovery synthesis session where you paste your raw research and ask Claude to produce a problem statement and a ranked list of user needs. Second, a 45-minute spec generation session where Claude produces a first draft spec you refine with your own judgment. Third, a ticket generation pass where Claude breaks the approved spec into well-scoped engineering tickets ready to drop into your backlog.

The total active PM time across all three stages is roughly two to three hours. The traditional approach, with multiple review rounds and stakeholder alignment sessions, often stretches the same output across two weeks. The difference is not in the quality of the decisions. It is in the speed at which those decisions become something an engineer can act on.

Three Prompts That Replace a Week of Docs

The first prompt synthesizes research into a problem statement. Give it raw material and ask for a structured summary. The second prompt generates a spec from the problem statement. Give it the problem statement plus any constraints and ask for a draft spec. The third prompt breaks the spec into tickets. Give it the approved spec and ask for scoped engineering tickets with acceptance criteria.

These three prompts, used in sequence, produce a complete PM deliverable for a feature in one focused afternoon. The output is not perfect on the first pass, but it is complete enough to review, align on, and move forward from. That is the point. The goal is not a perfect document. It is a clear enough direction that the team can start building.

import anthropic

client = anthropic.Anthropic()

def generate_ticket(one_liner, context=""):
    prompt = (
        "Feature request: " + one_liner + "
"
        "Context: " + (context or "No additional context provided") + "

"
        "Write a well-scoped engineering ticket with:
"
        "- Title (under 10 words)
"
        "- Description (2-3 sentences)
"
        "- Acceptance Criteria (3-5 bullet points)
"
        "- Open Questions (if any)"
    )
    response = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}]
    )
    return response.content[0].text

ticket = generate_ticket(
    "Users should be able to export reports as PDF",
    "Currently only CSV export is supported. Reports are generated server-side."
)
print(ticket)