GitHub Copilot for Product Managers: 5 Shifts Changing Product Development

The Jira ticket is marked done. Engineering has merged the pull request. QA has passed. Then the product manager opens the feature and discovers that it solves a different problem from the one the customer described. Where did the intent get lost?

Often, nowhere dramatic. It faded across a series of perfectly reasonable handoffs: discovery notes, a PRD, designs, Confluence decisions, Jira stories and implementation.

GitHub Copilot offers a way to make those handoffs more connected. Not by turning product managers into production engineers, but by helping them prototype, assemble context, explore implementation and check whether delivery still reflects the original customer need.

This article follows one example, an anonymised peer-benchmarking feature for an analytics platform, through five changes in product practice. It distinguishes what Copilot can help with today from workflows that depend on integrations, permissions and human review.

Cover illustration: the journey from customer problem to product outcomes.

How Product Development Traditionally Works

Consider a fairly typical product development process.

A customer problem or business opportunity is identified. The product manager investigates it, speaks with customers and stakeholders, and develops a possible solution.

Requirements are written. Design creates wireframes or prototypes. The work is documented in Confluence. An epic is created in Jira. The epic is broken into stories. Product and engineering hold refinement sessions. Engineers interpret the requirements and start building. Developers create pull requests. QA tests the implementation. The product manager eventually sees the finished feature during a demo or user acceptance testing. Finally, the feature reaches production.

Customer Problem → Discovery → Requirements → Design → Confluence → Jira → Refinement → Engineering → Pull Requests → Testing → UAT → Release

There is nothing inherently wrong with this model. But there is an important weakness.

Every arrow represents a translation.

The customer problem is translated into product requirements. Requirements are translated into designs. Product decisions are translated into documentation. Documentation is translated into Jira stories. Jira stories are interpreted by engineers. Engineers translate those requirements into code. The product manager eventually translates the resulting software back against the original requirements to determine whether the right thing was built.

Every translation creates an opportunity for information to disappear.

A ten-page product discussion might become a three-paragraph Jira ticket. An important design decision might be buried in a Confluence page. A customer constraint mentioned during discovery might never reach the engineer implementing the feature. An engineer may correctly implement the Jira story while still missing some of the original product intent.

This is fundamentally a context problem. And this is where GitHub Copilot becomes much more interesting for product managers.

Traditional versus connected delivery: each handoff is a chance to preserve or lose intent.

Copilot Is Not Just a Coding Tool

The obvious use case for GitHub Copilot is helping developers write software. But consider the wider product development lifecycle:

Discover → Define → Prototype → Build → Validate → Release → Learn

Software development is only one part of that process. AI can increasingly operate across several of these stages.

For a product manager, the important question therefore becomes:

What happens when I can move much further from an idea towards something executable before consuming significant engineering capacity?

That creates five important shifts in how product managers can work.

The five shifts: prototype, engineer context, collaborate on execution, connect knowledge and validate intent.

1. From Describing Products to Prototyping Them

Running example: a customer wants to compare its performance with a peer group. Before asking engineering to estimate the work, a PM can prototype filters, comparison charts, explanatory tooltips and a no-data state using synthetic data. Stakeholders can now react to behaviour, not just a sentence in a PRD.

Product managers spend a lot of time communicating ideas. We write requirements. We draw diagrams. We create wireframes. We prepare presentations. We explain the same concept repeatedly to stakeholders, designers and engineers.

Generative AI gives us another option: build something that demonstrates the idea.

GitHub Copilot can help a technically curious product manager create simple applications, dashboards, data visualisations, mock APIs and interactive product experiences.

The objective is not to create production software. The objective is to reduce ambiguity.

Imagine that you want to introduce a new analytics dashboard. A traditional requirement might say:

Users should be able to compare performance across different providers and time periods.

That sounds clear. But many questions remain. How does the user select providers? Can they select multiple providers? What happens when there is no data? What does the default view show? How does the chart respond when the date range changes? Does the selection remain when the user moves between screens?

A working prototype forces these questions to be answered.

Think About Prototypes in Four Levels

A useful approach is to think about AI-assisted prototypes across four levels.

• Level 1: Concept. Demonstrate the basic interface and product idea.

• Level 2: Interaction. Buttons, navigation, filters and workflows function.

• Level 3: Data. The prototype uses representative or synthetic data to demonstrate realistic behaviour.

• Level 4: Technical Spike. The prototype connects to a real API, database, model or service to test whether an idea is technically feasible.

Product managers do not need to reach Level 4 for every feature. In many situations, a Level 2 or Level 3 prototype is enough to transform the quality of a conversation with engineering.

This demonstrates the workflow I am proposing. Let's discuss whether it is the right experience and how we should implement it properly.

