Your first PM can’t read your mind. Build them a shared brain.
The setup I ran at GitHub, and how to build one before your first PM starts.
At the start, founders make decisions faster than anyone else. You remember every customer chat, failed test, strategy, and reason for each choice. What takes a big company a week of meetings, you can decide in minutes because you don’t need to document or get everyone on the same page first.
That speed helps until you bring someone in. In my last post, I explained why first PMs often struggle. The main reason is they can’t access what’s in your head. They see your decisions without the years of reasoning behind them, so they seem to miss the point. The knowledge that helps you move quickly is out of their reach.
You could let your first PM start from scratch and create their own vision. But if you do, you might end up with two different directions. Early companies need everyone working from the same context to stay aligned.
Writing things down has always been the simple solution, but founders skip it because it feels faster not to. What’s different now is the benefit. Before, new hires might read your notes once and never look again. Now, AI can find, understand, and use that information whenever the team needs it.
What a shared brain looks like
You might have heard of the second brain, a way to store what you know outside your head. Tiago Forte created a method for this, and Lenny Rachitsky has written about PMs using tools like ChatGPT and Claude for their own second brains. Those are personal. As a founder, you need a shared version that your first PM can use, your team can add to, and your AI tools can access.
Engineering teams already know what this looks like. It has three layers.
The first layer is the front door: a single file at the root of your repository called AGENTS.md. Major labs and tool makers use this as a standard, and it’s already in tens of thousands of repositories. It’s like a README for agents. It explains what you’re building, who it’s for, which decisions are final, and how you want things to work.
Behind that file is the store, where most of the context is kept:
the current plan, and the success criteria you’re judging it against
a running decision log, each call recorded with the reasoning behind it
customer signal: conversation notes, research, and the feedback that drove real decisions
the dependencies you’re waiting on, and the questions still open
recordings and transcripts of your meetings, which most software now captures automatically
The last layer consists of systems that change too quickly to document: your analytics, your error logs, your issue tracker, and wherever the team talks. Using MCP, a standard that lets agents pull data from other tools, you connect them once, and the agent can reach them whenever needed.
How I built one at GitHub
As a senior PM at GitHub, I built this exact setup, though I didn’t have a name for it at the time. Our team used seven main parts:
a fresh GitHub repository for each major initiative, holding the plans and context as markdown files
Copilot CLI as the agentic harness, GitHub’s answer to Claude Code
Issues for intent and work tracking
Discussions for exploring pitches and early ideas
Pull requests as the alignment layer over those docs and plans
MCP tools wiring in our analytics and Slack
Agentic Workflows for the recurring chores, like the weekly updates and issue triage
Once everything was set up, I stopped writing things by hand. I didn’t write memos, product updates, issues, PRDs, or epics myself. Instead, I told Copilot CLI what needed to be done, provided the context, and then reviewed the results carefully to ensure I agreed with every word.
I mostly worked from the terminal, with several sessions open at once. Later, I switched to the GitHub Copilot app when it made it easier to keep sessions separate. I spent most days in those repositories, and so did the AI.
I chose a git repository instead of a doc or wiki for two reasons: the AI could work directly inside it, reading and editing files, and the version history automatically tracked what changed and why.
When I wanted feedback on a plan or document, I opened a pull request, gathered the team’s comments, and made changes using Copilot CLI before merging the final version. This let us stay aligned without meetings, working together even when we weren’t online at the same time.
How to start building yours
Almost every part of my setup was a GitHub product. We dogfooded everything, so those were the tools to hand. You don’t have to copy it exactly, and the same setup works with alternatives.
Choose the part of the product your first PM will manage, or the whole company if they’re your first hire, and set up a repository your AI tools can read. Start with the front door: one file that explains what you’re building, who it’s for, and what’s already decided. Then add three things to the store: your current plan, the decisions that led you here and why, and anything you’re still unsure about. It doesn’t need to be perfect or finished on day one.
Keep it up to date. Whenever you make a new decision or change your thinking, update the repository. This takes some weekly discipline. Before you ask your AI for help, point it at the repository so that “work from what’s already here” becomes the default.
To build a real product function, you have to give up the thing that made you fast: keeping everything in your head. Founders who succeed at handing things over start sharing their thinking early, before and after the PM joins. When you do this, your first PM and your AI tools can start from what you already know.
I help founders build their product function from the ground up through coaching and advisory. Getting what’s in your head into a shared brain is where a lot of that starts. If you’re facing this handover, or looking for help building your product org, get in touch.
What’s the most important context you’re still keeping in your head? Reply and let me know.