A product team,
over your team's own knowledge.
A researcher scans your CRM, roadmap, and support signal. A PRD writer drafts against your team's templates. A reviewer checks against your product principles. A stakeholder communicator drafts the follow-ups. Working from your Notion, your Linear, your CRM — with the same rigour a senior PM would apply.
The CEO asks for a competitive teardown and a launch plan.
A CEO opens the chat and says: “The market's making noise about competitor X. What's actually differentiated in their new release, and what does our launch plan look like for our equivalent?” The manager plans: (1) research competitor's actual capabilities from public sources + our win/loss data; (2) synthesize a positioning brief; (3) draft the PRD skeleton for our equivalent; (4) reviewer checks against product principles and the roadmap; (5) communicator drafts the internal FAQ and the stakeholder update. Each specialist works over its own retrieval scope — the researcher over public sources and the CRM, the PRD writer over Linear and past PRDs, the reviewer over the product principles doc. The CEO watches the plan, redirects once (“skip the internal FAQ, I'll write that”), and gets a research memo + PRD skeleton + stakeholder update in the same conversation.
Who’s on it.
One published agent — the one your users talk to. The rest are internal team members with their own skills, retrieval scopes, and models.
The only agent stakeholders talk to. Decomposes ambiguous requests, plans the work, delegates to specialists, resolves conflicts, does the final synthesis.
Gathers signal from public sources, your CRM (win/loss, deal notes), support tickets, and past customer interviews. Cites every source. Follows the team's research standards.
Drafts PRDs against the team's PRD template. Retrieves relevant past PRDs and roadmap docs for context. Follows your voice, your section structure, your acceptance-criteria pattern.
Checks drafts against the team's product principles doc. Flags conflicts with the roadmap. Verifies acceptance criteria are testable. Cross-checks with support signal for known edge cases.
Drafts internal FAQ, changelog, launch email, sales enablement one-pager. Adapts tone per audience (eng, sales, exec). Cites the PRD.
Plan → Delegate → Review → Return.
Plan.
Manager decomposes the request in chat: research → PRD skeleton → review → stakeholder communication. CEO can redirect.
Delegate to research.
Researcher pulls competitor signal from public sources + win/loss data from the CRM + support tickets mentioning the topic. Returns a memo with citations.
Delegate to the PRD writer.
PRD writer retrieves relevant past PRDs, drafts the skeleton against the team's template, includes acceptance criteria. Returns a draft.
Delegate to the reviewer.
Reviewer walks the product principles doc, flags conflicts with the current roadmap, verifies criteria are testable. Returns a review memo.
Delegate to the communicator (optional).
Drafts internal FAQ, launch email, sales enablement one-pager. Adapts tone per audience.
Return.
Manager synthesizes: research memo + PRD draft + stakeholder pack. CEO reviews in the same conversation and approves. Save-to-Linear action fires; PRD lands in the project.
The team learns your product voice as you correct it.
When the CEO said “skip the internal FAQ, I'll write that” on the last conversation, the system emitted a skill_refinement against the Product Manager Skill: “only draft internal FAQs when explicitly requested; default plan skips this step.” When a designer noted “we should always include a design review checkpoint before writing acceptance criteria,” the refinement went against the PRD Writing Skill. Once a week, the head of product reviews the queue. Approved refinements bump the skill's version and become the team's standing PM voice on the next request.
Works over the tools you already run.
Data mapped from where it already lives. Nothing uploaded, nothing migrated. Common connections for this team:
Want to see this team on your workflow?
30-minute demo. Bring one specialist task your team keeps re-doing. We’ll show how the team topology fits.