Product
Product management with an AI worker on the roster
Five jobs a product team can hand to an AI teammate, and the ones it should never hand over.
What the worker does
A product team in Polaris hires an AI worker for the parts of the job that recur: roadmap drift, request triage, interview synthesis, release notes and competitor tracking. The worker reads Linear, Notion, Slack, Google Drive and the open web, then posts what it found as a comment on the task with files attached. Prioritisation calls, customer conversations and the decision to cut scope stay with people.
- Jobs covered
- 5
- Usual connections
- Linear, Notion, Slack
- Still yours
- What ships
The week a product manager actually has
The roadmap doc was accurate on the day it was written. Since then two initiatives slipped, one lost its owner when someone changed teams, and the tracker has the real dates while the doc has the ones you showed the board.
Meanwhile there are sixty feature requests scattered across Slack threads, support tickets and sales calls, twelve interview recordings nobody has read, a release that shipped without notes, and a competitor who quietly changed their pricing page. None of this is hard. All of it is assembly, and assembly is what eats the week that was supposed to go on the decision.
The five jobs
Each one is a page. Each page names the brief, the connections and what comes back.
Roadmap planning
A weekly diff between what the roadmap document claims and what the tracker actually says, with the initiatives that have no owner listed separately.
Feature prioritisation
Every open request clustered by theme, counted by how many distinct accounts asked, with the source link kept against each one.
User research synthesis
Interview transcripts read end to end and turned into themes with verbatim quotes, participant counts, and a flag where the evidence is thin.
Release notes
Merged pull requests since the last tag, grouped into user-visible changes and internal work, with a question list for the ones whose descriptions say nothing.
Competitive tracking
A weekly read of named competitors' public pricing and changelog pages, reported as a diff against last week rather than a fresh summary.
Brief, connections, delivery
What you write in the worker's SKILL.md, what you authorise it to reach, and what lands on the task.
| Job | The brief | Connections | What arrives |
|---|---|---|---|
| Roadmap planning | Compare the roadmap doc to tracker state every Monday | Linear, Notion, Slack | A comment listing moved dates and unowned initiatives |
| Feature prioritisation | Cluster open requests, count distinct askers | Slack, Linear, HubSpot | A ranked table with source links per cluster |
| Research synthesis | Read the transcripts in this folder, theme them | Google Drive, Notion | A themes document attached to the task |
| Release notes | Draft notes from merged PRs since the last tag | GitHub, Linear, Notion | A draft plus a list of PRs it could not interpret |
| Competitive tracking | Diff these public pages against last week | Web search, Notion, Slack | Only what changed, with dates and URLs |
The split that works
Product judgement does not survive being handed to a machine. Assembly does.
The product manager keeps
- Talking to customers
- Deciding what gets cut
- The trade-off argument with engineering
- Saying no to the loudest request
- Owning the outcome when it was the wrong call
The AI worker takes
- Reconciling the doc against the tracker
- Counting who asked for what, and when
- Reading twelve transcripts nobody has time for
- Turning merged pull requests into a notes draft
- Watching public competitor pages every week
Putting a product worker on the roster
About a minute of chat, then the part that matters: writing down how your team works.
- 1
Say what is falling through
Describe the gap to the Chief of Staff in chat. It runs a short interview: a name, the role, what the worker should be great at, which tools it needs. Answers are one click each.
- 2
Edit the SKILL.md
Capabilities land as a readable skill file. This is where you write the rules that make the output yours: what counts as a real request, which competitors matter, how you like release notes grouped.
- 3
Authorise the connections
Linear and Notion for most product work, Slack when the requests live in threads, Google Drive when the transcripts do. Credentials are verified once and stored server-side.
- 4
Assign the first task
Give it acceptance criteria the way you would give a contractor a definition of done. A cloud machine claims the job and starts working, whether or not your laptop is open.
- 5
Close it yourself
Read the delivery comment, keep what is right, rate it. The rating and your comments are what the worker's next run is briefed against.
The five product use cases
Your roadmap document and your tracker disagree
A weekly diff between what the roadmap claims and what the tracker actually says.
Sixty requests, and no idea how many people asked
Clustered requests with a real count of who asked, so the argument is about value rather than recall.
Twelve interviews recorded, two of them read
Themes with participant counts and verbatim quotes, plus a flag wherever the evidence is thin.
You shipped twenty-three things and announced four
A draft built from what actually merged, plus a list of the changes nobody described.
A competitor changed their pricing and you found out in a sales call
A weekly diff of public competitor pages, reporting only what changed since last time.
Questions people ask
+Can an AI worker decide what goes on the roadmap?
It should not, and Polaris does not let it try. A worker delivers findings as a comment and ticks the acceptance criteria it was given, but the task stays open until a person closes it. Roadmap decisions depend on context that never makes it into a tracker.
+Does this replace Linear or Jira for a product team?
It can, because Polaris has workstreams, lanes, a board and a list view over the same data. It does not have to. Many teams keep their tracker and give the worker the Linear connection so it reads issue state without anyone changing tools.
+How does a worker know what our team means by a feature request?
Because you write it down in the SKILL.md file. A rule like discount asks from a sales call do not count as product requests is one line, and it changes every subsequent run. The skill file is plain text you can read and edit at any time.
+What if the worker gets a synthesis wrong?
You reject the delivery and say why in a comment. Nothing was published, because the worker's output arrives as a comment on the task rather than as a change to a document. The rating and the correction inform how the next run is briefed.
Related
What an AI worker actually does, department by department
Twelve functions, sixty recurring jobs, and the exact tool connection each one needs.
The engineering work that is not writing code
Five jobs that sit between an engineer and the code, and what an AI teammate does with each.
Design work an AI teammate can take, and the part it cannot
Five jobs around the work, none of them the work itself. Taste stays where it belongs.
Hire an AI competitive analyst
Assign it every Monday and you get a written record of what your market did last week, with a URL behind every line of it.
Hire an AI project coordinator
The unglamorous half of running projects, done every week without anyone having to be the person who nags.
Connect Linear to Polaris
A Linear API key carries one person's visibility, so the account you make it on decides what every worker can see.
Connect Notion to Polaris
Notion decides what Polaris can see, page by page, because an internal integration only reaches what you explicitly share with it.
Polaris for product teams
Look at a product manager's calendar and subtract the meetings. What is left is mostly reformatting.