The PM is not replacing the engineer. The PM is making product intent more tangible.

2. From Prompt Engineering to Context Engineering

For the peer-benchmarking feature, context includes the definition of each metric, which customers can see which cohorts, minimum group sizes, suppression rules, entitlement boundaries and the meaning of a comparable peer. Without these constraints, a plausible prototype could also be misleading or unsafe.

Prototyping is the most visible opportunity. Context management may be the more important one.

AI systems can be extremely capable and still produce poor results when they lack the right context.

Imagine asking Copilot: How should we build a customer analytics dashboard? You will probably receive a reasonable answer. But it will also be generic.

Now imagine asking: Based on our existing analytics architecture, customer requirements, API standards and product metrics, identify the minimum changes required to introduce customer-level benchmarking.

That is a completely different task. The difference is not necessarily a better model. It is better context.

Product Context Is Everywhere

The challenge for most product organisations is that context is fragmented.

• The product strategy might be in Confluence.

• Requirements are in Jira.

• Designs are in Figma.

• Architecture documentation lives somewhere else.

• Customer feedback may be in a CRM.

• Product metrics are in analytics platforms.

• Code lives in GitHub.

• Important decisions may exist only in someone's memory.

Humans struggle with this fragmentation. AI agents will struggle with it too.

This introduces an important capability for product managers: context engineering.

Prompt engineering asks: What instruction should I give the AI? Context engineering asks: What does the AI need to know to make a good decision?

For product managers, that second question is far more interesting.

GitHub documents repository custom instructions, Copilot Spaces and agent instructions as distinct ways to supply context. Their availability and behaviour vary by product surface, plan and configuration. The relevant official guidance is linked at the end of this article.

/product
    product-vision.md
    personas.md
    terminology.md
    metrics.md

/product/features
    requirements.md

/architecture
    system-overview.md
    api-contracts.md

/decisions
    product-decisions.md

/.github
    copilot-instructions.md

The repository now contains more than code. It contains information explaining what the product is, why it behaves the way it does and what constraints should be respected when changing it.

The repository starts becoming a machine-readable representation of the product.

3. From Product Handoff to Shared Execution

The same benchmarking example now becomes an engineering conversation: which API provides aggregated statistics, where are entitlements enforced, and what happens when a cohort is too small? Copilot may help locate relevant code and formulate questions, but engineers and privacy specialists must approve the design.

The traditional relationship between product and engineering contains a natural handoff. Product defines what needs to be built. Engineering determines how to build it. That separation remains valuable.

But AI can make the boundary between the two much richer.

Consider a new requirement:

Allow customers to compare their performance against an anonymised peer group.

Traditionally, a PM might create an epic, write requirements, work with design and bring the feature into refinement.

Now imagine that before refinement the PM uses Copilot to investigate the existing product.

• Which existing components appear relevant to peer benchmarking?

• What parts of the data model would potentially be affected?

• Which APIs currently expose similar analytics?

• Identify potential privacy, entitlement and anonymisation considerations.

• What product decisions remain unresolved before engineering could implement this?

Copilot can help the PM explore the existing system before the first refinement conversation takes place.

Once the direction is agreed, AI can also help transform that intent into acceptance criteria, edge cases, dependencies, implementation questions, test scenarios and engineering-ready stories.

The result is not simply a better Jira ticket. It is a better product-to-engineering conversation.

Product intent → Shared context → Prototype → Technical exploration → Engineering plan → Implementation

The goal is not to automate the handoff. It is to reduce how much information gets lost during it.

4. From Tool Silos to Connected Context with MCP

In this example, a properly configured integration could retrieve a Jira story describing benchmark filters and a Confluence decision specifying cohort privacy thresholds. That does not happen automatically: the relevant MCP servers or connectors must be available, authenticated, authorised and supported by the Copilot environment in use.

There is still an obvious problem. GitHub does not contain all the information needed to understand a product.

A typical organisation might have Jira for delivery and requirements, Confluence for documentation and decisions, GitHub for implementation, Figma for design, and other systems for customer feedback, analytics, incidents or operational information.

For an AI agent to understand the complete product context, it needs a way to interact with those systems.

This is where the Model Context Protocol, or MCP, becomes important.

The Model Context Protocol (MCP) defines a way for compatible AI applications to connect to external tools and context sources. It does not itself guarantee a working Jira or Confluence integration, access permissions or accurate results.

For product managers, the important part is not the protocol itself. It is what becomes possible when the development environment can retrieve product context from outside the codebase.

Imagine Copilot being able to work across GitHub, Jira and Confluence.

MCP can connect approved external context to an AI workflow, subject to configuration and permissions.

