How to review a pull request: a PM checklist

If you are a product manager wondering how to review a pull request, start with this: you are not reviewing the code, you are reviewing the change as a customer will meet it. Read the issue the pull request is meant to solve, test the change on its preview, try the paths nobody wrote down, check the copy and look for anything the pull request does that the issue never asked for. Leave naming, structure and performance to the engineers. Then send your comments together in one review with a clear verdict: Comment, Approve or Request changes. That covers most of what makes a PM's review useful, and none of it needs the command line.

A quick case: the bug fix that changed the button colour

CatChow, an online pet-food shop, had a bug: after a customer edited the cart, the checkout button stayed grey. Daniel, a web developer, opened a pull request with the fix and asked two people to review it: Oscar, a backend developer, for the code, and the product manager for everything customers would see.

Oscar approved the code within an hour. The PM started somewhere else: on the preview, a temporary copy of the site built from Daniel's branch. The steps in the description worked, and so did the cases it didn't mention: removing items one by one, a promo code followed by a quantity change, the same cart edited in two tabs.

Two things came up in Files changed, the tab with the diff. The new hint under the disabled button, "Cart is empty. Add items to checkout.", sounded like an error message. And one line in a style file turned the checkout button from green to orange, which neither the bug report nor the description mentioned.

The review went out as one package: a suggested rewrite of the hint, a question about the colour and the verdict Request changes, with a summary saying the fix worked and the colour was the only blocker. Daniel applied the suggestion with one click, put the green back and opened a separate issue to test orange properly. The PM approved, and the fix was merged the next morning. The code review had no reason to stop a harmless-looking colour change; the product review did, because it asked a different question.

What a PM reviews, and what to leave to engineers

You check	You leave to engineers
Does the change do what the issue asked?	How functions and variables are named
Is the copy right: spelling, tone, terms, numbers?	How the code is structured and split up
Does it do anything the issue didn't ask for (scope)?	Performance, security, database queries
What happens off the happy path (edge cases)?	Which library or pattern should have been used
Does it look right on a phone and a small screen?	Whether the automated tests are good enough
Are the analytics events the ones you agreed on?	Whether the code follows the team's style

If something in the code looks odd to you, ask a question instead of giving an instruction. "What does this setting do?" is a fair question from a PM. "Please use a different library" is a judgement you can't back up.

How to review a pull request, step by step

GitHub moves buttons now and then; the labels below are as of 2026.

Read the issue first. The pull request should say which issue it solves, usually with a line like Fixes #131. Open it and remind yourself what was asked and why. This is the yardstick for everything else.
Read the description. A good one says what changed, why and how to test it, with screenshots. If it doesn't, ask before you spend an hour guessing.
Check the header and the state. The line under the title shows the direction, for example main ← fix/checkout-button. A grey Draft badge means the author doesn't want reviews yet. A red cross next to the checks means something failed; ask whether it matters before testing.
Test on the preview. Many teams deploy each pull request to a temporary copy of the site with its own link. Follow the "How to test" steps, then leave the happy path: empty states, long names, a promo code, the back button, two tabs, a phone. If there is no preview, ask the author how you can see the change.
Open Files changed and read what you can judge. Copy files, text in pages, prices and limits in settings, images. Each file has a Viewed checkbox; tick the ones you've read or left to others, and they fold away.
Compare the diff with the issue. Every changed file should have a reason in the issue or the description. A colour change in a bug fix, a new default in a settings file or an extra page are scope questions.
Comment on lines. Hover over a line and click the blue +. Choose Start a review rather than Add single comment, so your comments wait as Pending (visible only to you) and go out together.
Submit with a verdict and a summary. The review button at the top of Files changed (Submit review; older layouts say Review changes) opens a box for your summary and the three verdicts.

Suggested changes: write the fix, not a description of it

For small, exact fixes (copy, a number, a link) don't describe what's wrong. Write the corrected line. The comment toolbar has a button that inserts a suggestion block with the current line, ready to edit:

  "checkoutDisabledHint": "Your cart is empty. Add a treat to check out.",

The author sees it as a small diff with a Commit suggestion button. One click adds your line to their branch as a commit, with you credited as co-author.

