Aakash GuptaHow to Build an AI-Native Product Team in 2026 | Charles Zedlewski | Product Growth
At a glance
WHAT IT’S REALLY ABOUT
Together AI’s 2026 playbook for AI-native product teams and workflows
- Together AI reframed AI adoption from maximizing individual output to improving collective progress by reducing context overload and standardizing reusable workflows.
- The team runs on a shared product repository (Markdown/YAML) that stores strategy context and reusable AI “skills,” maintained through explicit ownership and pull-request hygiene.
- PM workflows are partially automated: discovery tasks (research, decisions, trade-offs) remain human-in-the-loop, while execution (draft PRs, code scaffolding) can be delegated to goal-based agent runs backed by engineering runbooks and architecture docs.
- They redesigned PRDs for the AI era: short one-to-two page documents grounded in evidence, paired with prototypes that carry most of the “detail” and drive higher-quality stakeholder feedback.
- At the company level, tools like Orchestrator and Agent Evals provide cross-repo visibility, sandboxed changes, and continuous agent-based product testing so teams can validate whether agents can successfully use shipped features and documentation.
IDEAS WORTH REMEMBERING
5 ideasOptimize for collective throughput, not individual AI “busyness.”
Together AI found that making each person “faster” can backfire if it increases noise—more docs, more code, more messages that others must parse. Their focus shifted to shared workflows, reusable skills, and curated context so AI output reliably advances team priorities.
Treat context and workflows as versioned infrastructure (a repo), not scattered docs.
They maintain a shared, Git-based product repository (mostly Markdown/YAML) containing strategy artifacts, product context by area, and reusable “skills” that agents can run. It’s designed so PMs can pull relevant context on-demand while keeping code-specific knowledge close to the relevant engineering repos.
Prevent context rot with clear ownership + PR-based updates + usage-driven fixes.
Ownership is explicit: PMs maintain context for their product areas; company-level direction gets updated after clear leadership “direction-setting” moments (planning sessions, CEO letters). Anyone can submit PRs; staleness is discovered when someone tries to use the context and patches it like normal code.
Keep skills closest to where they run; promote only repeatable workflows to shared main.
Skills that touch a specific codebase live with that code; general repeatable workflows live in the shared repo; niche experiments can stay on personal branches. This creates a practical boundary between team standards and personal experimentation.
Modern PRDs are short, evidence-linked prompts for decision-making—not 20-page artifacts.
Their “PRD writer” skill interviews the PM turn-by-turn, challenges assumptions, and pulls in customer evidence and shared context to generate a draft PRD. The PRD is intentionally short (1–2 pages) and used to trigger ideation and alignment, not as a heavyweight gate.
WORDS WORTH SAVING
5 quotesIt felt like after a while that the new party foul was flooding your coworkers' context windows, where we all just start launching slop at one another.
— Charles Zedlewski
What would it mean to use AI, but not to use AI to just make ourselves individually productive, where we all just start launching slop at one another, um, but rather AI to make us collectively more productive.
— Charles Zedlewski
If I had to do this manually, this would have easily occupied half of my day, if not more.
— Pavneet Singh
What replaces the bulk of that is actually a prototype.
— Pavneet Singh
We sort of set aside the idea that there was one big, broad, flat set of context that we're all gonna swim in, and it's much more like a context hierarchy.
— Charles Zedlewski
High quality AI-generated summary created from speaker-labeled transcript.