Key Takeaways
- Product management is mostly synthesis work. A PM spends 60-70 percent of the week reading: support tickets, sales notes, call transcripts, Slack threads, GitHub issues, analytics reports. The output is a roadmap, a PRD, a stakeholder update. The reading is a tax. The synthesis is the value.
- The synthesis is exactly what an AI coworker is good at. Viktor reads the whole stream (Pylon, Granola, Gmail, Linear, GitHub, PostHog, Slack), groups themes, and produces the artifact. The PM reviews and decides. The reading hours collapse from 25 to 4 per week.
- The artifacts get better, not worse, when the synthesis is automated. Customer themes cited with the actual quotes. Feature requests counted, not estimated. Roadmap status pulled from real Linear states, not Friday memory. The PRD opens with a quote from the call where the user said exactly what they needed.
- The PM job becomes the job it was supposed to be. Talk to customers. Decide what to build next. Negotiate with engineering. Defend the cut list. The AI coworker handles the input collation and the output drafting; the PM owns the decisions.
- This works for PMs at every scale, from the solo PM at a startup running across five surfaces to the principal PM at an enterprise responsible for one product area with twelve squads underneath.
The short version
The Product Manager job has expanded faster than the time available to do it. A modern PM is expected to be on calls with customers, on calls with sales, on calls with engineering, in the analytics tool, in the support tool, in Linear, in Slack, in Notion, and producing PRDs, roadmaps, stakeholder updates, launch plans, and post-launch reviews. Nobody who has actually done this job believes it is one role.
The honest answer is that PMs are buffered by spending most of their time on the thinnest version of each task. They skim 40 customer quotes instead of reading 200. They write a PRD with five real customer quotes instead of fifty. They produce a stakeholder update from memory of the last week instead of the actual data. The work happens. The depth doesn't.
An AI coworker fixes this not by replacing the PM but by removing the synthesis tax. Viktor reads the whole input stream every week, groups what users are actually saying, summarizes what shipped, identifies what's stuck, and drafts the artifacts. The PM reviews, edits, decides, and spends the recovered hours on customer calls and trade-off conversations. That is the job. That is the work AI can't do for them.
What a PM's week actually looks like
Pick any PM at a B2B SaaS company between 50 and 500 people. The week looks roughly like this:
- 8 hours: customer calls and internal stakeholder calls
- 6 hours: reading support tickets, sales notes, user research transcripts
- 5 hours: writing PRDs, specs, technical briefs
- 4 hours: roadmap maintenance, Linear cleanup, status updates
- 3 hours: Slack triage, async questions, one-off requests
- 4 hours: actual decision and design work
- 10 hours: meetings that aren't customer calls (planning, retros, reviews, syncs)
That is a 40-hour budget. The PM is in week 60-65 because the reading expands to fit available time and then exceeds it.
Notice that reading and roadmap maintenance together are 10-11 hours. That is the bulk of the synthesis tax. That is where the AI coworker pays back.
The four artifacts a PM produces, and what AI does to each
1. The customer-feedback synthesis
Every PM is supposed to know what users are asking for. The honest answer is they know what 5-10 of the loudest users are asking for, plus whatever the AE who ran the last big deal said in Slack.
Here is what the AI coworker version looks like:
@Viktor every Monday at 09:00:
Pull the last 7 days of:
- Support tickets in Pylon (all open + last 7 days closed)
- Granola call transcripts tagged "customer call" in the last 7 days
- Slack messages in #customer-feedback, #feature-requests, #cs-internal
- Gmail threads with customer-domain senders, last 7 days
- HubSpot deal notes from AE-led calls, last 7 days
For each input, extract: who said it (role and company stage if known),
what they wanted (one sentence), what they were trying to do (one sentence),
and the verbatim quote (one paragraph max).
Group by theme. Themes are not predefined; cluster on what is actually said.
Rank themes by frequency AND by customer revenue weight (a $50k MRR customer
asking once counts more than a free user asking once).
Output a single Notion page titled "Customer Signal Brief, week of {{ date }}":
- Top 10 themes
- For each theme: count, MRR-weighted rank, 3 representative quotes with
attribution, and a 2-sentence summary
- A separate "newcomer themes" section: anything that didn't appear in
the last 4 weeks but appeared this week
Post a link in #pm with a one-paragraph executive summary.The first time this runs, the PM finds three themes they didn't know existed and one theme they thought was loud that actually isn't. The brief replaces the "I think users want X" instinct with the data.
2. The PRD
A PRD that opens with five generic bullet points about why-this-matters is a PRD nobody reads. A PRD that opens with three customer quotes from real calls plus a concrete usage stat is a PRD that ships.
Viktor can draft the customer-context section of every PRD because it has read all the calls and tickets. Hand it the feature name and the Linear epic ID:
@Viktor draft the customer-context and problem-statement section of the PRD
for {{ feature_name }}:
1. Search Granola transcripts in the last 90 days for any mention of this
feature, the underlying user goal, or related workarounds users described.
2. Search Pylon tickets in the last 180 days for the same.
3. Search Slack #customer-feedback and the customer-feedback Linear project
for related entries.
4. Identify the 5 strongest verbatim quotes (1-3 sentences each) that
capture the problem in users' own words. Attribute each quote (role,
company size, link to the source if possible).
5. Identify the workaround pattern: what are users currently doing instead?
6. Identify the upgrade or churn signal: did any deal stall or expand on this?
7. Output a 600-800 word section in markdown with these subsections:
- "Why this, why now" (one paragraph)
- "What users said, in their words" (5 quotes)
- "What users currently do instead" (one paragraph)
- "What we expect this to unlock" (one paragraph)
- "What we are NOT solving here" (3-5 bullets)
Save as a draft in Notion under the project page for {{ feature_name }}.
Post a link in the project's Slack channel for review.The PM still writes the design and engineering sections. They still own the trade-offs. But the customer-context section, the part that takes 4 hours of reading and the part that everyone skims when it's hand-waved, is now real and citable.
3. The roadmap update
The weekly roadmap update is a dread artifact. It exists because someone above the PM wants to know "what's shipping, what's stuck, what's at risk." The honest version takes 90 minutes to assemble each week. The dishonest version takes 15 and is full of "on track" lies.
@Viktor every Friday at 15:00 in #product-leadership:
For every Linear project tagged "roadmap-{{ current_quarter }}":
- Pull the project status, last update, and active issues.
- Look at the issue cycle history: how many issues moved this week?
How many slipped from "in progress" to "blocked"? How many opened
vs closed?
- Look at the GitHub PRs linked to issues in this project: how many
are open >7 days? How many merged this week?
- Look at the Slack channel for this project: any concerning thread?
Any unanswered question >48h?
Produce a one-line status per project:
- ON TRACK (issues closing at expected rate, no PR backup)
- AT RISK (issue rate slipping or PR backup forming, with the specific reason)
- BLOCKED (named blocker with evidence)
- SHIPPED (all issues done, post-launch metrics if available)
For each AT RISK or BLOCKED, include a proposed unblock action and the
specific person who would own it.
Post the table in Slack. Update the Notion roadmap page with the same data.The leadership conversation that follows is now about decisions, not status. That is a meeting worth having.
4. The stakeholder update
The cross-functional update (to sales, support, marketing, exec team) typically goes out monthly and is the one a PM most often misses. Same pattern, same payoff:
@Viktor on the last Friday of the month, in #stakeholder-update:
Produce a "Product Update, {{ month_name }} {{ year }}" digest:
1. Shipped: every Linear issue tagged "shipped-this-month" with a one-line
what-it-is and link to the Notion launch note if exists.
2. Shipping next: the top 5 features in flight, with rough ETA from Linear
project dates.
3. Listened: 3 customer themes that were loud this month (pull from the
weekly Customer Signal Briefs, aggregated).
4. Killed: anything explicitly de-prioritized, with the reason.
5. Numbers: 3 product metrics that moved (pull from PostHog or our analytics
warehouse: weekly active users, key feature adoption, time-to-value).
Format as Slack message with the link to a longer Notion version. Tag the
PM lead for review before posting.The first month this runs, the org realizes how much shipped that they didn't know about. Cross-functional alignment improves immediately.
The interview-debrief workflow
A PM who runs proper customer research is interviewing 5-10 users a week. The synthesis of those conversations is its own art. Viktor accelerates the mechanical part:
@Viktor when a Granola call is tagged "user research", produce an interview
debrief:
1. Pull the full transcript.
2. Identify the user's role, company, and product context (free-text from
the start of the call).
3. Extract:
- Top 3 jobs they were trying to do
- Top 3 frustrations or workarounds they described
- Any specific feature requests, with verbatim quote
- Any answer they gave to a discovery question that contradicted our
current assumption (cross-reference with the PRD's "what we believe"
section if linked)
4. Output a 400-word debrief in the project's Notion folder.
5. Add the user's role and company to the existing "research participants"
tracker in Notion so we don't accidentally re-invite them too soon.
6. Cross-link this debrief to any related Linear issue automatically.Five interviews a week, 30 minutes of debrief work each, becomes 10 minutes of reviewing the auto-debriefs. Two hours saved per week per PM doing real research. Two hours that go back to the work that matters.
What does NOT change
The AI coworker is not the strategist. There are parts of the job it does not touch:
- Deciding what to build next. That is the PM call, informed by the synthesized data.
- Negotiating with engineering on scope. That is the PM owning the trade-off.
- Talking to customers. The interviews still happen. The post-call work shrinks; the call itself is unchanged.
- Defending the cut list. Why feature X is not on the roadmap is a conversation that requires conviction. AI can supply the evidence; conviction is human.
- Killing a project. The data may say "low signal, low impact, kill," but the political work to actually shut it down is the PM's.
A PM who tries to outsource the decisions to the AI coworker will produce a worse roadmap. A PM who outsources the synthesis will produce a better one. The line is real.
What this looks like in three companies
A 30-person seed-stage startup with one PM. The single PM is doing PM, design, sometimes engineering management. The reading volume is low (5-10 customer calls a week, 50 tickets) but the synthesis still eats their week. Viktor saves 8-10 hours by automating the four artifacts above. Those hours go to customer interviews and engineering pairing. The roadmap quality jumps in week two.
A 200-person Series B with five PMs and a head of product. The Customer Signal Brief becomes the shared input across all five PM areas. The PRD-context cron pre-loads each new feature with citations. The roadmap update for leadership takes 15 minutes instead of 90. Cross-functional alignment improves because the stakeholder digest actually goes out on time.
A 1,000-person Series D with 30 PMs across multiple product lines. The Customer Signal Brief becomes a per-product-area digest, with a meta-brief rolling up themes across products. Customer research debriefs are auto-tagged and aggregated quarterly. The PMM and design teams subscribe to the same feed. The principal PM running a product area can finally see the whole input surface without delegating to a researcher.
Safety and approval
Product Management artifacts are usually internal, but some leak: a PRD shared with an integration partner, a stakeholder update shared with a board observer. Treat the AI coworker output the same way you would a junior PM's draft.
Hard rules:
- Notion writes are auto-approve, but tagged. Drafts go to a "Drafts" folder, not the canonical project page. The PM moves them after review.
- Slack posts to internal channels are auto-approve. No customer-facing summaries are auto-posted anywhere external.
- No CRM or Linear field changes auto-applied. If Viktor identifies a Linear issue is mis-categorized, it proposes the change. Engineering and PM confirm.
- Customer quotes are pulled with attribution. Any artifact that quotes a customer cites the source (call, ticket, Slack message) so the PM can verify before sharing externally. No paraphrased quotes presented as direct.
- Internal-only by default. The PRD-context drafts are tagged INTERNAL until the PM moves them out. This prevents the Air Canada class of failure where AI output reaches a customer surface without a human checking.
Review-first. Always.
Frequently Asked Questions
Will the synthesis miss the things that matter most because they are quietest?
Sometimes. The quiet signal is the one a senior researcher catches and a frequency count misses. The defense is to combine the AI brief with regular qualitative reads. Viktor surfaces the loud and the new. The PM still does occasional deep reads to catch the quiet.
How does Viktor handle conflicting signals (one user wants A, another wants B)?
The brief shows both, with their MRR weight and frequency. The PM does the conflict-resolution thinking. AI cannot pick the right answer when users disagree; it can only show the disagreement clearly.
Does this work if our customer research is mostly in Notion docs from interviews, not call transcripts?
Yes. Viktor reads Notion. The pattern is the same. Tag the docs consistently and the synthesis cron picks them up.
Can the PRD draft replace the PM writing?
No. The PRD draft replaces the synthesis section, which is the part that's mostly assembling evidence. The design, scope, dependencies, and trade-off sections are PM work. The draft saves 4 hours; the PM still does the 4 hours that matter.
What about features where there is no customer signal yet (true innovation)?
The Customer Signal Brief is one input among many. Some features come from technical opportunity, competitive pressure, or strategic bet. The brief documents the signal that exists; the PM owns the cases where the signal doesn't.
Will engineers trust a PRD where part of the writing is AI-drafted?
Engineers care about whether the spec is right and the trade-offs are honest. The customer-context section being well-cited is a quality improvement, not a quality concern. What matters to engineering is the design and constraints sections, which are still the PM's.
What's the first week setup?
One day to wire up Pylon, Granola, Gmail, Slack, Linear, and PostHog through OAuth. Two days to write the four cron prompts (we share starter templates). Two days of reviewing the first outputs and tuning thresholds. By Friday, the four artifacts are live. The team starts feeling the time gain in week three.