Review the implementation of PRODUCT-2187 against its Jira acceptance criteria and the architecture decision documented in Confluence.

There are three different types of context here.

• Jira provides intent. What are we supposed to build?

• Confluence provides organisational context. What decisions and constraints should we respect?

• GitHub provides implementation. What did we actually build?

Bringing these together creates something much more interesting than an AI coding assistant. It creates the foundations for requirements-aware engineering agents.

Confluence Becomes More Valuable, Not Less

This could also change the value of documentation. Most organisations know the pattern: Meeting → Decision → Confluence page → Forgotten.

Six months later, somebody asks: Why did we decide to build it this way? Nobody remembers.

With AI retrieval, historical product documentation becomes useful operational context again.

• Find previous decisions concerning customer data retention before we design this feature.

• Have we considered this approach before?

• Does this proposed implementation contradict any existing architecture decisions?

Documentation stops being something we hope people will read. It becomes context that AI can actively retrieve when decisions are being made.

That gives product teams a much stronger reason to document important decisions clearly.

5. From Tracking Delivery to Validating Product Intent

For peer benchmarking, a useful AI-assisted review asks whether filters behave as agreed, missing cohorts are handled, access controls are enforced in the correct layer and tests cover boundary cases. Any reported gap is a lead for human review, not a definitive compliance finding.

Product managers spend considerable time tracking delivery. Is the story in progress? Has the pull request been merged? Is QA complete? When will the feature reach production?

Those questions remain important. But AI enables another question that may be more valuable:

Did we actually build what we intended to build?

This is where GitHub Copilot can potentially change the PM's relationship with implementation.

A PM does not need to understand every line of code to ask useful questions about a pull request.

• Explain this pull request from a product perspective.

• What user-visible behaviour does this change?

• Which acceptance criteria appear to have been implemented?

• Does anything here change the way this metric is calculated?

• What existing workflows could potentially be affected by this change?

This does not replace engineering code review. It gives product managers a new way to review product behaviour.

Towards Continuous Product-Intent Validation

Take this one step further. Imagine a pull request references a Jira issue. Through MCP, Copilot can access the requirement.

It can then reason across requirement, acceptance criteria, implementation and tests.

✓ Acceptance criterion 1 appears implemented
✓ Acceptance criterion 2 is covered by an automated test
⚠ Acceptance criterion 3 appears partially implemented
✗ No implementation corresponding to acceptance criterion 4 was identified

A human still needs to review the result. But the feedback loop changes.

Instead of discovering during UAT that engineering and product interpreted something differently, potential discrepancies can be surfaced much earlier.

This creates the possibility of continuous product-intent validation.

The sample acceptance-criteria report above is illustrative, not a real Copilot test result. A trustworthy review should cite the actual issue, changed files, tests and observed behaviour, then record uncertainty and require a human sign-off.

The Bigger Idea: Executable Product Intent

Think of executable product intent as a proposed team operating model, not a built-in Copilot feature. The aim is to keep human-readable requirements, representative examples, decision records and testable acceptance scenarios close enough to implementation that both people and authorised agents can consult them.

Put these changes together and something larger begins to emerge.

Today, product intent is often represented through a collection of documents: a PRD, a Figma design, a Confluence page, several Jira stories, some Slack conversations and perhaps a spreadsheet.

Humans have to assemble those fragments mentally to understand what the product is supposed to do.

AI gives us an opportunity to structure this differently.

Imagine a product specification containing:

/product
    problem.md
    requirements.md
    metrics.md

/prototype
    working-product-concept

/tests
    acceptance-scenarios

/sample-data
    representative-data

/decisions
    product-decisions.md

/.github
    copilot-instructions.md

Alongside Jira for delivery state, Confluence for wider organisational knowledge, GitHub for implementation, and MCP connecting relevant external context.

This is much more than a PRD. It is closer to an executable representation of product intent.

Humans can read it. AI agents can retrieve it. Engineering can implement against it. Tests can validate parts of it. And product managers can compare the implementation against it.

How Product Development Could Work with GitHub Copilot

Now return to the traditional product development process.

We started with:

Customer Problem → Discovery → Requirements → Design → Confluence → Jira → Refinement → Engineering → Testing → UAT → Release

The process is largely sequential. Information moves downstream. Each stage translates the previous one.

With Copilot and connected context, product development could become more iterative:

Customer Problem
↓
Product Intent
↓
Context + Constraints
↓
Prototype
↓
Validate with Users and Stakeholders
↓
Technical Exploration
↓
Engineering-Ready Context
↓
Human + AI-Assisted Implementation
↓
Continuous Product-Intent Validation
↓
Release
↓
Product Outcomes
↓
Learning
↓
Updated Product Context