Keep suggestions for things you're sure about and that fit on a few lines. For anything bigger, describe the problem and let the author choose the solution.

Comment, Approve or Request changes

Verdict	What it says	Use it when
`Comment`	Feedback, no verdict	You have questions or small notes and no opinion on merging yet
`Approve`	This can be merged	The change solves the issue, the copy is right, nothing extra
`Request changes`	Something must change before it's merged	A real blocker: wrong behaviour, wrong copy customers will see, scope creep

Request changes isn't rude. It's precise, as long as your summary says exactly what blocks the merge and why. Don't use it over a comma, and don't approve while hoping someone else will catch the problem you noticed.

On many teams main is protected by rules: a number of required approvals, passing checks, all conversations resolved. Under those rules a Request changes review from someone with write access holds the merge until that reviewer approves or the review is dismissed, even if another reviewer has already approved. So if you block, stay available: when the author re-requests your review, look again the same day, resolve your threads and approve.

Review comments people are glad to get

The author spent days on this change. A few habits make the difference between feedback and friction:

Comment on the change, not the person. "This hint reads like an error" instead of "You wrote an error message".
Say why. "The colour change isn't part of #131 and affects every customer" gives the author something to agree or disagree with.
Ask when you're unsure. "Is the limit 500 on purpose? The issue says 150."
Mark small things as optional. "Optional: 'Your cart' might read friendlier than 'Cart'."
Say what works. "Tested promo codes and two tabs, the button behaves every time" tells the author which parts they don't need to worry about.

Common mistakes

Reviewing code you can't judge. Comments about variable names or architecture from a PM waste the author's time and dilute the comments that matter. Your value is the customer's point of view.

Reading the diff before the issue. Without the issue in mind you can't tell what's extra, and scope creep is the thing engineers are least likely to catch.

Approving without testing. The diff shows that a line of copy changed; only the preview shows that it fits on a phone screen.

Treating "approved" as "live". Approval allows the merge. Whether customers see the change depends on when it's merged and deployed, and sometimes on a feature flag.

A PM's pull request review checklist

I've read the linked issue and know what was asked.
The description covers what, why and how to test; it isn't a draft, and no checks are failing.
The "How to test" steps and at least three edge cases work on the preview, including on a phone.
The copy is correct: spelling, tone, product terms, numbers.
Every changed file has a reason in the issue; anything extra has a question.
My comments are batched in one review, with suggestions for exact copy fixes.
My summary says what works, what blocks (if anything) and what's optional.

What to do this week

Ask your engineering lead to add you as a reviewer on the next pull request that changes something customers see.
Find out whether your team deploys previews for pull requests, and where the link appears.
Read three recently merged pull requests and their reviews to learn how your team talks.
Save the checklist above next to your issue template, so every review starts from the issue.

Key takeaways

A PM reviews the change from the customer's side; the code belongs to engineers.
Start with the issue, then the description, then the preview, then the diff.
Scope is where a product review adds the most: question anything the issue didn't ask for.
Use suggestions for exact copy fixes, and send all comments in one review.
Comment for questions, Approve when it's ready, Request changes for a named blocker.

FAQ

Should product managers review pull requests at all?

Yes, for changes customers will see: copy, prices, flows, layouts, emails. An engineer's approval says the code is sound; a product review says it's the right change. Many teams require an engineer's approval by rule and ask for a product review by habit.

Do I need to understand code to review a pull request?

No. You need to read a diff well enough to find copy, numbers and file names, and to notice files that have nothing to do with the issue.

What's the difference between a comment and a review on GitHub?

Add single comment posts one comment immediately. Start a review collects your comments as pending and sends them together, with a summary and a verdict, when you submit the review.

Can I approve my own pull request?

No. GitHub doesn't let authors approve their own pull requests; the approval has to come from another reviewer, and on protected branches only reviews from people with write access count.

Learn it hands-on

The lesson Reviewing as a PM: comments, suggestions, approve walks through a full review of CatChow's checkout fix, with a practice review of your own checked by AI. Before it, Anatomy of a pull request explains every tab and panel on the page, and Icons and colours teaches you to read review and check states at a glance. They are part of the free course Git and GitHub for Product People.

How to review a pull request as a product manager (without reviewing code)