Productside Webinar

Beyond the Backlog

Five GitHub Plays for Product Teams

Date:

09/02/2026

Time EST:

1:00 pm
Watch Now

Your best thinking dies in three places: a Notion doc nobody reopens, a Slack thread nobody can find, and a slide deck that gets rebuilt from scratch every quarter. Meanwhile every AI tool you touch starts from zero, because nothing you know lives anywhere it can find it. 

GitHub isn’t Jira with a different logo. It’s not just where engineers go when something breaks. It’s durable memory for what your product team believes, decides, and ships, and it’s the context your AI tools have been missing. 

In this live, hands-on session, Dean Peters and Kenny Kranseler build five GitHub plays from scratch. On screen. In the wild. No net. No coding required. You’ll leave with a working repo, not notes about one. 

Your strategy doc gets rewritten every Monday. Your GitHub repo doesn’t have to. 

What You’ll Learn: 

  • Context. One versioned home for strategy, research, and decisions, built for your team and your AI to use.
  • Communications. A place to pressure-test ideas before they turn into expensive commitments.
  • Confidence. Assumptions, experiments, and evidence, all connected so one discovery informs the next.
  • Constitution. Guardrails GitHub enforces, so nobody has to become the process cop.
  • Community. A real front door for ideas and requests, with a visible record of what happened next.

Introduction and Housekeeping

Welcome and Audience Check-In

Dean Peters & Kenny Kranseler | 00:00:00 – 00:02:57

Good morning, good afternoon, or good evening. Good to see you all in our Beyond the Backlog webinar for today. Welcome. While we wait for everyone to find their way over to Zoom, please drop in the chat where you’re dialing in from.

We have New York, Pittsburgh, Colorado. We have someone from South Africa. Welcome, Nicole. Cape Town, yes. And we have Canada represented. There is more than one kind of London going on today, and we even have someone joining from Egypt. Welcome, Sah. Good to see you.

Ryan’s from Pittsburgh. I was actually in Pittsburgh last week. It is a nice time of year there. We’ve got a decent crowd and people are still streaming in. Go on, everyone, let us know where you’re from. We like a chatty webinar. It’s okay. We are from all over. Keep it coming.

Speaker Introductions

Dean Peters & Kenny Kranseler | 00:02:57 – 00:04:03

All right, for those of you who want to learn a little bit about GitHub, you’re in the right place. Dean, you want to introduce yourself?

Dean Peters | 00:02:57 – 00:03:25

Sure. I’m Dean Peters. I’m from Apex, North Carolina, just outside of Raleigh. I’ve been with Productside about four and a half years. Prior to that, I spent 20 years in product management and about 15 years in software engineering before that. I did a lot of work with AI, data, connectors, and APIs, so I’m coming in from the technical side. Kenny, over to you.

Kenny Kranseler | 00:03:25 – 00:04:03

And I’m Kenny Kranseler, also a consultant and trainer at Productside, one of Dean’s co-workers and co-conspirators in this endeavor. Unlike Dean, I came to product management from the marketing world. So he’s going to use me as that marketing-background person during this session to show that yes, even someone with no coding experience, except for one summer where I tried to learn COBOL and failed, can actually run GitHub and make sure that when working with AI, we can put things in the right place in the right environment.

About Productside

Kenny Kranseler | 00:04:03 – 00:05:24

Welcome. If you’ve been here before, good to see you again. If it’s your first time, we can’t wait to get to know you a little better.

At Productside, we truly believe that bad thinking kills more products than bad execution. The teams we meet are rarely short on effort or speed. They’re short on the thinking that happens before the work starts, thinking that really should answer questions like:

  • Who is this for?
  • What kind of problems does it solve?
  • Does it deserve to exist at all?

AI has made every product team faster. It has not made a single one righter. That belief is the reason we exist. We have spent nearly 25 years teaching product people how to make decisions that survive the rooms they are not in, and how to measure the outcomes that result. Our training, assessments, and advisory services all serve that one core concept: your outcomes are what matter most.

Housekeeping and Staying Connected

Kenny Kranseler | 00:05:24 – 00:07:12

