CHAPTERS
- 1:30 – 2:37
Why AI-native teams need a “company operating system” (and what it replaces)
Aakash sets the stakes—PMs are overwhelmed by AI tools but not seeing real productivity gains—then introduces Mikhail’s goal: building an AI-native operating system that changes how product work gets done. The conversation frames the episode around tangible leverage (2–3× productivity), not tool hype.
- •PMs are adopting many AI tools but often feel no net productivity gain
- •Mikhail’s OLX setup is positioned as an end-to-end “operating system,” not a single chatbot
- •Focus of the episode: how to build, measure, and operationalize AI in product orgs
- •Promise: AI can validate, ship, and review work across the product lifecycle
- 2:37 – 3:38
Digitizing organizational knowledge to prevent context leakage
Mikhail explains the core purpose of AI-native teams: automate and retain domain context so knowledge doesn’t walk out the door with individuals. The more the AI understands the organization’s context, the more autonomy it can be safely given.
- •Old paradigm: domain experts become knowledge bottlenecks and create leakage risk
- •Goal: a centralized store of business/customer/product/technical context
- •Higher context coverage enables delegation of higher-level tasks to AI
- •AI autonomy increases as organizational knowledge becomes more complete
- 3:38 – 5:39
The OLX knowledge graph: layers, signals, and what “54% coverage” means
Mikhail demos a company-wide knowledge graph built over five months, spanning contacts, projects, customer interactions, and funnel metrics. He introduces “product context coverage” as a KPI and explains how it reflects the AI’s ability to act like a junior-to-mid PM today—and potentially strategy support later.
- •Knowledge graph formed quickly (5 months) and already richly interconnected
- •Tracks org interactions (who talks to whom), projects, customers, and metrics
- •Product context coverage KPI: currently ~54% understanding of industry/business/customers
- •At higher coverage (70–90%), AI may contribute to strategy-level decisions
- 5:39 – 8:00
Using the graph to detect silos and evaluate team discovery strength
Beyond visualization, Mikhail uses graph connectivity as a management tool—assessing teams’ context depth and cross-team overlap. Sparse connections can indicate discovery weakness, siloing, or poor stakeholder involvement.
- •Three layers: product nodes, contacts/reflections, and team clusters/divisions
- •Ability to drill down to team/PM level to assess “knowledge of context”
- •Low overlap between horizontal and vertical teams flags silos
- •Graph becomes a proxy for stakeholder management and discovery quality
- 8:00 – 12:36
How the context-coverage metric is measured (and why it works)
Aakash presses on measurement: Mikhail describes a structured prompt that asks the AI to estimate what it knows across industry, business model/PNL, and customer segments. He notes the metric improves as PMs load real artifacts (transcripts, research, RFDs) into memory.
- •Coverage is computed via a repeatable prompt with explicit definition of “context”
- •Breakdown includes verticals, business model/PNL drivers, and customer/cohort knowledge
- •Metric trends upward as teams feed transcripts, research, and RFDs into memory
- •Not a perfect truth source—orgs should tailor a context metric to their needs
- 12:36 – 15:18
The “agentic CPO”: shifting from process scaffolding to AI operating systems
Mikhail argues output is now cheap; leadership must optimize quality and token consumption instead. The CPO’s job evolves from procedural scaffolding (cadences, reviews) to owning the agent architecture, rituals, and training that make AI a daily collaborator and decision-maker.
- •Output cost drops; quality and token budget become central constraints
- •Old CPO playbook: vision, hiring principles, cadences, reviews, procedural scaffolding
- •New CPO playbook: build/own agentic scaffolding so AI can collaborate and decide
- •CPO must drive rituals/processes that keep teams continuously interacting with agents
- 15:18 – 16:56
Where PM time is saved: automating rituals so PMs can focus on discovery
Mikhail estimates ~50% of PM time historically goes to repetitive processes (reports, demos, stakeholder updates). Delegating that work to AI frees PMs to focus on customer discovery, letting one PM cover the workload of two in many contexts.
- •PM time sink: reporting, stakeholder workflows, demos, and recurring rituals
- •These tasks often require low cognitive effort and are AI-automatable
- •Result: PMs reallocate time to high-leverage discovery and value finding
- •Net effect: 1 PM can often do the work of ~2 PMs (in suitable domains)
- 16:56 – 18:51
Slack agent in action: status reporting, workspace integration, and rule libraries
Mikhail demonstrates how stakeholders query project status and receive structured updates in Slack (or other formats). He highlights deep integration with Google Workspace and the importance of a large rule/imperative library to reduce hallucinations and enforce factual outputs.
- •Status reporting via Slack with flexible output formats (Doc/Confluence/etc.)
- •Deep integrations: Gmail triage, calendar management, and other workspace tools
- •Mikhail offloads email reading and calendar coordination to the agent
- •~700 lines of rules/imperatives to keep outputs clean and factual
- 18:51 – 21:17
Agent as gatekeeper: handling stakeholder feature requests before PM escalation
Instead of stakeholders going straight to PMs with unframed requests, the agent collects clarifying info, checks fit with priorities, and decides whether to reject politely or escalate into the backlog. The agent routes work to the correct domain owner because it has org structure mapped.
- •Stakeholders are trained to interact with the agent before contacting PMs
- •Agent asks clarifying questions and enforces problem framing and rationale
- •Outcomes: reject non-valuable ideas or add to backlog and escalate to the right PM
- •Domain routing works because org ownership and structure are encoded in the system
- 21:17 – 22:22
Why the CPO should own the agent (not AI Ops): iteration speed and business impact
Aakash asks whether ownership should sit with an AI Ops role; Mikhail warns it slows iteration and dilutes accountability. He argues the CPO must own it to iterate daily based on feedback and because the agent directly shapes decisions and business outcomes.
- •Ownership drives rapid feedback-to-deployment cycles
- •CPO has the incentives (‘skin in the game’) to optimize for outcomes
- •Delegating to engineering/other roles risks slower iteration and less impact
- •Agent influences time savings and decision-making across the organization
- 22:22 – 25:25
Under the hood: architecture choices (OpenClau + Hermes) and memory stack design
Mikhail opens the technical setup: he blends OpenClau (scaffolding/support) with Hermes (auto skill generation) for measurable accuracy gains. He also explains the three memory layers—knowledge graph, vector DB, and raw transcript logs—forming a persistent, improving knowledge base.
- •Blend of OpenClau for scaffolding and Hermes for automated skill generation
- •Three memory layers: knowledge graph + vector database + stored conversation transcripts
- •Vectorization enables fuzzy retrieval when exact keyword match fails
- •Daily stored MD transcript files include meetings, agent chats, and reflections
- 25:25 – 31:41
Counterintuitive lesson: summarization hurts retrieval—store raw transcripts instead
Aakash expects transcripts must be cleaned and summarized for usefulness, but Mikhail shares tests showing summarization reduces recall significantly. Raw storage preserves nuance and avoids forcing conversations into a lossy template, and storage cost is negligible.
- •Summaries lose granular details and nuance critical for accurate retrieval
- •Templates imposed by summarization can distort what matters
- •Observed ~20–25% worse recall with summarization vs raw transcripts
- •Decision: store everything raw (when permitted) because it’s cheap and higher fidelity
- 31:41 – 37:46
Imperatives, tool integrations, and how Mikhail edits the system on the go
Mikhail explains the importance of imperative/rule files to correct LLM biases (plausible-sounding output, contradictions, ‘fake helpful’ responses). He also covers tool plugins (Google, Atlassian, automations like review digests) and how he ships changes via Claude App + GitHub, using multiple IDE agents when needed.
- •Imperatives reduce hallucinations, enforce thinking, and prevent ‘fake helpful’ answers
- •Claude MD vs Sol MD: priority system prompts (short high-priority + longer rule set)
- •Tools integrated: Google Workspace, Atlassian, automations (e.g., app review digests)
- •Mikhail uses Claude App for fast edits, commits immediately to GitHub; two IDEs allow parallel agents
- 37:46 – 41:43
Hermes auto-skills + evaluation: measuring recall improvements and building evals
Hermes creates skills based on frequent tasks and even decides when a skill should exist. Mikhail describes a lightweight evaluation approach: generate common question sets for key areas, compare control vs treatment (skills on/off), and track accuracy—showing +31% improvement.
- •Hermes auto-generates skills from recurring requests and identifies opportunities to offload work
- •Example skills: hiring evaluation, immigration case building, and more
- •Recall eval method: 5 core topics × ~10 questions each; compare skill vs no-skill outputs
- •Result: +31% accuracy improvement; once methodology exists, evals can be delegated to the system
- 41:43 – 57:18
High-leverage use cases: board-deck critique, permissions, prototypes, design systems, and hiring automation
Mikhail shares advanced applications: a ‘board skill’ that encodes directors’ mental models to stress-test strategy decks; strict access controls and opt-in transcript privacy; agentic prototyping and model routing based on risk/cost; auto-generated design systems with human review; and recruiting automation across LinkedIn/CRM/interview transcripts.
- •‘Board skill’ abstracts board member principles to give brutal feedback on strategy decks
- •Access control by role + opt-in transcript policies protect sensitive/private information
- •Agent can prototype features and route to models by complexity and blast radius (token optimization)
- •Design system can be generated from prompt and updated via queued requests + designer review
- •Recruiting: LinkedIn sourcing, CRM actions, transcript-based interview analysis; automates ~70–75% and improves candidate rejection quality
- 57:18 – 1:06:16
The future of PM and org design: smaller teams, blurred roles, and hiring AI-native PMs
Mikhail argues PM isn’t going away; AI removes compliance theater and returns PM focus to value discovery and customer understanding. Teams will get leaner, role boundaries between PM/EM/design blur, staffing differs by complexity/blast radius, and hiring now includes explicit testing of AI craft and automation maturity.
- •PM thrives as AI removes operational overhead; humans remain essential for customer discovery
- •Expect smaller, faster teams and changing PM:engineer ratios
- •Roles blur: PMs, engineers, and designers all orchestrate quality and token budgets
- •Staffing: high-risk/high-complexity areas still need dedicated owners; other domains can scale without headcount
- •Hiring: fundamentals (problem-solving/systematic thinking) + AI craft (what they’ve automated, tool/memory/scaffolding/evals decisions)
