This is taking longer than expected.

Try againBrowse the library
AI Blocks

All AI specialists

Hire an AI product manager

Give it the idea or request, and who asked for it. You get a problem statement with the evidence behind it and the gaps in that evidence.

What you give

  • The idea or request, and who asked for it
  • Who the users are and what they struggle with now
  • Your goals for the next quarter, such as a number you want to move

What you get

  • An options table with a build, test small, defer or stop recommendation and how sure it is
  • A list of what you are not building and when to revisit it
  • Open questions with an owner and a date for each
  • A suggested next step, such as which user to interview or which spec to write next

An example

A stakeholder says "we need feature X" and you want to know if it is the right thing to build.

You ask: “Give it the idea or request, and who asked for it. Use the material I attach and ask for anything essential that is missing.”

You get back:

  • Problem statement. Who has the problem, how often, what it costs, and the evidence and gaps behind it.
  • Options and recommendation. Build, smaller version, buy, defer or stop, with one call, its confidence and what would change it.
  • PRD, roadmap or launch plan. The one you chose, in a layout your team can share and edit.

An example, not your task.

Hire this specialist

It is free and needs no account. Download the pack, give it to your AI and tell it the job. Your AI asks for anything it is missing, then does the work and checks it.

Download the specialist

Related specialists

Skills and workflows for this job: Build a product people want

Details

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

  • A problem statement with the evidence behind it and the gaps in that evidence
  • An options table with a build, test small, defer or stop recommendation and how sure it is
  • The document you chose, in a ready-to-share layout
  • A list of what you are not building and when to revisit it
  • Open questions with an owner and a date for each
  • A suggested next step, such as which user to interview or which spec to write next

How it does the job well

  • Do not give engineering estimates, legal opinions or financial forecasts as facts. Mark them as needing the engineers, a lawyer or a finance lead.
  • Lead with the problem, not the solution. Never accept a feature request at face value. Stakeholders bring solutions — your job is to find the underlying user pain or business goal before evaluating any approach.
  • Write the press release before the PRD. If you can't articulate why users will care about this in one clear paragraph, you're not ready to write requirements or start design.
  • No roadmap item without an owner, a success metric, and a time horizon. "We should do this someday" is not a roadmap item. Vague roadmaps produce vague outcomes.
  • Say no — clearly, respectfully, and often. Protecting team focus is the most underrated PM skill. Every yes is a no to something else; make that trade-off explicit.
  • Start from the user problem and the evidence for it, then the solution.
  • Write decisions down with the reason and the options you rejected.

Mistakes it avoids

  • Treating opinions or one loud request as proven demand.
  • Specs that skip edge cases, error states or dependencies.
  • Roadmaps with dates but no owners or confidence levels.

What a good result looks like

An example, not your task: A stakeholder says "we need feature X" and you want to know if it is the right thing to build.

  • Problem statement. Who has the problem, how often, what it costs, and the evidence and gaps behind it.
  • Options and recommendation. Build, smaller version, buy, defer or stop, with one call, its confidence and what would change it.
  • PRD, roadmap or launch plan. The one you chose, in a layout your team can share and edit.
  • Not building list. Requests set aside, with the reason and the condition to revisit them.
  • Open questions. Each question that must be answered before work starts, with an owner and a date.
  • Next step. One action to take next, such as a user interview or a spec review.

How the work is checked

  • Every requirement can be tested.
  • Assumptions and risks are listed with how each will be checked.
  • Dependencies and owners are named.
  • States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

Capabilities

  • Find the real problem. It asks why up to three times, separates the user's pain from the proposed fix, and states who has it and how often.
  • Check the evidence. It lists what you have, such as interviews, data and tickets, and marks every gap instead of filling it.
  • Compare the options. It sets out build, a smaller version, buy, wait and stop, with pros, cons and effort. Scores such as RICE use only numbers you give or mark as assumed.
  • Make a recommendation. It gives one call, how confident it is, and what would change its mind.
  • Write the document. It writes your chosen format. The PRD has the problem, goals and measures, non-goals, users, scope, risks, open questions and a launch plan.
  • Say what you are not building. It lists requests set aside with the reason and the condition to revisit, so the same request does not return unanswered.

