The method

Read. Map. Prove. Write. Verify. Grow.

A job description is a requirements document. Most résumé advice skips straight to writing anyway. That’s the equivalent of asking a development team to start coding before anyone reads the spec. This method borrows the discipline software engineering already has for exactly that problem: requirements analysis, traceability, verification, incremental development.

Works entirely by hand, no software required: a printed job description, two highlighters, and your own memory are enough. Read the full whitepaper →

Recorded in the product against synthetic example data. Real screens, not a mockup.

Stage 1

Read: understand the opportunity

Prevents answering a job that was never actually asked.

Before analyzing anything, decide whether the opportunity deserves the effort: pursue, conditional, or not pursuing. Don’t open your résumé yet. Print the job description if you can, and read it three separate times, each with a different purpose.

The three reads

Read one: understand the job. Read naturally, highlight nothing. End with one sentence: what is this person actually being hired to accomplish? That sentence is your role hypothesis.

Read two: identify requirements. Mark responsibilities, capabilities, outcomes, constraints, repeated terms, and strong verbs (lead, own, build, drive) that reveal how much agency the role expects.

Read three: interpret the organization. Ask what the language implies. “Establish governance and improve cross-functional visibility” may really mean: we have coordination problems. A posting is something you investigate, not just parse.

In Standing Proof: All RolesQualify the posting, then take it into Job Lab for the three-read analysis.

Stage 2

Map: decompose the requirements

Prevents treating thirty statements as thirty equally important demands.

A posting rarely contains thirty equally important requirements, even when it contains thirty sentences. Several statements usually point at the same deeper capability: “coordinate across departments,” “facilitate stakeholder alignment,” and “partner with business leaders” can all be one pattern, cross-functional stakeholder orchestration. Group requirements into capability clusters, then weight each one: critical, high, moderate, supporting, peripheral. Résumé space is scarce real estate; it should be allocated by requirement value, not by the order things happened to appear in the posting.

A requirements matrix

IDRequirementPriorityEvidence I have
R1Lead cross-functional programsCriticalERP implementation (strong)
R2Executive reportingHighSteering committee dashboards (strong)
R3Financial managementModerate$4M portfolio (partial)

Each requirement gets an ID. That small act creates traceability. You’re no longer vaguely wondering whether your résumé “matches.”

In Standing Proof: Job LabThe same tool reads both, then breaks the posting into a list of requirements, grouped and ranked by how much each one matters.

Stage 3

Prove: connect evidence to requirements

Prevents both exaggeration and undersell.

Now, and only now, turn toward your own experience. Not your résumé; it’s a lossy summary of a previous compilation. Capture each meaningful experience as a Proof Record: situation, actions, scale, result, and how you know. Far richer than a bullet, because the bullet gets compiled from it later.

Score each match honestly, 0 to 5: from no evidence, through practitioner, up to enterprise-scale leadership with measurable impact. The scale exists to catch exaggeration, and just as often it reveals a strength you’d have undersold.

Capability gap vs. representation gap

Say a posting wants executive presentations and your résumé has none. There are two very different reasons:

Capability gap: you’ve genuinely never done it. A real development goal, not a writing problem.

Representation gap: you’ve done it repeatedly but never wrote it down. Fixable this afternoon.

Most people carry far more representation gaps than capability gaps. A maintained evidence library quietly closes gaps a scrambled rewrite would never even find.

18 requirements analyzed

  • 11Strong evidenceTraced to something you can point at and defend.
  • 3Representation gapYou have it; you just haven't written it down. Capture it.
  • 2Evidence gapYou did it, but can't yet prove it. Recover the scale, metric, outcome, or artifact.
  • 1Scope gapYou've done this, at a smaller size than they're asking for. Say the real number and argue it, or find the bigger seat first.
  • 1Capability gapYou genuinely don't have this. Never fabricate it; track it in the Growth Ledger.

An illustration, not real data. This is the summary the Match Matrix produces for an opportunity, and the reason it is a breakdown rather than a single percentage: each of these four answers calls for different work.

In Standing Proof: Match MatrixEvery requirement traces to evidence, or visibly doesn't. Nothing hides in a gap you can't see.

Stage 4

