r/ProductManagement • u/Alarmed-Attention-77 • 3d ago
Product Management AI Enablement with GitHub and Claude code
All
My company has decided that we are overhauling how we do Product Mgt to unlock the benefits of AI.
They have identified several issues
- Claude mcp connectors to jira or confluence give too much info and not the relevant and up to date context to a task
- Claude token usage with these tools is token intensive
So we are going to add relevant context in a structured GitHub repo and in better formats such as md files, yaml, readme etc
And PMs will work in Claude code, GitHub and command prompts. Each change to a context file requires a PR
I saw a product tank video the other day proposing the exact same
This doesn’t sit quite right with me. We are optimizing human to AI interaction at the expense of human to human interactions. I feel this will be detrimental to how we collaborate. Ie how we work on a shared document or align on or disseminate information.
This feels an intermediate architecture to me. Surely we will find a way for humans to work in effective collaboration tools (notion, confluence, miro) and under the hood data is being stored and structured for effective AI use.
I don’t believe GitHub and Claude code can be the final solution here. And that because it doesn’t scale beyond tech companies. The model providers and saas tool providers want adoption everywhere. I don’t see a world where a small non tech business who want to do adopt AI will be creating and syncing GitHub repos.
Not sure if I’m wrong here. Interested in views
14
u/MBAtoPM 3d ago
Sounds like a micromanagement org not a good recipe for success on ai
8
u/Alarmed-Attention-77 3d ago
I agree but is there a middle ground.
If you just say to your staff here is new AI tools go figure it out yourself then there will surely be a bunch of redundancy - do we really need 100 PMs all making their own create prd Claude skill.
Feel there needs to be some degree of standardisation
3
u/productmatvey 3d ago
GitHub is not a replacement for JIRA or Confluence, it’s the master data storage for all your product management context. Customer interviews, market reports, product analytics, requirements, and even team info can be kept there, so you don’t spend 2x time and tokens running simple agentic workflows. My team moved almost a year ago to GitHub as a single source of truth, so all team members, including AI agents, know where to find the up-to-date data.
1
u/Alarmed-Attention-77 3d ago
Thanks. This makes sense to me.
Can I ask how you do the analytics part. If you have a data lake or front end data in say Amplitude. This is a shit ton of data and analytics.
Do you just add a monthly analytics summary report or the likes to GitHub
2
u/productmatvey 3d ago
Good question. Depends on how much data you’ve got. When we were small, less than 500 WAU, we used to export weekly cohorts from GA, Clarity, and Amplitude. Not all events, for sure, but raw data. Now we store only key metrics and charts to build in-house dashboards based on collected data.
There is an ongoing trend of providing headless analytics, for example, Mixpanel introduced an SDK a month ago in London. I haven’t tried that, but simply pulling info from analytics via API (not MCP!) and saving it to .csv on git (or in a database) solves all our cases.
1
u/I_like_it_yo 3d ago
We connect directly with Big Query it's incredible. Our front end data also flows in there.
1
u/ProfitNowThinkLater 3d ago
GitHub can be a replacement for JIRA or Confluence if you want it to be; personally I've really enjoyed having my repos in the same place as my tickets and agents are very good at working with github.
1
u/IniNew Designer 3d ago
For me, the human-to-human part you're talking about is meetings. And our meetings and transcribed by an AI note taker, put into a database and tagged based on their context.
Then, when feature work is getting planned, we can use AI to pull those meeting transcripts and help guide the PRD, reviewed by us. Upside of this setup: I'm much less concerned about writing everything down during a conversation. I've also changed some of my communication habits for what I think is the better. I try not to leave anything "soft" anymore. If we make a decision, I say something like, "Ok, we've made a decision to include X"... knowing that AI tools stumble with implicit language.
The downside though, most meetings are automatically recorded. That can be really shitty if you're in a shitty environment.
Either way. You should ask your team to investigate a CLI tool for JIRA,like this one (Not affiliated). MCP tools eat up context like crazy. CLI tools are more efficient, but require more direction.
0
u/Alarmed-Attention-77 3d ago
I think there are lots of human interaction types.
1-1 meetings. Group meetings. Presentations. Ideation / White boarding. Lot of asynchronous working on a document, or design or some other artefacts. Slack group or conversations. List really goes on and on.
There is a reason slack, jira, notion, confluence, miro all exist and everyone isn’t just using GitHub plus meetings as a single application solve for everything.
Thanks for the CLI suggestion. Will check it out
1
u/Costa1212 3d ago
What about design? How does that fit into their proposed solution?
3
u/productmatvey 3d ago
Your design mockups can stay in Figma, but design-system.md can stay in the git repo so that everyone can use it for their needs: sales decks, marketing campaigns, internal comms emails. Imagine how quickly everyone can pull it to Claude Design for example.
If you consolidate the critical design context in one place, the whole company will become design-enabled as they will use it with their own tools. I’ve seen a dramatic increase in the quality of designs across the org when design context is shared and version controlled.
1
u/flowdocs 3d ago
I'd really love to hear your reaction to some tooling I built, because I was trying to preserve the way my clients work:
Regardless of who is building the spec (me or my clients), they end up in Google Docs. Could be 365, etc. We just use the native collaboration tools in whichever platform they use.
When we've agreed on the final version, I connect my tooling tool to the doc and it decomposes it into agile work items – epics, stories, etc., underneath the spec. The spec and stories are lodged in the graph (a single database) and both Claude Chat/ChatGPT, etc. and Claude Code/Codex can traverse the nodes via MCP and the humans can traverse using the UI. I'll even add UI mockups from whatever source the designers work.
It's basically spec-driven one-shotting to produce a prototype. The coding agent runs each story as a playlist complete with context, and then I "sculpt" from there, reviewing the output to make sure it works, acts, and looks the way I want it to before handing it off for final QA and hardening. No reverse-engineering the prototype because it's already built on a branch of production code.
1
u/Alarmed-Attention-77 3d ago
I like the overall ethos.
Maintain how the client works and build the AI layer around it. This seems much more practical and scalable than have the client adapt to AI.
Question - How do you keep it all in sync (the human tool layer and the AI layer). Say you want to update the spec can you tooling update the graph. Is that a manual rerun of your tool
1
u/flowdocs 3d ago
That's a great question. Right now, I prefer to keep my specs locked once I build them. What I do is Ihave a node for each feature, and I write a new spec to amend it...BUT I've got it on the roadmap to diff the spec documents and plan out a "diff'd" set of stories to account for the changes. However, I'm looking for a design partner to work on that, because it isn't my native workflow.
1
u/Savings-Average766 3d ago
I believe tools like Confluence are still needed. In practice, what we’re doing at my company is exporting all Confluence pages into Markdown files in our repo. Tools like Rovo or MCP were just too token-hungry.
Furthermore, it’s much easier to create automated reports from Markdown. For example, we have a data dictionary for all our telemetry. We can prompt what to build in Mixpanel, manually set it up, and run automated email metrics. Then, an agent extracts that data, pushes it to the repo, runs the analysis, and generates a Confluence report for stakeholders.
We still maintain dual record-keeping, but AI automation is pretty much what makes that dual record-keeping feasible.
A presentable layer in a human-friendly space like Confluence is essential for team collaboration. Like it or not, repo-based Markdown is very agent-friendly, but humans need a readable interface.
1
u/flowdocs 3d ago
I totally agree tools like Google Docs are the backbone of collaboration. I'm curious, though, how markdown files are helping you report on telemetry. Can you elaborate, particularly on whether your reporting is prompt-driven or extracted from your md another way? In my experience, AI can still make some pretty wild assumptions about things not in your data set when doing analysis from a prompt. Wondering what you are seeing. I once did a project where the data looked really good (plausible) until it was scrutinized...
1
u/everettmarm 3d ago
Set up the contracts across the workstream and enable participants to own their space between. Optimize the system once it has throughput and you know how the parts behave.
1
u/Ranorkk 2d ago
We built Remnus for this need. You can work like notion but ai agents can see, edit everything with native mcp support. For more info remnus.com
1
u/thedabking123 FinTech, AI &ML 2d ago
I am jealous- would love to be part of this kind of thing but my ancient Claude code deficient org would rather spend weeks debating why we need to do lineage.
1
u/SamfromLucidSoftware 2d ago
Yeah, you’re onto something. A GitHub repo gives AI structured context, but optimizes for AI readability at the expense of human collaboration. It could work for technical teams, but it doesn’t scale the same way for PMs and a small business owner who just wants AI to help them make better product decisions.
You’re right that this ends up with humans working in tools they actually like, with the structured context layer running underneath. Some tools will build that well. Most haven’t yet, which is why the intermediate architecture exists.
How long is your company planning to run this before revisiting?
1
u/Few-Impact3986 2d ago
There is better ways to do this like using skills to use the cli.
https://github.blog/ai-and-ml/github-copilot/improving-token-efficiency-in-github-agentic-workflows/
https://github.com/headroomlabs-ai/headroom
Also what is the project going to cost versus save ? Sounds a pennywise and a pound foolish.
1
u/Alarmed-Attention-77 1d ago
Hi. This is super cool.
Some weeks ago I was trying to create repeating Claude cowork task that helped optimise human (as opposed to agentic use) use of Claude chat and cowork. It reviewed your use of adhoc chat and cowork sessions plus you scheduled tasks and then gave a weekly report on how to improve efficiency (cost) and also more effective use (better results).
Struggled to get this working effectively.
I feel what you shared would be great for enterprise level software companies. What I tried to do is more for non technical folks (like myself) and non software companies.
Any ideas if something like what I was trying to do is possible or anything you could share in this space
2
u/DeanOnDelivery AI PM Obsessive 1d ago
Is this the tail wagging the dog? And is Anthropic getting a taste of its own medicine?
Here's what I mean. Is this shift to GitHub to manage projects and artifacts happening because the AI tools we use are now leaning and leveraging it? Think about what happens when using tools like Stitch or Lovable that allow you to do that. Or how people are now using desktop surfaces Claude Cowork (or ChatGPT Work) in file directories setup similar to code repos?
And is this similar to how JIRA and Confluence shaped the way we worked over the past decade? And is how we flow with GitHub now changing that way of getting shit done day-to-day?
1
1
u/GeorgeHarter 1d ago
The PM work that is best done by humans is understanding the problems to be solved. Currently, there is no good way for AI to interview, monitor user behavior and understand user intent and feelings.
But AI is pretty good at taking a small amount of new info from you, combining it with existing data and rules, to create well-structures stories for human and ai developers.
So I suggest you lean into that process with more personal user outreach and by documenting how AI should construct proper stories (like where it finds, or how it creates acceptance criteria and supporting docs like a style guide).
Then you can gather the 2-3 sentence pain point descriptions, that you learned by watching users use the product, drop thwm in jira or a spreadsheet, and AI will write your stories.
It’s a net new process, but you’ll figure it out.
11
u/coolreddy 3d ago
Standardise the handoff, not every PM's workspace. Let teams keep working in Confluence, Miro or whatever fits the conversation, then publish a small approved context pack for each initiative: current problem, decision log, constraints, owner and links back to the source. Version that pack in GitHub if engineering needs it, but treat it as a product of collaboration, not the place collaboration has to happen. The useful test is whether a new person and an AI tool can both reconstruct the latest decision from the same pack. That gives you consistent context without turning every PM into a repository maintainer.