Before we dive in, a few quick housekeeping notes:

  • Can I watch this later? Yes. Everyone who attends will get a recording link in their inbox shortly after we wrap up
  • Drop questions in the Q&A as they come to you. Do not sit on them until the end. I will be monitoring, and we like addressing things as we go
  • The chat is also open. Compare notes, swap war stories, tell someone their AI rollout sounds painfully familiar. You will get as much from the room as from Dean and me
  • Connect with us on LinkedIn. We post the leadership stuff worth stealing, AI tips and tricks, and the ongoing argument about what makes product management work. Scan the QR code or hit the link in chat

We want this to be more of a conversation between friends than a one-way presentation. Definitely interrupt us with questions, and definitely connect with us. We are here to be your partners in product, and this is your invitation to the party.

Collaboration Pain Points and the Solution

Setting Up the Mural and Repository Access

Dean Peters | 00:07:12 – 00:09:01

Without further ado, let’s get into it. You’ll notice I’m not using PowerPoint today. I’m using Mural to share the agenda and the flow. I’m dropping the link to the Mural board in chat. You do not need to create an account. Just click the link and enter as a visitor when it prompts you. Feel free to follow along on your own screen.

We’re also sharing a GitHub repository we created specifically for this session, focused on market intelligence. When you load it up, it will appear as part of the Productside repository presence on GitHub. We built this repository together, Dean standing it up technically and Kenny critiquing it by walking through the steps as we go. That is the game plan.

Here are the links you need:

  • The Mural board link, in chat now
  • The market intelligence GitHub repository link, also in chat

If you want to follow along and build with us, this is your moment to get set up.

Collaborative Bottlenecks and Dysfunctions

Dean Peters & Kenny Kranseler | 00:09:01 – 00:11:46

The first thing Kenny and I want to talk about is collaborative bottlenecks. How many times has one of these happened to you?

The three dysfunctions:

  • Versioning hell: The “final-final-REAL-v6.2.4” naming spiral in SharePoint. History exists in theory, but in practice nobody trusts it. The moment someone saves a new version, the last one becomes unreliable.
  • Context scavenger hunt: A little bit in SharePoint, a little in Jira, a little in Slack, a little in Confluence. Nobody can find what they need, and nobody agrees on which version is current.
  • Individual or siloed realities: Teams working from separate chat threads, separate documents, separate interpretations of the same work. Lots of effort, no shared understanding.

These three dysfunctions compound into five specific pains for product teams:

  • Copying context everywhere: Every handoff means copy-pasting the same background into a new doc or a new session
  • Relitigating past decisions: A decision gets made, gets written down, and then three weeks later someone who was not in the room relitigates it because they could not find the record
  • Redoing discovery: Research that already happened gets run again because nobody could find the original and nobody trusted it enough to build on
  • Rules nobody remembers: Process docs that people forget exist. Guidelines that get broken not out of malice, but because nobody can remember them when it counts
  • Losing ideas that never got explored: Good ideas that died in someone’s inbox or a Slack thread that scrolled off the screen before anyone had a chance to evaluate them

Wouldn’t it be nice if we had a system that solved all five of those? That is what a well-structured GitHub repository can be for a product team. And that is what we are building today.

Poll: Identifying Top Collaboration Pains

Dean Peters & Kenny Kranseler | 00:11:46 – 00:13:12

Before we get into the solution, we want to hear from you. Which of these five pains hits hardest in your organization right now?

  • Copying the same context everywhere
  • Relitigating past decisions
  • Redoing discovery
  • Rules nobody remembers or follows
  • Losing ideas that never got explored

There is no wrong answer. The only wrong answer is not to play.

Results: copying context everywhere and keeping everybody on the same page came out on top. Losing ideas that never got explored was a surprising third. Relitigating decisions was a close fourth.

Relitigating decisions is the one that jumps out at me. Everybody goes their own way, we make a decision, and then we revisit it for the eighth time because someone found a new angle and had no way to connect it back to what was already decided. That is the whole problem in one sentence. And that is what GitHub’s version history and pull request records solve at a very granular level.

