← all posts

Why You Need 3–5 Resume Versions (And How to Manage Them)

Different roles need different narratives. The Pegasus vault gives each version a label, a slot, and a history — so you always know which one you sent.


title: "Why You Need 3–5 Resume Versions (And How to Manage Them)" description: Different roles need different narratives. The Pegasus vault gives each version a label, a slot, and a history — so you always know which one you sent. date: 2026-04-18 tags: ["pegasus", "resume", "strategy"]

Most job seekers have one resume. Maybe a "long version" they trim before sending. The result is one of two failures: either the resume tries to address every kind of role and ends up specific to none, or you keep editing the same file and lose track of which variant landed which interview.

The fix is simple to describe and annoying to maintain by hand: keep a small set of distinct resumes, each tuned to a different narrative, each labeled clearly, each with a record of where it went. The Pegasus vault is built for that, on purpose.

The 3–5 versions to maintain

There's no universal answer, but a useful default is:

  • The product version. For PM-adjacent and product engineering roles. Leads with shipped outcomes, scope, and impact.
  • The platform / infra version. For systems-heavy roles. Leads with reliability work, scale numbers, on-call cadence.
  • The startup version. Leads with breadth, autonomy, and "owned the thing end-to-end". Drops some of the corporate accomplishments that read as bureaucracy in a small team.
  • The big-co version. Leads with the big-co accomplishments. Promotions, scope expansions, project lead roles.
  • The wildcard. Whatever else you keep applying to that doesn't fit the other four.

You don't need all five — most people genuinely only need three. The point is they should be intentionally different, not lightly edited variants of the same thing.

How the vault works

Each slot in the vault is a labeled resume version. You upload, label it ("Product, 2-page"), and it lives in a private R2 bucket with a signed URL — only you can fetch it.

Three things flow from that:

  1. Per-application linking. When you add a job to the tracker, you can mark which resume version you sent. Months later, when an interview reschedule lands, you know which file the recruiter has been staring at.
  2. AI feedback per version. The same JD will surface different gaps against the product version vs. the platform version. The vault lets you run reports against the specific resume you actually sent, not "your resume" as a vague category.
  3. A clean swap-and-replace flow. When you tweak the product resume after a feedback session, you replace the file in the slot. The label stays; the link in every existing application updates automatically.

What this actually buys you

Two things, both quiet wins.

The first is honesty — you stop pretending one resume is universal. You start writing each version like a real argument, addressed to a real reader.

The second is memory — six months from now, when you're trying to figure out why two applications converted and three didn't, you'll know which resume you sent to each. That's the difference between "what worked" being a feeling and being a fact.