Aakash GuptaHow to Build an AI-Native Product Team in 2026 | Charles Zedlewski | Product Growth
CHAPTERS
- 0:00 – 3:36
From individual AI output to collective team throughput (and avoiding “context window slop”)
Charles explains why maximizing individual productivity with AI can backfire—creating lots of low-signal artifacts that burden coworkers. The team’s goal became collective productivity: centralize reusable context and practices so work compounds instead of fragmenting.
- •AI makes it easy to generate unlimited code/content, but that doesn’t guarantee startup progress
- •The new failure mode: flooding teammates with low-quality, high-volume artifacts
- •Shift from personal optimization to systems that improve team coordination and decision-making
- •Early decisions: what to centralize vs. what to leave to individual workflows
- 3:36 – 6:08
The Together Product Repository: a shared, model-readable source of truth
Nicolina introduces the “Together product repository,” a shared repo of Markdown/YAML that stores cross-team context and reusable skills. It’s designed to help PMs reuse each other’s thinking and reduce duplicated discovery work.
- •Repo is mostly Markdown/YAML: easy for humans and AI harnesses to consume
- •Holds product context (by product area) plus outputs from strategy/planning sessions
- •Enables “legwork reuse”: PMs can build informed proposals using existing docs from other areas
- •Clear boundary: code-specific details should live in the relevant code repo, not the product repo
- 6:08 – 9:03
Reusable skills that automate recurring PM work (status updates, competitive/news reports)
Nicolina walks through practical team skills: sprint status rollups and daily news/competitor briefs. The workflow is ‘generate from sources → lightly edit → publish,’ turning formerly manual synthesis into a quick review step.
- •Sprint update skill pulls from repos/projects to draft shipped/ongoing/next status
- •Cuts status-writing time from 10–30 minutes to a few minutes
- •News-report skill aggregates competitor/model-lab updates from chosen sources
- •Outputs are editable drafts—humans remain responsible for correctness and nuance
- 9:03 – 10:47
Keeping shared context fresh: ownership, PRs, and “update when it hurts”
The team treats context like code: each area has an owner, but anyone can submit PRs when they find gaps. Strategy shifts from leadership provide a natural trigger for updating canonical direction docs.
- •Area owners maintain their sections (e.g., sandboxes, customer intelligence)
- •Leadership direction-setting documents become clean “update triggers”
- •Updates are handled via normal PR workflows; contributors fix missing context when discovered
- •Avoids stale knowledge bases by tying maintenance to real usage and pain points
- 10:47 – 12:03
Team skills vs. personal skills: where experiments live and when they graduate
Nicolina describes a pragmatic rule: keep skills close to the work they reference; otherwise use personal repos or the shared repo. Skills often start as experiments in branches and get promoted to main only after repeated use.
- •Co-locate skills with the repo when they depend on that repo’s code/architecture
- •Otherwise use personal repos or the shared skills repo
- •Prototype niche skills in branches; promote to main after they prove repeatable
- •Prevents premature standardization while still enabling reuse
- 12:03 – 13:22
Harnesses and models: choosing the right tool for the task in a multi-model world
The team relies on a harness layer (e.g., OpenCode, others) that runs against shared context/skills while letting individuals choose models. They’re moving from Claude toward their own/open models for cost and control, and encourage model-task pairing experimentation.
- •Repository (context/skills) is separate from the harness that executes them
- •Multiple harness options; individuals pick what fits their workflow
- •Model selection is task-dependent (coding vs analysis vs prototyping)
- •Cost pressures accelerate adoption of in-house/open models
- 13:22 – 15:38
Ad break: tracing + eval loop for agents (Arize example)
Aakash describes a common agent failure mode: things work locally but hallucinate in the wild because nothing is being evaluated. He demonstrates an instrumentation → tracing → eval → fix loop using Arize to catch and reduce errors.
- •Without evals, agent shipping is ‘flying blind’ even if prompts/tools look fine
- •Tracing exposes step-by-step tool calls and decisions
- •Evals identify systematic failure rates and validate fixes
- •Closed loop: trace → evaluate → fix → rerun automatically
- 15:38 – 20:00
Live feature research: one query across Pylon, Linear, Notion—and the codebase
Pavneet demonstrates a shared feature-research skill that aggregates evidence from support tickets (Pylon), execution tracking (Linear), and internal docs (Notion). It quickly quantifies demand, surfaces verbatims, and prevents duplicated work by discovering partial prior implementations.
- •Research skill answers: how big is the problem, who’s asking, and what they said
- •Finds related Linear work and flags partial/broken implementations to build upon
- •Connects into a local OS directory with access to internal GitHub repos
- •Compresses half-day research into minutes while preserving links to sources
- 20:00 – 27:37
The PRD writer that interviews you: turn-by-turn decision forcing + critique
Pavneet shows a PRD-writing skill that conducts an interview, challenges assumptions, and uses a question bank to ensure key trade-offs are addressed. The output is a draft meant to be edited—solving the blank page problem while keeping the PM responsible for judgment.
- •Sequential workflow: research output feeds the PRD interview agent
- •Agent asks for evidence inputs (Figma, screenshots, POC) or proceeds without them
- •Question bank covers trade-offs, one-way-door decisions, and scope shaping
- •Goal is faster, higher-quality drafts—not replacing PM decision-making
- 27:37 – 35:27
What a “good PRD” looks like now: short, decision-oriented, paired with a prototype
They redefine PRDs as ideation/problem-solving tools rather than heavyweight gating documents. The modern PRD is typically 1–2 pages: crisp problem, options, and a user journey—while prototypes replace long narrative detail and become the main alignment artifact.
- •PRD is not a gate; it’s a catalyst for aligned problem-solving
- •1–2 pages: customer problem, solution options, sample user journey
- •Prototypes replace 20-page docs and drive richer cross-functional critique
- •Figma Make preferred for shareability and collaborative iteration
- 35:27 – 40:30
Orchestrator: a ‘God’s-eye view’ across every repo with inherited skills and sandboxes
Charles introduces Orchestrator, an internal tool that lets “casual” users interrogate any repo without recreating each team’s local setup. It spins up sandboxes, routes across models/harnesses, inherits repo-local skills/MCPs, and can even generate PRs for small changes.
- •Central UI lists all major company repos and lets users query or change them
- •Creates a sandbox per task and clones only what’s needed for the work
- •Inherits repo-specific skills/MCP servers so users don’t replicate environments
- •Core components: sandboxing + model gateway/router + skill/context organization
- 40:30 – 44:25
Shared context as a hierarchy (not a flat pool): right-sizing what people need to know
They abandon the idea that everyone should share one giant, flat context set. Instead, context is layered: most people only want enough to answer a question or fix a small issue, while domain owners go deep—tools like Orchestrator enable this traversal.
- •Most teammates don’t want full nuance of other domains—only what’s needed now
- •Context should be layered: deep ownership + shallow cross-team visibility
- •Orchestrator supports lightweight cross-repo exploration and contribution
- •Better than forcing constant org-wide context synchronization
- 44:25 – 52:32
Agent Evals: testing the product as an agent and using failures to improve docs/UX
Hassan demos Agent Evals: a harness that runs realistic end-to-end tasks in a sandbox (often via Claude Code), watches the agent execute via API/SDK/CLI, and scores outcomes. The biggest payoff is actionable ‘improvements’—especially doc fixes—driven by transcript-level visibility into where agents get stuck.
- •Define representative tasks per product area (e.g., fine-tune → deploy endpoint → evaluate → delete)
- •Run in sandboxes with required keys/assets; observe full transcripts
- •Compare runs across different contexts (docs only vs MCP vs skills)
- •Use failures to prioritize concrete doc/UX fixes (e.g., missing links, discoverability gaps)
- 52:32 – 59:34
Where PM ends and developer begins (plus realistic gains and cost control)
Charles argues roles haven’t fundamentally changed: PM value is validated market insight; engineering value is maintainable, efficient design. AI mainly lowers the friction for each side to do small tasks in the other’s domain—while real velocity gains are meaningful but not magical, and cost stays sane when teams optimize collective throughput and use cheaper models.
- •PM’s core: unique, well-validated market/customer insight
- •Engineer’s core: efficient design that’s maintainable and extensible
- •AI enables cross-boundary reach for small/medium tasks (PMs can PR; engineers can research customers)
- •Skepticism of ‘3X’ claims: discovery/coordination still dominate; costs managed via open models + avoiding slop