Understanding Git vs. GitHub and Initial Setup

Dean Peters | 00:13:12 – 00:16:24

Before we build, let’s get one distinction clear: Git and GitHub are two different tools that work together.

  • Git is the engine. It is a version control system that tracks every change, preserves the full history, and makes it possible for multiple people to work on the same material at the same time without colliding. It runs underneath the hood of everything we are doing today.
  • GitHub is the car. It is the shared platform where the repository lives, where reviews happen, and where the team can see what changed and why at any point in time.

The good news: you do not need to become an expert in either. You do not need to learn command-line Git to make this useful.

Here is Play Card 1. If you have not installed Git and set up GitHub access on your machine, you can use any coding agent to do it in plain English. Tools that work:

Just say: “Check whether I have Git or GitHub already installed on my device. If anything is missing, install it.”

Kenny ran this on Windows. The agent installed a package manager called winget first, then used that to install Git and GitHub. On a Mac, it would use Homebrew instead. These package managers are not just for Git. They are general-purpose tools for installing any software you need, and they give you more control over your installs. Windows also has one called Chocolatey if you prefer that.

The point: you asked in plain English, and it set everything up. You do not have to become a programmer to get started.

Practical Application: Versioning and Market Intelligence

Use Cases: Comparing Git Workflows to Traditional Tools

Dean Peters & Kenny Kranseler | 00:16:24 – 00:20:21

Now let’s talk about the problems we are actually solving, and why GitHub handles them better than the tools most product teams already have.

The three problems Play 1 addresses:

  • Sharing safely, with version control so every change is preserved and you can see exactly what happened and when
  • Working simultaneously without bumping into each other, even on the same document or the same skill
  • Creating an environment that AI coding tools understand and can work from, pulling context across multiple files without you having to point them at each one

How does GitHub compare to the tools you already use?

SharePoint: Great for file storage. Not good enough for version reviews at a granular level. History exists, but it is not reliable at the line level, and the annual “great purge-nation” of working directories never quite solves the naming problem. You end up with “final-REAL-August-26” and a dozen versions that all look equally authoritative.

Confluence or ADO Wiki: Good for shared documents. Confluence will get you line-level history in some cases, but it does not let you run safe parallel experiments the way Git does. And if you are in an Atlassian environment, you are also managing tool licensing complexity that goes with it.

Claude Projects or similar: A great place to start and build context for a specific conversation or project. But once something grows in complexity, you want to share it, govern it, and bring more people in across and outside the organization. At that point, you have outgrown it.

GitHub repositories: Give every coding agent a bird’s-eye view of all files in a directory: documents, examples, prompts, references, and skills. When you ask Claude Code or Codex to do something, it does not need you to point it at each file. It reads the whole directory, finds the context it needs dynamically, and works from there. That is what separates a useful AI interaction from one that starts from zero every session.

Setting Up the Market Intelligence Repository

Dean Peters & Kenny Kranseler | 00:20:21 – 00:23:53

Here is the repository we built for today’s session: a market intelligence repository under the Productside GitHub presence. We created it specifically as a shared platform that attendees can clone, use, and build from after this session.

Two key terms before we go further:

  • Clone: Copy a repository to your local machine so you can contribute to it or work within its structure. You stay connected to the original.
  • Fork: Take a repository and derive an entirely different direction from it. Not a pivot inside the existing project, but a full move into new territory.

The market intelligence repository was itself forked from two earlier repositories Dean had already built: one on AI skills for product managers and one on prompts for product managers. That is how you build on what already exists instead of starting from scratch.

Practical setup recommendation for your machine:

  • On Windows: create a root-level folder called projects, sitting at the same level as Documents and Media
  • On Mac: do the same in your home directory, alongside your existing folders
  • Then everything you do with repositories and coding agents lives inside that organized structure
  • If you are working with Productside content, create a subfolder called productside inside projects and keep all related repositories there

Once you have cloned the market intelligence repository to your local machine, you have a full local copy. The coding agent can see all the files, all the skills, all the examples, and work from them without you managing dependencies manually.

