Skills Gap Analysis: Working Out What to Learn Next

Start from the destination, not the catalogue

The usual way people decide what to learn is backwards. They browse a course platform, find something interesting and affordable, complete it, and then discover it changed nothing about which jobs they can get.

The problem is that the starting point was availability. A useful plan starts from a specific target and works back, which means the analysis has to come before any decision about what to study.

The analysis itself is not complicated and it takes an afternoon. Most people skip it because it produces an uncomfortable answer: the gap is usually not a course-shaped gap. It is often experience, or scope, or a specific kind of project you have not run.

That answer is more useful than a certificate, even when it is harder to act on.

Build the evidence base

Collect ten to fifteen job postings for the role you want, at the level you want, in the market you are in. Save the full text.

This is the step that makes the whole exercise work, because it replaces your impression of what the role requires with what employers are actually writing. Impressions are usually a few years out of date, weighted towards what your current employer values.

Take the postings from a spread of companies rather than five from the same one. A single company's requirements reflect its stack and its habits; the pattern across a market is what you are trying to see.

Then read them with a tally. Every skill, tool, credential and kind of experience mentioned, and how many of the fifteen mention it. Twenty minutes of tedium produces the only genuinely useful output of the exercise.

Separate the real from the wished-for

Job descriptions mix hard filters with aspiration and read as if everything is mandatory. The tally sorts them.

Mentioned in most postings. These are real. Missing one is what is keeping you out, and it is where the plan goes.

Mentioned in a third or so. Differentiators. Useful, not blocking. Worth picking up if one aligns with something you already do.

Mentioned once or twice. Ignore them. They reflect one team's particular setup and chasing them is how people end up with a scattered set of half-learned tools.

There is a second cut worth making, between things that are checked and things that are claimed. Licences, clearances and specific regulated credentials are verified. Most software and methodology requirements are not, and the honest question there is whether you could hold your own in a conversation about it, not whether you have a certificate.

Our career guides set out what each role's core requirements look like, which is a reasonable sanity check against your own tally.

One clear takeaway: a requirement in most postings is a filter, one in a couple of postings is somebody's preference.

Score yourself honestly

Against each of the frequently mentioned requirements, put yourself in one of four places.

Have it and can evidence it. You have done this in a job, and you can name the project, the scale and the outcome.

Have it but cannot evidence it. You know how, but it happened years ago, or in a side project, or in a way that does not appear on your resume. This is a writing problem, not a learning problem, and it is far more common than people expect.

Adjacent. You have done a near neighbour. Different cloud, different framework, same discipline. Adjacency is usually acceptable to employers if you name it explicitly rather than hoping they infer it.

Genuinely missing. You have not done it.

The second category deserves attention before anything else, because it costs nothing to fix. A significant share of people who think they need to learn something actually need to write down what they already did. Our resume builder is built for exactly that gap between what you have done and what your resume says.

Prioritise what unblocks you

Now order the genuinely missing items, and not by interest.

Put first anything that appears as a hard filter in most postings and that you cannot work around. These are the items where being without them means your application is never read, and everything else is secondary until they are handled.

Second, anything that opens up several other things. Some skills are prerequisites for a cluster: SQL underneath most analytics work, a cloud platform underneath most infrastructure work, a language underneath a whole market. Learning one of these buys more than it costs.

Third, whatever is nearest to what you already do. The cost of learning is much lower when you are extending something rather than starting fresh, and early progress is what keeps a plan alive.

Leave off anything that would take more than about six months to reach a usable level, unless it is a hard filter. Long-horizon items belong to a career decision rather than a learning plan, and mixing them in is how plans get abandoned in month two.

Make each item end in something

This is the rule that separates a plan that changes your prospects from one that fills evenings.

Every item should finish with an artefact: something you can point at, show, link to or describe with specifics. A completed course is not an artefact. A thing you built with what the course taught you is.

The strongest artefact is work done at your current job, which is why the first question for any gap should be whether you can arrange to do it where you are. Volunteering for the project nobody wants is faster, cheaper and more credible than any external route, and it comes with a colleague who can vouch for it.

Where that is not possible, in order of usefulness: a real project with a real user, a substantial personal project, a documented piece of analysis, a certification. Certifications sit last for most fields and first for a few. In regulated and compliance-driven work they are checked; in fields where you can show the work, they carry much less weight than the work itself.

Put a date on each item and keep the list to three. A plan with nine items is a wish list, and the failure mode is starting all nine.

Learning that survives

Skills you do not use decay quickly, which has two practical consequences for how you sequence a plan.

Learn things close to when you will use them. Studying something you will not touch for a year is mostly wasted effort, and the version you half-remember later is often worse than starting fresh, because you believe you know it.

Apply immediately, even artificially. A week between learning something and using it is the difference between retention and vague familiarity. This is why the artefact rule works: it forces application into the plan rather than leaving it as a hoped-for next step.

Then write it down as you go. The details that make a resume bullet credible, the numbers, the scale, the specific problem, are all clear at the time and gone within months. Keeping a short record while you work is the cheapest possible way to make the effort visible later.

When to redo the analysis

Once a year is enough when you are settled, and immediately whenever your target changes.

Requirements move faster in some fields than others. Anything touching AI tooling has changed materially in the last two years and the postings show it. Regulated fields move slowly and an analysis from three years ago is largely still valid.

The signal that yours is stale is simple: you read a posting for your target role and see several terms you do not recognise. That is the moment to redo the tally rather than assume the market drifted a little.

Questions people ask

How do I know which skills actually matter?

Tally them across ten to fifteen real postings for your target role. Requirements appearing in most of them are filters; the rest are preferences.

Are certifications worth it?

In regulated and compliance-driven fields, yes, because they are checked. Elsewhere a piece of work you can show usually carries more weight.

What if I have the skill but no proof?

That is a writing problem rather than a learning one. Naming the project, scale and outcome on your resume fixes it at no cost.

How many things should I learn at once?

Three at most, each with a date and a finished artefact attached. Longer lists reliably get started and not completed.

How often should I redo this?

Yearly, or whenever a posting for your target role contains several terms you do not recognise. That is the sign the analysis has aged.

Related reading

• Cover Letter Format: Layout, Length and Where It Goes
• The Job Application Checklist Worth Running Every Time