The important difference is the final step. The process becomes a loop.

Learning does not disappear into another presentation. It updates the context used for the next product decision.

What Changes for the Product Manager?

This does not mean product managers should become engineers. It changes where PMs can create leverage.

The traditional PM spends significant time translating and coordinating information. The AI-enabled PM can spend more time defining intent and improving the context from which decisions are made.

• Writes requirements → Defines clear product intent

• Describes concepts → Builds testable prototypes

• Searches for information → Creates reusable context

• Creates Jira stories → Creates execution-ready specifications

• Hands requirements to engineering → Collaborates around shared context

• Tracks implementation → Interrogates implementation

• Waits for UAT → Continuously validates intent

• Maintains documentation → Maintains product context

• Coordinates information → Orchestrates people, context and AI

• Measures delivery → Measures outcomes and feeds learning back

Some traditional activities remain. We will still need requirements. We will still need Jira. We will still need documentation. And we will absolutely still need experienced engineers.

But their roles in the system can change.

What Copilot Cannot Reliably Decide

Copilot cannot establish whether a product is commercially desirable, whether synthetic data captures real customer behaviour, whether an architecture is secure, or whether every unstated requirement has been met. Generated code, technical analysis and requirement-to-test comparisons may contain omissions or errors. Human product, engineering, security and legal ownership remains essential.

Repository instructions such as .github/copilot-instructions.md can supply guidance, but support varies by Copilot surface. Copilot Spaces curate task-specific context; they are not identical to repository instructions. MCP adds tool access only when configured and permitted. A model's explanation of a pull request is not evidence that the feature is production-ready.

This distinction is important.

AI-generated code does not remove the need for engineering expertise. Production systems require careful thinking about architecture, scalability, security, reliability, maintainability and operational risk.

A prototype generated by a PM should not automatically become production software. An AI-generated technical recommendation should not automatically become an architecture decision. And an AI review of a pull request should not replace experienced engineering judgement.

The opportunity is different.

Product managers can arrive at engineering conversations with better prototypes, clearer intent, richer context, greater understanding of the existing system, better-defined edge cases, more informed technical questions and clearer acceptance criteria.

Engineering can then spend more time on the difficult engineering decisions where its expertise creates the greatest value.

That is a healthier division of labour than simply asking AI to generate more code.

Try This: A First Copilot-Enabled Product Workflow

Choose one small, low-risk product idea. For example, let users compare a metric against a synthetic peer cohort. Use a sandbox repository, representative fake data and a supported Copilot environment. Avoid customer secrets and production credentials.

• 1. Define intent: write the user problem, target persona, desired outcome and non-goals in a one-page product brief.

• 2. Prototype: ask Copilot to help create a basic interactive view with filters, loading states, empty states and synthetic peer data.

• 3. Add context: include metric definitions, glossary, known constraints and repository instructions. Confirm that Copilot actually uses the intended sources.

• 4. Prepare handoff: ask for open questions, dependencies, edge cases, acceptance criteria and suggested tests. Review them with engineering.

• 5. Validate: compare the prototype and any implementation against the agreed acceptance criteria; explicitly record unsupported assumptions and unresolved risks.

• 6. Learn: test the prototype with users, record what changed and update the product context before the next iteration.

Outputs to keep: a working prototype, a short decision log, a set of engineering-ready acceptance criteria, a risk checklist and a list of open questions. Success means less ambiguity and faster feedback, not simply more generated code.

Measure Whether the Workflow Actually Helps

Use a small pilot rather than assuming productivity gains. Compare the time from idea to first testable prototype, clarification questions per story, requirements-related rework, acceptance-criteria coverage and time spent in UAT. Track quality and security findings alongside speed. A faster prototype that creates more downstream rework is not a win.

The Future PM: Less Translation, More Product Judgement

Traditional product delivery often treats intent as a document that moves downstream. A stronger model treats intent, context, prototypes, implementation and validation as connected artefacts that improve with every release. Copilot can help teams build that connection, but only when the context is accurate, the permissions are deliberate and the decisions remain accountable.

Start with one question: where does product intent most often get lost between discovery and delivery in your team? Improve that handoff first. The value of AI is not that it writes more code; it is that it can help people build the right thing with less ambiguity.

Further Reading and Official Documentation

GitHub Copilot documentation: https://docs.github.com/en/copilot

GitHub: repository custom instructions and supported environments: https://docs.github.com/en/copilot/reference/custom-instructions-support

GitHub: using Copilot Spaces: https://docs.github.com/en/copilot/how-tos/provide-context/use-copilot-spaces/use-copilot-spaces

GitHub: configuring MCP servers: https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot

Model Context Protocol: https://modelcontextprotocol.io/