Generating Context in AI Coding Agents

Dean Peters & Kenny Kranseler | 00:23:53 – 00:26:20

Here is the first prompt Kenny ran when he started a new session in Claude Code with the market intelligence repository loaded:

“Read the repository. Tell me what skills are available, what frameworks they use, and what rules I should follow. Then recommend which skills we should install to help us build a battle card comparing two large enterprise CRM products.”

This matters because every new coding agent session starts without context. Asking it to read the repository first creates that context. Here is what happens underneath the hood:

  • Claude Code reads claude.md by default to get its bearings
  • Tools like Codex and Gemini’s agentic tool read agents.md
  • Dean’s repositories also include a constitution.md, a file with explicit rules about what to do and what not to do
  • The agent then scans the entire directory tree: documents, examples, prompts, references, and skills

After reading the repository, the agent builds a picture of what is available, what the constraints are, and what it should prioritize. All of this happens without you typing a single line of code.

The constitution file is worth pausing on. Dean includes this in all his repositories. It contains rules such as:

  • Do not expose customer names
  • Do not share documents that belong in SharePoint
  • Do not include anything that looks like a credential or secret
  • Do not create oversized documents

Those rules get picked up automatically every time the agent reads the repo. Governance is built into the repository itself, not enforced by a human each time.

Executing Skills for Battle Card Generation

Dean Peters & Kenny Kranseler | 00:26:20 – 00:28:51

Once the agent has context, you can run skills against it. The prompt Kenny used:

“My product is Microsoft Dynamics CRM. My competitor is Salesforce. Focus on enterprise deals. Recommend the market intelligence skills and run them.”

Here is what the agent did:

  • Recommended six skills to run based on the repository content
  • Laid out a step-by-step execution plan before starting
  • Ran a full market intelligence sweep on both Microsoft Dynamics and Salesforce
  • Generated a battle card comparing the two

Total time: approximately 25 to 30 minutes end to end. Kenny did not type a single line of code.

What made this possible was not the prompting. It was the structured repository. The agent found all six skills, all the examples, all the reference documents, and all the prompts on its own because everything was in one organized directory. That is context engineering in practice: doing the structural work upfront so the AI does not have to start from zero every time.

The agent also provides a clear plan before it acts. Step one, I will do this. Step two, I will run a sweep. Step three, I will generate the output. You get to see the plan, confirm it, and then watch it execute. You are in control without being in the code.

Iterative Review, Branching, and Pull Requests

Understanding Branching and Work Trees

Dean Peters & Kenny Kranseler | 00:28:51 – 00:32:35

Kenny looked at the first battle card that came out of the skills run and had observations. The output was accurate, but not seller-ready. It read like an intelligence brief, not a field tool a sales rep could walk into a meeting with.

This is where branching comes in. A branch is a private copy of the work. It lets you experiment with changes without touching the main codebase. A work tree is where that work actually happens on your local machine.

Here is why this matters for product teams: Dean could be working on the battle card. Kenny could be working on the battle card. Tom could be trying a completely different approach. All three can work simultaneously on the same repository without stepping on each other:

  • Dean’s experiment: trying approach A
  • Kenny’s experiment: “that first version didn’t hit the mark, let me try something else”
  • Tom’s experiment: “I’ve got a few more things I want to try before I’m ready to propose anything”

None of those experiments interfere with each other until someone is ready to propose their changes for review through a pull request.

Kenny’s specific feedback on the original battle card, typed into Claude Code in plain English:

  • Too narrow in scope for enterprise deals
  • Too polite in framing, not direct enough for a sales conversation
  • No clear if-then logic for salespeople to follow in the field
  • Did not highlight CRM-specific strengths against Salesforce
  • Not one-page and field-ready as a practical tool

He typed those observations in. The agent created a plan, updated the skill file, and produced a new version. Kenny did not write a single line of code. Claude Code wrote the changes on his behalf based on the feedback he provided.

Capturing Feedback and Committing Changes

Dean Peters & Kenny Kranseler | 00:32:35 – 00:34:36

Once Kenny was happy with the revised battle card, the next step was to commit and push his changes.

