---
title: "What if the product development operating system lived in git?"
description: "A conversation at Demo Nights brought me back to an idea: keeping product decisions, their reasoning, implementation and postmortems traceable in the same repository."
date: 2026-09-09
author: "Gabi Udrescu"
tags: ["product-management", "git", "collaboration", "decision-making"]
source: https://productowner.ro/blog/product-development-operating-system-in-git/
---
# What if the product development operating system lived in git?
import ProductDecisionDemo from '../../../components/ProductDecisionDemo.astro';
I ended my evening at [Demo Nights by How to Web](https://luma.com/Demo-Nights-7) with a chat with [Petre Dragoș Constantinescu](https://www.linkedin.com/in/petre-drago%C5%9F-constantinescu-41473556/) and [Mara Hutart](https://www.linkedin.com/in/mara-hutart-681108247/) about something I’ve [written about before: bringing product requirements into git](https://productowner.ro/blog/git-for-product-requirements/).
The conversation went into the broader idea of a product development operating system living in a GitHub repository. Decisions reviewed as pull requests, the reasoning kept alongside the implementation, and a trail you can follow six months later when you are writing the postmortem and trying to understand why you made those choices.
As engineers, they immediately connected with the idea of having that history available. Their reaction gave me some encouragement to do more with it. I’ve been thinking about this for a while, and talking it through with people outside my usual work context helped.
## Let the agent deal with git
Product people and nontechnical colleagues should be able to use this without learning git. I want to explain a change, read what it does to the document, and ask the right people to review it. Learning how to untangle branches should not be the price of admission.
Git is already familiar territory for coding agents. [Claude Code, for example, can create branches, commit changes and open pull requests](https://code.claude.com/docs/en/overview#create-commits-and-pull-requests). Preparing an edit to a requirements document uses those same mechanics; the product judgement still belongs to us.
The experience I have in mind is closer to: “Move SMS to a later release, keep email for launch, and ask support what we’re missing.” The agent prepares the proposal with the reasoning we supplied, then brings back the changed document for people to review. **We should be reviewing the decision, without having to operate git ourselves.**
## What actually changes in the document?
Take an order-tracking feature for an online shop. This is a made-up example, but the trade-off should look familiar: reduce the scope or move the launch date.
## Product decisions as pull requests
The part I find enticing is reviewing decisions in the same way engineers already review code: someone proposes a change, others question specific parts, and the discussion stays attached to the proposal. Git keeps the document versions; a platform such as GitHub or GitLab keeps the comments and approvals around them.
## A postmortem with the reasoning still attached
Six months later, customers report missing delivery updates, and I ask an agent to investigate why SMS was left out of the launch. It can search the codebase, find the relevant line in the PRD, and follow its history back to the PR, the people who contributed and the reasoning in their inline comments.
That gives me something useful for the postmortem: the constraint we were working around, the assumption we made, and the fallback someone thought to add. **The names help recover context; they are not a list of people to blame.** Knowing why we chose a scope still leaves the incident’s cause to investigate.
For this trail, I don’t need to wire an agent into Jira, Confluence and three other places where a decision might have ended up. The PRD lives beside the code, git keeps its history, and the PR keeps the discussion. The agent needs access to that repository and its PR comments, plus a habit from us of writing down the rationale and preserving the PR reference. A grep is a starting point. The useful output is a few evidence-backed paragraphs and better questions for the team.
## GitLab already does this beyond engineering
[GitLab’s handbook](https://handbook.gitlab.com/handbook/about/handbook-usage/) is a useful example: changing a company process means proposing a change to the handbook through a merge request, their name for a pull request. Each department is responsible for keeping its part current. That is a fairly concrete way to make “this is how we work” something people can question and update.
This extends into nontechnical work. The [finance handbook](https://handbook.gitlab.com/handbook/finance/) directs people to a finance issue tracker, including confidential issues, and [marketing operations works from issues and issue boards](https://handbook.gitlab.com/handbook/marketing/marketing-operations/). Even [product budget requests go through issues](https://handbook.gitlab.com/handbook/product/product-management/#working-with-finance-business-partners), with leadership bringing them into planning with Finance.
Those issues live in GitLab’s collaboration platform; the document history lives in git. What interests me is the shared habit: write down the proposal, involve the people responsible, and leave a record others can follow.
GitLab’s example shows the organisational practice. The part I want to explore is using agents to make that practice accessible without asking everyone to learn the tools underneath. A colleague in finance should be able to question a cost assumption in plain English and see that feedback reflected in the next revision. I would quite like that for my own work, too.
---
Thanks to Dragoș and Mara for the conversation. Their interest was a useful nudge to come back to this idea and see what I can make of it.