How the role works

  1. Checks your task, context and available tools.
  2. Picks the methods needed and prepares a work plan.
  3. Carries out supported tasks, with each method's limits and review gates.
  4. Checks the real deliverables and corrects supported faults.
  5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id product-manager only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/product-manager/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

  • The idea or request, and who asked for it
  • Who the users are and what they struggle with now
  • Your goals for the next quarter, such as a number you want to move
  • What evidence you have, such as interview notes, support tickets, usage numbers or competitor notes
  • Which document you want, such as an assessment, a requirements doc, a roadmap or a launch plan
  • Team size and deadlines, and anything you cannot change (optional)

Helpful context (optional)

  • Five or more user interview notes, or the nearest real evidence you have.
  • The numbers behind your goal, such as sign-ups or support tickets per week.
  • A list of requests from sales and customers that you have not yet answered.

Tools and access

  • Claude, ChatGPT or Gemini with file upload: You can attach interview notes, a ticket export or a spreadsheet of usage numbers.
  • Your team's document tool, such as Notion or Google Docs: Paste the PRD or roadmap there so the team can comment and fill in the gaps.

Functions and deliverables

  • Product manager: Turn a feature idea into a product plan. Get a problem statement, a build or defer recommendation, a product requirements doc and a roadmap.
    • A problem statement with the evidence behind it and the gaps in that evidence
    • An options table with a build, test small, defer or stop recommendation and how sure it is
    • The document you chose, in a ready-to-share layout
    • A list of what you are not building and when to revisit it
    • Open questions with an owner and a date for each
    • A suggested next step, such as which user to interview or which spec to write next
    Source: Michael Sitarzewski and Agency Agents contributors.
  • Feature request priority planner: Share feature requests and product priorities. Get a build, defer or decline recommendation, with a reply for each.
    • A repeat count for each request
    • A cost list for each yes
    • A ruling of yes, later or no with one reason
    • A short, kind reply with no promised date
  • Feature requirements writer: Turn feature plans and code context into a spec that sets out what to build and test.
    • A spec with problem, solution and user stories
    • Implementation decisions
    • A testing plan with chosen test points
    • The spec posted to your tracker with a ready label
    Source: Matt Pocock.
  • Product requirements writer: Describe a feature or product. You get a short product requirements document (PRD) with goal, audience, value and release plan.
    • A lean eight-section PRD
    • Value propositions in jobs-to-be-done form
    • An objective and release plan
    • A list of open questions that block decisions
    Source: Pawel Huryn.
  • Product context file writer: Share product facts, audience and positioning. Get a reviewed context file that other marketing skills can reference.
    • A product marketing context file
    • A summary of what the file already holds
    • A change log of updates
    • Gaps you still need to fill
    Source: Corey Haines.

Tasks you can use it for

  • A stakeholder says "we need feature X" and you want to know if it is the right thing to build.
  • You have too many ideas and need to choose, say no to some and explain why.
  • Your engineers ask for a clear spec before they start.
  • You are about to launch and need a plan that covers support, marketing and rollback.

Limits to check before starting

  • You only want a short requirements document from a few lines. Use the Product requirements writer.
  • You need to order tickets for the next sprint. Use the Sprint priority planner.
  • You have raw customer feedback to sort first. Use the Product feedback analyst, then bring its themes here.
  • You need engineering estimates, legal review or financial forecasts. Ask the engineers, a lawyer or your finance lead.
  • Your request is still vague. Use the Requirements interviewer to sharpen it before you start.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

  • Download the pack from this page and add it to your AI as a skill. Or paste SKILL.md into a new chat, then paste references/source-agent.md after it.
  • Write a short brief. Include the idea, the users, your goal, the evidence you have and which document you want.
  • Your AI asks once for anything missing. Anything still unknown is marked as an assumption you can change.
  • Read the problem statement and the evidence gaps first. If the evidence is thin, collect more before you act on the recommendation.
  • Share the document with your team. Replace every ASSUMED and MISSING item with real numbers or names.
  • Take the next step it names, then bring the new facts back and ask for a revised plan.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/product-manager for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.