Three steps in sequence:

  • Branch: Create a private copy of the repository to experiment in. Kenny’s branch was named after the specific change he was making.
  • Commit: Take a snapshot of the current state of your changes and save it locally. This captures the work at that point in time with a note about what changed and why.
  • Push: Move that snapshot up to GitHub so others can see it, review it, and decide whether to merge it into the main codebase.

What GitHub shows you after a push: every file that changed, and every line within those files. The additions appear in blue, the removals appear in red or orange. This is the change history at the line level, automatically generated even though Kenny did not write any of the code by hand. Claude Code generated it based on his observations.

And if you are unsure what changed or why at any point, you can simply ask: “Show me exactly what changed line by line. Explain why.” The agent can walk you through the diff in plain English. You do not need to understand the code to understand the change.

The Pull Request Process Explained

Dean Peters | 00:34:36 – 00:37:16

A pull request is a formal proposal to merge your branch changes into the main codebase. The name is slightly counterintuitive: the person maintaining the repository is being asked to pull the changes in. That is where the term comes from.

When Kenny submitted his pull request with the updated battle card, here is what Dean sees on his end:

  • Every file that was changed
  • Every line that was added or removed, with color coding
  • The commit history showing when each snapshot was taken and what the author noted

Dean then has three options:

  • Accept the changes and merge them into the main repository
  • Request revisions before merging, with a message explaining what needs to change
  • Decline the changes with an explanation

A real example from Dean’s public product manager prompts repository, which has been live since 2024: a contributor submitted a pull request proposing to add a monthly progress report prompt. On review, it was not really a product manager prompt. It was a general monthly facilitation tool that had drifted from the repository’s scope.

Dean sent a message to the contributor explaining why it was being declined and what the repository was specifically for. That is governance in action: no meeting, no policy doc that nobody reads, no one person having to police every contribution. The process creates a visible record of the decision, the reasoning, and the outcome.

Live Workflow Demonstration and Enterprise Governance

Reviewing Branch Changes in GitHub

Dean Peters & Kenny Kranseler | 00:37:16 – 00:40:10

Let’s look at Kenny’s pull request in the market intelligence repository as it actually came through.

In the GitHub interface, the branch Kenny submitted shows as “seller-friendly battle card” with a timestamp. Clicking into it shows the specific skill file that was updated: build-battle-card. The diff view shows the original version in red and Kenny’s updated version in blue.

Here is what the original version looked like: a broad, thorough competitive analysis. Accurate. Comprehensive. And, as Kenny noted, not something a salesperson could pick up and use in a meeting without reading a dissertation first.

Here is what Kenny’s updated version added:

  • A one-page, field-ready layout
  • Ranked weaknesses with direct competitive positioning language
  • If-then conversational paths for live sales situations
  • Explicit CRM-specific differentiation against Salesforce

All of that shows up in the diff automatically. Dean can review it, approve it, request changes, or decline it with a note. And the record of that conversation stays attached to the pull request permanently. Six months from now, anyone can go back and see what was proposed, what was reviewed, and what was decided.

That is the version history that relitigation-proofing looks like in practice.

Walkthrough: Refining Battle Cards with Claude Code

Dean Peters & Kenny Kranseler | 00:40:10 – 00:42:54

Let’s walk through what Kenny’s session in Claude Code actually looked like from the top, because this is the full workflow any product manager can replicate.

Step 1: Make sure the local clone of the market intelligence repository is up to date.
Step 2: Ask the agent to create a branch for this specific piece of work.
Step 3: Share observations about what needed to change in the battle card, in plain English, not in code.
Step 4: Let the agent generate a plan and execute it.
Step 5: Review the output.
Step 6: Commit and push.

The key moment was when Kenny reviewed the new battle card file the agent had created. He expanded it in the terminal to see the full output. The original version: comprehensive but not field-ready. The new version: tighter, more direct, structured for a sales conversation. That gap is what the branch and the pull request captured.

