Use repos for product docs

A pair of posts by product writer Aakash Gupta argued that product and operations teams should run documents in shared repositories, not scattered Google Docs and Slack threads. (news.aakashg.com) The posts, published on X and echoed in Gupta’s April 7 Substack podcast listing, described a workflow where teams check documents into a repo, open pull requests for changes, and route updates into Slack. (x.com) (news.aakashg.com) A repository is a versioned folder: every edit is saved as a commit, and a pull request is a formal request to review changes before they land in the main copy. Microsoft’s Azure Repos documentation says repos support pull requests, code review, reviewer assignment, and branch policies that can require approvals before a merge. (learn.microsoft.com 1) (learn.microsoft.com 2) Slack is the notification layer in that setup. Microsoft’s Azure Repos Slack integration sends channel alerts when code is pushed and when a pull request is created, updated, or merged; GitHub’s marketplace also lists actions that post review requests, comments, approvals, and merges into Slack threads. (learn.microsoft.com) (github.com) The pitch lands as more non-engineering teams are adopting developer tools to manage fast-moving work. Gupta’s own recent writing and interviews have focused on product managers using shared repos, prototypes, and internal workflows as everyday operating systems rather than one-off documents. (news.aakashg.com) (atlassian.com) That changes the review process from “latest link in chat” to a record with diffs, comments, and approvals attached to one file history. Azure Repos says pull requests notify reviewers, track comments, and can enforce minimum reviewers on critical branches such as main. (learn.microsoft.com) The tradeoff is that a repo workflow asks non-engineering teams to learn branching, commits, and review queues that were built for software teams first. Microsoft’s docs tie some features to project permissions and web-based review flows, which can add setup and admin overhead before a team sees the benefits. (learn.microsoft.com 1) (learn.microsoft.com 2) The idea is not that product documents become code. It is that planning, requirements, and operating procedures get the same version history, review gates, and notification trails that engineering teams have used for years. (learn.microsoft.com) (x.com)