Portfolio Review

Portfolio Review

You are not reviewing accounts. You are reviewing reads, and the two meetings look identical for the first ten minutes and then diverge completely.

Reviewing accounts means solving problems, one at a time, until the hour is gone and four accounts have been discussed. Reviewing reads means finding out which of the thirty assessments in front of you are not supported by evidence, which is the only version that scales and the only one that improves a forecast.

The failure this exists to prevent: the review that becomes a working session on the first account raised. Everyone leaves feeling it was useful and twenty-six reads went unexamined.

What this needs

Shared context. If an account-context document exists, read it first, particularly what healthy looks like per segment, which is what lets you tell a wrong read from an unusual account. Where it is absent, carry on and name the assumption.

Minimum: the team's current reads on their accounts. Enough to sample, question and find the thin ones.

Better with last contact dates, health scores you know the composition of, and the previous review's notes, so movement in the reads is visible.

Best with forecast-versus-actual history per person, which turns "I do not believe this read" into a calibrated statement rather than an opinion.

Step 0: Say which meeting this is

Three different meetings get called portfolio review and mixing them is why they run long and change nothing:

• Calibrating the reads, to produce a forecast you can stand behind
• Coaching, to develop the person
• Problem-solving, to fix a specific account

Pick one. Coaching in front of peers is not coaching, it is a performance, and it teaches everyone else to bring safe reads. Problem-solving belongs in a separate, shorter, invited meeting.

Step 1: Sample rather than cover

You cannot review two hundred accounts, and attempting it produces thirty seconds each, which is worse than not reviewing them.

Review three groups:

• By exception. Anything that changed category, anything at risk, anything above a value threshold
• A random sample, five or six accounts nobody chose. This is the group that catches systematic bias, and it is the one always dropped for time. Exceptions show you what the team already knows; the random sample shows you what they do not
• The quiet ones. The lowest last-contact dates in the book, which correlate with risk and with green ratings simultaneously

Announce that the random sample exists and is random. That alone changes how reads are written, which is most of the value before the meeting even runs.

Step 2: Ask the four questions that expose a thin read

Consistently, on every account, so it is a standard rather than an interrogation of whoever is unlucky.

1. What is the mechanism? Not the category. "At risk, low usage" states a category and names no mechanism. A read without a causal chain is a status update
2. Who decides, and when did you last speak to them? The single highest-yield question in the meeting. An unmet economic buyer outranks every usage signal on the page
3. Which of this is what someone said, and which is your inference? Both are legitimate. Confusing them is not, and most over-confident reads collapse here
4. What would make you wrong? A read with no falsifier has not been thought about. This one also does the most to make the meeting feel collaborative rather than adversarial

Ask them in that order. It moves from the account to the evidence to the person's own reasoning, which is a gentler slope than starting at four.

Step 3: Know the tells

Sandbagging. Risk flagged with no play attached. Risk flagged late. Reads that never change state. The signature: an at-risk book that renews at ninety-five per cent, quarter after quarter. It is rational behaviour under a system that punishes misses more than it rewards accuracy, so treat it as a system problem before treating it as a person problem.

Happy ears. Everything green. Evidence verbal, single-sourced, and from a champion who does not control budget. No sceptic named on any account. The tell is that the read contains no bad news at all, which is not how books work.

The green account with no logged touch. The most reliable defect in any portfolio, and it appears in both patterns. Nobody is worried because nobody has spoken to them. Pull these deliberately every time.

Reads that match the health score exactly. Either the score is doing the thinking, or the read was written from it. Ask what they know that the score does not; a good CSM always has something.

Step 4: Protect the person who brings bad news

A review that punishes a red flag gets no more red flags, and your forecast dies quietly about six weeks later.

• Reward the surfacing, separately from the situation. "Good that this is on the table" costs nothing and buys the next one
• Never let a downgraded read be the reason someone is criticised in front of peers. Once is enough to teach the whole team
• Take at least one action off someone's plate in the meeting. It converts the review from an examination into a resource, which is what makes people bring the hard accounts

The system, not the individual, decides whether reads are honest. If everything is green in a team where a miss is punished, the reads are behaving exactly as designed.

Step 5: Look across the book, not just down it

The one thing a manager can see that no individual CSM can: the same mechanism appearing on multiple accounts.

Five reads mentioning the same product gap, the same price change, the same segment under pressure, or the same departed integration partner are not five accounts. They are one problem, and it needs internal-escalation or product-feedback rather than five separate save plays.

This is the highest-value output of the meeting and it is invisible unless someone deliberately looks for it.

Step 6: End with changes, not with notes

• Which reads changed in the meeting, and to what
• What each changed read needs, with an owner and a date
• What you took on as the manager, which should not be zero
• What the pattern was, if Step 5 found one, and who owns it

Then check the previous review's changes actually happened. A review that never audits its own output becomes a reporting ritual within a quarter.

Output

1. Which meeting this was: calibration, coaching or problem-solving
2. The sample: exceptions, the random five, and the quiet ones
3. The four questions applied, with the reads that did not survive them
4. Tells observed, and whether they look like a system problem or a person problem
5. The cross-book pattern, if any, and who owns it
6. Changed reads, with owners and dates
7. What the manager took on
8. Last review's changes, audited

assets/review-agenda.md is the meeting on one page.

Failure modes

• Reviewing accounts instead of reads. The first account eats the hour
• Trying to cover the whole book, which gives thirty seconds each
• Dropping the random sample for time, which is dropping the only part that catches systematic bias
• Coaching in front of peers, which teaches everyone to bring safe reads
• Accepting a category as a mechanism. "At risk, low usage" is not a read
• Not separating what was said from what was inferred
• Punishing bad news, which ends bad news and then ends the forecast
• Treating sandbagging as a character flaw when it is a rational response to how misses are treated
• Missing the cross-book pattern, the one thing only the manager can see
• No audit of last review's changes, which turns it into a reporting ritual

What good looks like

• The random sample was reviewed, and it was genuinely random
• Every account got the same four questions
• At least one read changed in the meeting
• Somebody surfaced something bad and was visibly better off for it
• A pattern across accounts was found and given an owner
• The manager left with actions
• Last review's changes were checked, and some of them had not happened, and that was said

Related skills

• renewal-forecast for the number these reads roll into
• renewal-risk for the read itself, which is what is being reviewed
• coaching for the individual development conversation this meeting will surface and should not host
• internal-escalation and product-feedback for the cross-book pattern once it is found
• book-triage for what the CSM does with the accounts the review flags

Supporting files

• assets/review-agenda.md - the meeting on one page, usable without an assistant