TRD (Technical Requirements Document) Process

The Technical Requirements Document (TRD) is the single source of truth for every AI/full-code project, from kickoff through delivery. Announced at the August 25, 2026 all-hands. It replaces scattered specs, Slack threads and tribal knowledge with one collaborative, living document that PM, developer and client all refer back to.

Why this exists

Estimation, scope creep and handoffs were the biggest pain points on AI/full-code projects. We needed one document that everyone (PM, dev, client) trusts as the definitive spec. The TRD is collaborative and live, not something written once and forgotten.

The workflow

Project Manager edits the Google Doc in the relevant section.
PM pings the developer in Slack that the section was updated.
PM logs the change as a Plutio task. This is a must, not a nice-to-have, so we have an audit trail.
Developer updates on GitHub.
Loop closes.

What you need to know

Every new AI/full-code project has a TRD, no exceptions. This applies going forward from the August 25, 2026 all-hands.
Existing projects that started before this process are grandfathered in. They may have their own thing going on, and that is fine.
The TRD is also what gets handed off to the client during onboarding: they learn everything about their project through this one doc.
Do not set it aside during development. Refer to it constantly. It is your defense against scope disputes and finger-pointing.

The bar: the TRD is collaborative, live, and everyone's responsibility. If it is out of date, that is a team failure, not a PM failure.

Context

Q3 2026 saw the company's project mix shift entirely to full-code AI work (Bubble and FlutterFlow projects dropped off). Full-code projects need real dev lifting: setup, architecture, estimation, execution. Estimation on speed was already a known pain point (see Roadmap Estimation), which is a big part of why the TRD now exists as the shared, versioned spec both sides can hold each other to.