Write: compile the résumé

Prevents generic, activity-only writing.

Only now does writing start. Every important statement should answer something: requirement → evidence → response. A strong bullet can carry up to five parts: action, object, context, method, result. Not every bullet needs all five. Three questions keep a line honest: so what? What did you do? And if an interviewer says “tell me about that,” can you actually defend it?

A worked example

Requirement: lead cross-functional initiatives, manage risk, report to executives.

Retrieved memory: “I led our customer onboarding redesign.” Interrogated: who was involved (Ops, sales, finance, compliance, IT), who sponsored it (the COO), what was wrong (onboarding averaged 23 days), what you actually did (mapped processes, built the plan, ran weekly meetings, managed risk).

“Led a five-function customer onboarding redesign sponsored by the COO, translating stakeholder requirements into prioritized workstreams, project plans, risk controls, and executive reporting that reduced average onboarding time from 23 to 14 days.”

One sentence answers six requirements. That’s the real measure of quality: not more bullets, more requirement coverage per sentence.

You don't have to take our word for it

The U.S. federal government is the country’s largest employer, and its own résumé guidance asks for exactly this. USAJOBS gives applicants a one-sentence formula: “Accomplished [X] as measured by [Y], by doing [Z].” A measured result, per line. And it warns: “The hiring agency will not make assumptions about what’s in your resume.”

For senior executive selection, OPM goes further: an Accomplishment Record describing “the problem or situation, the specific actions taken, and the results or outcomes achieved” — plus someone who can verify it.

That is a Proof Record with the fields renamed. The method on this page is what the most process-driven hiring system in the country already requires; the difference is that here you build it once, calmly, instead of the night an announcement closes.

In Standing Proof: Blueprint + Résumé StudioCompile the smallest, strongest set of statements, every one traced back to a Proof Record.

Stage 5

Verify: test before you submit

Prevents grammatically perfect résumés that fail to answer the posting.

Software engineering separates two questions, and the résumé needs both. Verification: is it built correctly? Dates, grammar, formatting, consistency. Validation: does it actually answer the posting? Are the critical requirements represented, is the most relevant experience getting the most space, are gaps acknowledged rather than disguised.

A résumé can be grammatically perfect and still fail validation. Go back through every critical requirement and mark it covered, partial, or not covered. This pass routinely surfaces strong evidence you have but never placed on the page.

The human scan test

Print the résumé. Look at it for about fifteen seconds, the way a stranger would. Cover it. Write down what you remember.

If you remember project manager, PMP, communication, leadership, it’s generic. If you remember enterprise transformation, healthcare implementation, executive governance, multimillion-dollar programs, it’s communicating a professional position.

In Standing Proof: Verification LabEvery claim checked against what actually traces to evidence, not a keyword score.

Stage 6

Grow: the step that compounds

Prevents starting from zero every time.

Traditional résumé work behaves like: old résumé → rewrite → submit → forget. This method behaves like software under active development: each application leaves your permanent evidence record a little richer than it found it. A recovered metric here, a forgotten project there. Small increments, but they never need to be re-earned.

Your résumé is not your career history. It’s a compressed release, compiled from a much larger repository. The better the source, the better every compilation. That repository is your professional source code, and it’s what a promotion case, a performance review, and next year’s search all compile from too.

After every application, ask

  • What experience did this posting remind me I had?
  • What metric did I recover?
  • What terminology did I learn?
  • Which capability keeps appearing across my target roles?
  • What new accomplishment belongs in my permanent record?

Resolution

3 of 6 rungs.

  1. Named
  2. Owned
  3. Scaled
  4. Decomposed
  5. Measured
  6. Evidenced

Decomposed

What were the parts? “Ran the migration” hides the analysis, the config, the training and the cutover.

An illustration. Every experience you capture gets read this way, and the ladder never grades you: it asks the one question that would raise the record furthest, then waits.

In Standing Proof: Growth LedgerHonest capability gaps, tracked over time: the pattern a single search can't see.

Start before you need it

The evidence you capture calmly today is the proof you won’t have to reconstruct desperately later.

Or work it by hand first: download the Evidence Starter Kit, six printable worksheets, free and no signup.