Aakash GuptaThe Unfair Way to Build an AI Native Product Team
CHAPTERS
- 0:00 – 3:30
From individual AI output to collective team productivity (avoiding “context window slop”)
Charles frames the core problem: AI can make individuals produce more, but that often just floods teammates with low-signal artifacts. Together AI optimized for collective throughput—centralizing reusable context and workflows so outputs advance the company, not just activity.
- •AI as a superpower can increase output without increasing progress
- •The new failure mode: overwhelming coworkers with low-quality AI-generated docs/code
- •Shift the goal from individual productivity to organizational momentum
- •Decide what should be centralized vs left to individual workflows
- 3:30 – 6:31
The Together Product Repository: shared context + reusable skills in Markdown/YAML
Nicolina introduces the “Together product repository,” a central repo of lightweight files that encode strategy, product context, and repeatable workflows (“skills”). The repo enables agents/harnesses to pull the right context on demand and lets teams reuse each other’s work without constant meetings.
- •Repository is mostly Markdown with some YAML for agent/harness consumption
- •Contains product-area context (e.g., customer intelligence, sandboxes) and strategy artifacts
- •Enables cross-team leverage: use another PM’s docs before syncing live
- •Separates general skills from code-specific artifacts that belong in engineering repos
- 6:31 – 8:57
Automating recurring PM work: sprint status updates, daily news briefs, and model/harness choices
Nicolina walks through practical skills that save time: end-of-sprint updates pulled from repos/projects and a daily competitor/news brief. The team started with Claude Code but increasingly uses Together’s own models and open harnesses for cost and flexibility.
- •Status-update skill pulls shipped/ongoing/next items from chosen sources and drafts leadership updates
- •Morning news-report skill scans competitors/model labs and generates a readable brief
- •Adoption path: began with Claude Code, moving toward own open-weight models
- •Harness experimentation: OpenCode, Hermes, and model-task fit (coding vs analysis)
- •Cost awareness: proprietary models can become expensive at scale
- 8:57 – 10:41
Ownership and freshness: who maintains shared context and skills?
Aakash presses on the risk of stale context. Nicolina explains governance: domain owners maintain their sections; strategy/planning outputs get translated into Markdown; changes flow through normal PR behavior when gaps are discovered.
- •Context ownership maps to product-area ownership (e.g., sandboxes maintained by its PM)
- •Strategy updates happen after clear “direction-setting” events from leadership
- •Anyone can propose updates via PRs; missing context becomes a trigger to improve it
- •Treat the repo like any other codebase with review and iteration
- 10:41 – 15:32
Team skills vs personal skills: where they live and when they get promoted to “shared”
The team uses rules for skill placement: keep code-adjacent skills co-located with the relevant repo; everything else lives in personal or shared repos. Individuals can incubate skills in branches, then promote them to main when they prove repeatable and broadly useful.
- •Principle: keep skills closest to the work they reference (especially code)
- •Non-code/global workflows go to personal repo or shared product repo
- •Incubate niche skills in branches; promote to main after repeated use
- •Avoid forcing uniformity while still enabling reuse
- 15:32 – 23:40
Live feature research: one command to pull evidence from Pylon, Linear, and Notion
Pavneet demonstrates how discovery is accelerated by a research skill that aggregates customer tickets, project status, and internal docs. In minutes, he can quantify demand, grab verbatims, and avoid duplicating partially implemented work.
- •Research skill integrates Pylon (support), Linear (execution), and Notion (docs)
- •Outputs: size of problem, ticket counts, customer verbatims, links for deep dives
- •Finds existing/abandoned implementations to prevent duplicated effort
- •Discovery and alignment stays human-in-the-loop; execution becomes more automated
- 23:40 – 27:31
Customer Insights MCP: unified voice-of-customer across Gong, Slack, and support
The team shows a dedicated Customer Insights tool that summarizes and catalogs calls and tickets, with an MCP server for querying. Hassan explains it’s maintained by DevEx and runs largely automatically via a daily ingestion pipeline that surfaces “daily insights.”
- •Covers multiple sources: Gong + Slack + Pylon (and more)
- •Daily cron ingests the last 24 hours into a database powering the app
- •Delivers daily surfaced insights and supports chat/query via MCP
- •DevEx owns and evolves the tool; internal tools are iterated or retired based on usage
- 27:31 – 27:31
PRD Writer skill: an interviewing agent that challenges assumptions
Pavneet triggers a PRD writer that conducts a structured, turn-by-turn interview, optionally ingesting prototypes or a POC. It pulls shared context and uses a question bank to force tradeoff thinking, reducing blank-page friction while preserving human decision-making.
- •PRD writer can ingest a prototype, screenshots, or POC—or start from a simple prompt
- •Agent is instructed to challenge assumptions, not just comply
- •Question bank covers tradeoffs, one-way-door decisions, and scope boundaries
- •Agents feed each other: research output becomes PRD input
- 27:31 – 31:55
What a good PRD looks like now: 1–2 pages + prototype replaces the 20-pager
They redefine PRDs as lightweight artifacts for ideation and shared understanding rather than heavyweight gates. The modern PRD is short—problem, solution options, and user journey—while prototypes carry much of the detail and debate.
- •PRD as ideation trigger, not a gating document
- •Keep it to one or two pages: customer problem, options, sample journey
- •Amazon-style long PRDs give way to prototypes for richer discussion
- •Prototype skill turns a one-pager into a detailed prompt for Figma Make / design tools
- •Figma Make preferred for shareability and iterative collaboration
- 31:55 – 35:07
Reviewing the AI-drafted PRD: strong structure, but still needs human editing
Pavneet shares an example final PRD draft with evidence, goals/non-goals, user stories, and API/UX flow. It captures key issues (like billing implications) but can leak internal implementation details into user journeys—reinforcing that drafts require PM refinement.
- •PRD includes evidence counts, customer names, and verbatims for credibility
- •Goals/non-goals reduce scope creep; user stories anchor use cases
- •Agent surfaced missed considerations (e.g., billing adjustments, capacity constraints)
- •Drafts can include unnecessary internal details; PM must edit before broad circulation
- 35:07 – 40:24
Orchestrator: a “God’s-eye view” across every repo with sandboxed Q&A and PRs
Charles introduces Orchestrator, an internal tool that lets “casual” cross-team contributors interrogate any repo without recreating local setups. It spins up sandboxes, inherits repo-specific skills/MCP servers, supports multiple harnesses/models, and can even generate pull requests.
- •Unified UI over all major company repos/products
- •Pick harness (OpenCode/Claude/Cursor) and model per task
- •Sandbox clones the needed portion of a repo to answer questions or craft PRs
- •Inherits the latest skills/MCPs maintained within each repo
- •Designed for cross-team exploration and lightweight contributions
- 40:24 – 41:19
Shared context is a hierarchy, not a flat pool (and Orchestrator helps traverse it)
Charles explains why “everyone shares everything” doesn’t work: most people only want enough context to answer a specific question. Together treats context as layered—deep for owners, shallow for casuals—so tools enable quick traversal without forcing total alignment overhead.
- •Rejected the idea of one broad, flat shared context for everyone
- •Most users want targeted answers, not full domain nuance
- •Context should be hierarchical: deep ownership vs shallow traversal
- •Orchestrator provides server-side maintained access to local context/skills
- 41:19 – 44:19
How to build Orchestrator: sandboxing + model routing + reusable components
They outline the architecture and effort behind Orchestrator: sandbox execution per task, a model gateway/router for multi-model workflows, and leveraging open source/commercial components. Hassan estimates a few weeks to a month of engineering time to ship an initial version.
- •Core requirements: connect to all repos and inherit repo-local skills/MCPs
- •Sandboxing is essential for safe, repeatable PR generation and investigation
- •Model gateway/router enables multi-model, multi-harness operation
- •Many building blocks exist as OSS or commercial products; not out of reach
- •Initial build time: a few weeks to ~1 month engineering time
- 44:19 – 52:26
Agent Evals: testing the product as an agent, improving docs and UX continuously
Hassan demos Agent Evals, which runs end-to-end agent tasks (e.g., fine-tune a model, deploy an endpoint, evaluate, then clean up) inside sandboxed harnesses and scores success. The system provides transcripts and actionable “improvements,” driving rapid doc and product fixes—turning UX validation into a continuous loop.
- •Write task suites with PMs to represent real agent user journeys
- •Spin up sandbox + Cloud Code, provide keys/artifacts, and observe execution
- •Compare runs with different contexts: docs-only vs MCP vs skills
- •Inspect full transcripts to diagnose failures and generate targeted fixes
- •Agent-based validation provides faster, more objective UX signal for developer products
- 52:26 – 59:27
Where PM ends and developer begins in the AI era (and realistic productivity claims)
They conclude that the essence of roles hasn’t changed: PMs bring validated market insight; engineers deliver maintainable designs. AI mainly lowers the friction for each side to do small-to-medium tasks across the boundary, while true bottlenecks (discovery, debate, coordination) remain; productivity gains are meaningful but not magical 3× leaps.
- •PM core: unique, validated market insight grounded in internal/external context
- •Engineer core: efficient, maintainable, extensible design and architecture
- •AI enables boundary-crossing for smaller tasks (PMs can PR; engineers can research VoC)
- •Coordination/discovery still constrain velocity; skepticism toward exaggerated 3× claims
- •Cost control: using own open-weight models and focusing on collective productivity limits runaway token spend