And here is the part that is easy to miss: when Dean reviews the pull request, he is not just reviewing the battle card. He is reviewing the updated skill file that generates battle cards. Every future battle card produced by this repository will now reflect Kenny’s improvements. One review, compounding value.

That is the difference between fixing a document and fixing the system that generates documents.

Applying Modular Workflows to PRDs and Deliverables

Dean Peters & Kenny Kranseler | 00:42:54 – 00:45:23

The same workflow Kenny ran for the battle card applies to any complex product deliverable. PRDs. Go-to-market plans. Competitive strategy documents. Research synthesis.

Here is why the modular approach works better than a single large document:

When a PRD lives as one massive file, it creates a bottleneck. One person edits it at a time. Nobody else can touch it without coordination. Changes are hard to trace. And when you want AI to work on one section, you have to manually copy context from all the other sections first.

When a PRD lives as multiple files in a GitHub repository, each section in its own document, the whole picture changes:

  • Different team members can work on different sections simultaneously without stepping on each other
  • The AI coding agent sees the entire directory and finds the dependencies on its own, without you pointing them out
  • Every section has its own version history, so you can see what changed in the market analysis independently of what changed in the user stories
  • Pull requests let the right people review the right sections before anything gets merged into the main document

In SharePoint or Confluence, asking Copilot or another AI to work on one section means it may wander into other directories or lose track of what it was doing. In a GitHub repository with a clear structure, the agent stays narrowly focused on the relevant files and builds from what is already there. You get all the knowledge, not just the section you asked about.

Reusability, Community Repos, and GitHub Projects

Dean Peters | 00:45:23 – 00:48:55

Once a skill or a process works, you do not rebuild it. You invoke it. That is where GitHub starts to compound value across your team and across time.

Skill reuse: The battle card skill Kenny refined is now part of the market intelligence repository. Any team member who loads that repository can say “run the battle card skill for product X versus product Y” and get a field-ready output without needing to know how the skill was built.

Document reuse: Any complex document, a PRD, a go-to-market plan, a research synthesis, can live as a set of structured files in the repository. Team members work on different sections simultaneously. The AI sees the whole thing without anyone having to manage dependencies manually.

Community reuse: Public repositories let you build on what the broader product community has already created. Examples worth knowing:

  • Dean maintains a public product manager prompts repository that has been live since 2024, with contributors submitting pull requests of new prompts for review
  • Lenny Rachitsky made his podcast transcripts publicly available and people built AI retrieval systems on top of them
  • Dean forked Microsoft’s Tiny Troupe repository to build a synthetic persona tool from Productside’s survey data
  • There are public repositories specifically for learning eval skills, vibe coding, and AI skill development in product management

To find Dean’s public repositories: search for “Dean Peters product manager skills” or “Dean Peters product manager prompts” on GitHub. They are open and reusable.

GitHub Projects: Inside any repository, the Projects feature lets you track open items, add issues, gather requests, and manage a visible backlog of contributions. Dean has been running a project in one of his repos since 2016, which he and Shannon Bal started together when she was VP of Product at Pendo: a living set of interview questions for product managers, organized by role level and updated as the field evolves.

Automated Governance and Security Actions

Dean Peters | 00:48:55 – 00:52:04

Governance through GitHub Actions is one of the most powerful things a product team can set up, and it requires no ongoing enforcement by a person.

Actions are YAML-based workflows that run automatically whenever someone commits or pushes to the repository. Dean had Claude Code generate the Actions in the market intelligence repository. They check for:

  • Customer names that should not be exposed in a shared repository
  • Secrets or credentials that could create a security risk
  • Documents that belong in SharePoint or a secured internal system rather than a public or shared repository
  • Oversized files that should not be committed
  • Anything that looks like a malicious payload or injection

These checks run automatically in the background the moment a push happens. Nobody has to review every commit manually. Nobody has to remind contributors of the rules. The guardrails are built into the repository itself.

A real and recent example: a team that wanted to publish an MCP connector with Claude accidentally exposed their entire codebase through the integration because nobody had governance in place. Security is not hypothetical. It is a very live concern for product teams working with AI tools today.

