Release notes are long and mostly irrelevant to any one client. The skill is finding the parts that touch what YOU have built, in an hour rather than a week.
Start from your own inventory, not from the notes. You have a list — the reports, the integrations, the personalisations, the flexfields, the scheduled jobs. Read the notes looking for those, rather than reading everything and asking whether it matters.
Four searches cover most of it. The MODULES you have configured — skip the rest entirely, and that removes most of the document. Anything described as CHANGED or REMOVED, which matters far more than anything new. Subject areas and reporting, because those are your exposed artefacts. And service or API changes, for your integration list.
NEW FEATURES ARE THE LEAST URGENT PART AND THEY TAKE UP MOST OF THE PAGES, because that is what release notes are written to sell. They arrive switched off — Lesson 5 — so they are a decision for later rather than a risk for this weekend.
Write the output as a SHORT LIST OF THINGS TO CHECK, with an artefact name against each. "Payables subject area gains two attributes — check the ageing analysis and the supplier extract" is a usable line. "Payables has changes" is a line somebody reads and does nothing with.
An hour, once a quarter, on a document written for everybody. That is the whole job, and doing it badly means finding the same information on the Monday after, from a user.