Context

Together AI just raised $800 million at an $8.3 billion valuation selling AI inference and fine-tuning to developers. Host Aakash Gupta gets a live screen-share walkthrough of the product team's actual shared repository and workflow tools from CPO Charles Zedlewski and three of his product and engineering leads: Nicolina (product), Pavneet Alwalia (infrastructure PM), and Hassan (developer experience). This matters to PMs because it's a rare look at a company that has already built and battle-tested a shared "product operating system," not a theoretical framework, covering how context and skills get organized, how a PRD gets written and reviewed by AI, and how a shipped feature gets validated against real agent usage rather than just human user testing.

The Big Idea

Individual AI productivity can move a company backwards if everyone just generates more code and content in isolation; the real unlock is making a team collectively more productive by centralizing shared context and skills while keeping judgment calls human.

Together AI's product team explicitly rejected optimizing for each person feeling faster and instead built a shared repository of markdown context files and reusable "skills" so that a PM's research, prototypes, and PRDs plug into everyone else's work instead of flooding colleagues with disconnected output.

Key Insights

Individual output can be negative-sum for the team

Charles Zedlewski describes the failure mode that shaped the whole system: a world where every product person and engineer could generate unlimited code and content, but it wasn't "necessarily forward progress for us as a startup." He calls the result "flooding your coworkers' context windows," where everyone launches slop at one another. The team's response was to explicitly optimize for collective productivity (work that compounds across the team) rather than individual productivity (each person feeling faster in isolation).

The shared repo holds context and skills, not code

The Together product repository is mostly markdown and YAML files, split into two categories. Context files cover things like customer intelligence, sandboxes, and the output of quarterly strategy meetings broken down by mission and milestone, so a PM working on a cross-team workflow can read another team's documented context and draft a real proposal before ever taking up that PM's time. Skills are reusable prompts/workflows, like an automated end-of-sprint status report that pulls from each project's Linear tickets, or a personal morning "competitor news" digest, and anything tied to a specific codebase deliberately stays out of this shared repo and lives with that code instead.

Skills live closest to the work they touch

Pavneet's rule for where a new skill belongs: if it references code inside one team's repo, it stays colocated there; everything else goes into either a personal or a shared repo. A new skill typically starts on a branch, gets tested and reused a few times to confirm it's repeatable, and only then gets pushed to the shared main branch. Niche, one-off skills are deliberately left on a branch and never promoted, which keeps the shared repo from accumulating clutter nobody else needs.

Shared context is a hierarchy, not a flat pool

The team initially considered making everyone carry everyone else's full context, then abandoned it. Charles found that most people have little motivation to learn the depth and nuance of another team's area; they want the single answer to the specific question they came with. The resulting design is a context hierarchy: a few people live deep in a given area's context, and most people just traverse the top layer when they need one thing, which is also the reasoning behind Charles's own "Orchestrator" tool described below.

The PRD stopped being a gating document

Pavneet contrasts today's approach with the historical model (he cites his time at Amazon, "used to writing like 20-page PRDs") where a long document was the alignment gate everyone had to sign off on before building started. Together now treats the PRD as a trigger for ideation and problem-solving: one to two pages that define the customer problem clearly, lay out a few solution options without needing them fully fleshed out, and sketch a sample user journey (API-based or UX-based) for the option under discussion. That's enough to have the real debate about whether the feature is worth building and what the engineering design should look like.

A prototype, not a long document, carries the detail