More broadly: AI tools including advanced models have been finding bugs in production software, bugs that have been deployed for years without anyone knowing they were there. The technical risk conversation has moved from hypothetical to very real. GitHub Actions give you a lightweight, automated way to put a guardrail in place before something goes sideways.

Two important prerequisites:

  • Talk to your legal team or COO before setting up any GitHub repository. Licensing, vocabulary, publishing rules, ownership, and contracts all need to be in alignment.
  • Any public or shared library you pull in through the marketplace or community needs your own security review. You can ask Claude Code or Codex to write a script that checks a repository against known risk patterns. That is exactly how some of the governance Actions in this repository were built.

And the practical summary of when to use GitHub versus your other tools:

  • Keep using Jira, Notion, Slack, and Confluence for what they do well
  • Use GitHub when you need to see what changed and why at a granular level
  • Use GitHub when you need dense context made up of multiple files that AI can read as a whole
  • Use GitHub when reviews and peer handoffs are critical
  • Use GitHub when you want to bring AI into the room across an entire group of files, not just one
  • Use GitHub where change needs a memory

The result: a shared context your team actually works from, decisions that are faster and captured, handoffs that are more seamless, and AI tools that are not starting from zero every session.

Conclusion, Key Takeaways, and Q&A

Poll: Adoption and Key Takeaways

Dean Peters & Kenny Kranseler | 00:52:04 – 00:53:34

Starting today, what is the one thing you will do differently, with or without GitHub?

  • Track why decisions were made
  • Stop rebuilding context from scratch every session
  • Run parallel experiments safely
  • Build a structured front door for ideas and requests
  • Give AI tools a structured place to work from

Results: tracking why decisions were made came out clearly on top. Not a surprise. You are not going to get that out of SharePoint. You might get it out of Confluence in limited form. But for a dense set of files with granular, line-level history and a visible record of every decision and why it was made, GitHub is where that lives.

Productside Offers and Upcoming Events

Kenny Kranseler | 00:53:34 – 00:56:53

For being an attendee today, here are resources available to you right now:

  • Strategic Planning for PMs Playbook: Scan the QR code on screen or click the link in chat. A downloadable pack of tools and frameworks to help you think more strategically about your product work
  • State of AI for Product Management Report: Productside’s research on how product organizations are adopting AI, where the gaps are, and what the most mature teams are doing differently. Link in chat. A webinar recording on this report is also available at productside.com
  • Product Management Certification Outcomes Study: Research on what happens to salaries and career trajectories after certification. The results are worth reading. Link in chat

Upcoming courses and events:

Q&A and Wrap-Up

Kenny Kranseler & Dean Peters | 00:56:53 – 01:00:46

Question:
A lot of my stakeholders never open GitHub. Does anything we showed today help with people who are not going to use the tool directly?

Dean Peters:
A few practical options. You could use a shared OneDrive directory as a local stand-in for some scenarios, though that creates its own version control problems. The more useful answer is notifications. In a GitHub repository, stakeholders can watch the repository at different levels and get notified by email whenever something changes. They do not need to run it locally. They click the link in the notification, see what changed, and decide whether to look more closely. You can tune the notification level so they only hear about things that are relevant to them, not every commit. You make it low-friction for the people who need visibility without needing control.

Question:
The skills sweep generated a lot of content quickly. How do I know which of it I can trust, and how often should I re-run it?

Dean Peters:
All libraries need your own verification. Do not assume that because a repository is popular or well-maintained it is safe to run without checking. You want to check for prompt injections and malicious code. There are tools specifically designed to evaluate repository safety. You can also ask Claude Code or Codex to write a script that interrogates a repository against a list of known risk patterns. That is actually how some of the governance Actions in today’s repository were built. The rule: verify before you trust, especially before anything touches customer data or production systems.

Question:
Can I use this just to explore and learn without committing to any permanent changes?

Dean Peters:
Absolutely. You can clone the market intelligence repository and run the skills without committing anything. Open a new session in Claude Code, load the repository, and say “give me a battle card for my product versus this competitor using the skills in this repo.” It runs, you get a result, nothing is saved, nothing is pushed. You burn some tokens, but nothing changes in the repository. You do not have to commit or push until you decide something is worth keeping. The repository is just context for the session.