A separate "UX prototype" skill takes the one-pager PRD and generates a detailed prompt for a design tool (the team uses Figma Make specifically because the output is a shareable, click-through link, versus Claude's raw HTML output which is harder to version and share). Pavneet finds that once people can see and click through an actual visual prototype, that's where the sharpest, most concrete feedback shows up, from engineering and marketing alike, replacing what used to be pages of written detail in a traditional PRD.

Discovery research dropped from half a day to five minutes

Pavneet demonstrates a "research" skill that queries Pylon (support tickets), Linear (engineering execution), and Notion (internal docs) simultaneously for a real feature request (customers wanting self-serve storage volume resizing). It returned 19 tickets filed in the last two months, flagged that the feature had actually been partially built before and abandoned, and surfaced verbatim customer quotes with sources. Pavneet's assessment: "if I had to do this manually, this would have easily occupied half of my day, if not more," and the real value isn't the summary text, it's not duplicating work an engineer already half-finished.

Agent evals treat "can an agent use this" as the new UX bar

Hassan's team built "Agent Evals," which spins up a sandbox, hands an agent a real task against the live product (for example: run a fine-tuning job on a given dataset, deploy the resulting model as an endpoint, send it test inference requests, then delete the endpoint), and simply watches Claude Code attempt it end to end. One run revealed the agent couldn't find the page listing fine-tunable models, not because the page didn't exist, but because it wasn't linked from the main fine-tuning quickstart doc; that single finding led to dozens of documentation fixes across the product. Charles frames this as necessary because "at this point, for a lot of our products, agents are already the majority user," so validating design quality can now happen continuously in hours instead of waiting on rounds of human usability testing with conflicting signal.

Mental Models & Frameworks

Human in the loop for decisions, automated for execution

Together's product team draws a consistent line: defining the feature, the API surface area, and the abstraction layer stay hands-on and human, while the actual code-writing execution runs automatically once those decisions are set. Pavneet triggers a "goal" (e.g. "give me production-ready PRs for resizing shared volumes without destroying data") and the system spins up multiple sub-agents to investigate the data plane, control plane, and existing docs in parallel, only pinging him for missing information or an actual design decision.

Orchestrator as a shallow, on-demand cross-team interface

Charles built "Orchestrator" specifically to avoid having to replicate every other team's deep skills and MCP servers just to ask one occasional question about their code. It's a UI wrapper across every product repo in the company: pick a repo, pick a model and harness (Claude, OpenCode, Cursor, GLM, etc.), ask a question or request a small pull request, and it spins up a sandbox that clones just the needed slice of that repo. Hassan estimates it took a few weeks to a month of engineering time to build, and notes the underlying pattern (repo access plus MCP/skill inheritance, sandboxing, and a model router/gateway) is common enough now that other companies (he cites a marketing agency he met at a conference) have built equivalents, and open-source versions exist too.

Turn-by-turn PRD interview instead of a blank page

The "PRD writer" skill Pavneet uses doesn't generate a document from a single prompt; it interviews the PM turn by turn, using a pre-built question bank (trade-offs, one-way-door decisions, scope boundaries) and is explicitly instructed to challenge the PM's assumptions rather than just accept them. Pavneet's take: "it's not a substitute for me, but it really does two things: it speeds up the whole PRD-writing process, it solves the blank-page problem to a large extent, but it also catches a lot of things that I might not have thought of."

Trade-offs & Nuance

AI output still needs a human edit pass before it goes wide

Walking through a generated PRD live, Pavneet finds the headers and structure are consistently right, but "the devil is in the details": one user-flow step described an internal validation detail that had no business being in a user-facing journey description. The generated document explicitly labels itself a draft not meant for wide distribution, and Pavneet is clear you "can't just immediately take this and start sharing this with your colleagues," reinforcing that the human-in-the-loop review step is not optional even for a mature, well-tuned skill.

The essence of PM and engineering roles hasn't changed, the reach has

Asked where the line between PM and developer now falls, Charles argues the core of each role is the same as before AI: the PM's most valuable contribution is still a unique, well-validated market insight, and the engineer's is still architectural judgment. What's changed is how far each side can reach into the other's territory for small and medium tasks, a PM can now interrogate a codebase and open a small pull request, and an engineer can run the same customer-insights query a PM would have run. Convenience of reach expanded in both directions; the underlying skill each role is valued for did not converge.

Be skeptical of large multiplier productivity claims

Charles pushes back directly on a Chamath Palihapitiya observation that token costs were doubling roughly every 70 days while engineering productivity claims of 3x circulated industry-wide. Together doesn't track story points, so Charles can't cite a precise number, but he estimates velocity gains "more than 5%" and calls 3x-style claims "very suspicious," reasoning that a large chunk of building software, discovery, debate, re-evaluation, and coordination among a team, doesn't get magically faster just because coding and testing got compressed by AI.

Practical Application

Split your team's AI repo into context (read-only knowledge) and skills (reusable workflows)

Set up two categories from the start: context files (customer intelligence, strategy/mission docs, per-team entry points) that anyone can read before starting cross-team work, and skills (repeatable prompts/workflows like a sprint status generator) that live closest to the code they touch, promoted to a shared location only once proven repeatable.

Replace your long-form PRD with a one-to-two-page problem doc plus a clickable prototype

Cut the traditional PRD down to just the customer problem, a few solution options, and a sample user journey, then generate a prototype (via a design tool your stakeholders can click through) to carry the detail that used to live in extra pages of prose. Route the sharpest feedback conversations around the prototype, not the document.

Wire a research skill into your support, tracking, and docs tools before writing a PRD

Before starting to write a PRD, query your support-ticket system, project tracker, and internal docs together for evidence: how many customers actually asked for this, is it already partially built somewhere, and what do customers say in their own words. This turns a half-day research task into a five-minute starting point and prevents duplicating in-flight engineering work.

Build an "agent evals" pass into your launch checklist if agents are meaningful users of your product

For any feature developers will reach via API, CLI, or SDK, write a handful of realistic end-to-end tasks and have an agent attempt them unattended in a sandbox, then review where it got stuck. Treat every place the agent failed (a missing doc link, an unclear parameter) as a real UX defect, the same as you would a human usability-test finding.

Keep feature-definition and API-surface decisions in your own hands even as execution automates

As you push more of the coding and testing work to automation, explicitly protect the decisions that define what the feature is, how tenants and abstractions are shaped, and what tradeoffs are acceptable. Use an AI PRD or design skill that's instructed to challenge your assumptions rather than just accept your first framing, so the speed gain doesn't come at the cost of a weaker problem definition.

Bottom Line

The gains from AI in product work come from making a team's context and workflows composable across people, not from each person individually producing more; centralize customer research, PRD structure, and prototyping into shared, reusable skills, keep the actual product-defining decisions human, and validate what you ship against real agent usage as the new baseline for good UX.

Tools & Products