Kenny Kranseler | 01:00:10 – 01:00:46

Thank you so much, everyone. We have hit the top of the hour. I hope you found this valuable. If a feedback form pops up, please fill it out. It really does help us build better sessions. And be sure to come back in about two weeks for Roadmap Rage, where we will tackle what to actually say when a stakeholder points at “later” on your roadmap and demands a date. Have a great day, folks. Thanks so much.

Webinar Panelists

Dean Peters

Known for building AI products decades before they were cool. Learn from Dean’s obsession with product and passion for AI.
LinkedIn

Kenny Kranseler

Kenny has led product teams from KFC to Amazon to Seattle-based startups. He has the range and strategic insight to differentiate what works from what doesn’t.
LinkedIn

Webinar Q&A

Yes. Product managers can use GitHub without writing a single line of code. Productside’s Dean Peters and Kenny Kranseler demonstrate this directly in their live session: Kenny, who comes from a marketing background with no coding experience, used plain English instructions inside a coding agent to install Git, clone a repository, create a branch, update a skill file, and submit a pull request for review. The key insight is that AI coding tools like Claude Code and Codex handle the technical execution; the product manager simply describes what they want in natural language. GitHub for product managers is not about becoming a programmer. It is about having one versioned, structured home for strategy, research, decisions, and context that the whole team and AI tools can reliably work from.
GitHub solves three collaboration dysfunctions that slow most product teams down: versioning chaos (the “final-final-REAL-v6.2.4” naming spiral in SharePoint), context scavenger hunts where strategy lives in Confluence, decisions in Slack, and research in Notion with nobody finding anything, and individual realities where the same team works in parallel but never from the same shared understanding. GitHub gives product teams a single repository where every file, decision, experiment, and reference lives together with full version history. Pull requests create a formal review process for changes, branches allow parallel experimentation without collisions, and GitHub Actions can enforce governance rules automatically, without requiring a meeting or a policy document that nobody reads.
GitHub creates persistent, structured context that AI tools like Claude Code and Codex can read across an entire repository at the start of every session, rather than starting from zero each time. When a product manager opens a new AI session and says “read the repository,” the agent reads the README, scans the full directory of documents, prompts, skills, and references, and builds a complete picture of what is available and what rules to follow. In Productside’s live demo, this setup allowed a competitive intelligence skill to run a full market sweep on Microsoft Dynamics versus Salesforce and produce a seller-ready battle card in 25 to 30 minutes, without the product manager writing any code. A constitution file in the repository can add governance guardrails: rules about not exposing customer names, not sharing credentials, and not including documents that belong in other systems.
Branching in GitHub lets product team members each work on their own private copy of a file or skill simultaneously, without interfering with each other or with the main repository. In the context of product discovery and experimentation, this means a product manager can test a new approach to a battle card, a research framework, or a decision template while a colleague tests a different approach, and both experiments remain separate until one is ready for review. In Productside’s session, Kenny used a branch to rewrite a competitive battle card from an intelligence brief format into a seller-ready field tool, describing his observations in plain English to Claude Code, which rewrote the skill file on his behalf. GitHub then showed every line that changed in color, creating a transparent, traceable record of exactly what was updated and why.
Productside’s five GitHub plays for product teams each address a specific collaboration or workflow breakdown. Play 1, Context, creates one versioned repository for strategy, research, and decisions that both the team and AI tools can reliably work from. Play 2, Communications, teaches product managers to start every AI session by having the agent read the full repository so it builds context instead of starting from scratch. Play 3, Confidence, uses branching to run parallel experiments safely, so multiple team members can test different approaches without stepping on each other. Play 4, Constitution, uses pull requests and GitHub Actions to build governance directly into the repository, reviewing and enforcing rules automatically rather than relying on a policy document nobody remembers. Play 5, Community, focuses on reuse: invoking existing skills, sharing structured libraries across teams, and contributing to or learning from public repositories, so the team compounds its work instead of rebuilding from zero every time.