I ask every new mentee the same opening question: "Tell me your top three transferable skills."
The answer almost always falls into one of three patterns.
The first is a list of tools. Python, SQL, Figma, Salesforce. This is technically accurate, but completely uninformative. A tool is something you used. A skill is something you developed through using it. Listing Python tells me you can write Python. It tells me nothing about what you can actually do with ambiguous information, difficult stakeholders, or a system that is about to break.
The second is a list of job description lines. "Managed cross-functional projects." "Drove stakeholder alignment." "Led a team of six." These are responsibilities. They describe what you were accountable for, not what you got good at. Your employer needed someone to manage those projects. You showed up and did it. That is not the same thing as having developed a skill that transfers anywhere else.
The third is a pivot story. "I started in finance, then moved to operations, and now I am in product." This tells me your history. It does not tell me what made each move possible, what you carried forward, or what you will be good at next.
None of these answers tells me what I actually need to know: what this person can do that is hard to find, genuinely valuable across contexts, and actually theirs.
And the frustrating thing is that almost everyone I work with has real skills. Specific, hard-won, in-demand capabilities they have built over years of actual work. They just cannot see them. They are looking at their career through the wrong lens.
The Compounding Paradox
Here is the part that surprises people. The more credentials someone accumulates, the harder this question usually gets.
I have worked with professionals who have completed three Udemy courses, two industry certifications, a side project sitting at 40% on GitHub, and a second job title earned by staying visible when others checked out. They have done a lot. And when I ask about their skills, they stare at the accumulated stack and feel less clear, not more.
The problem is that none of these efforts were connected by a through-line. The AWS cert was tactical (someone said cloud skills matter). The React course was defensive (a job posting asked for it). The side project was exploratory (there was an idea and some free weekends). Each one made sense in isolation. Together, they do not form a narrative. There is no claim to be made from the pile.
This is credentials without compounding. The stack grows; the direction does not.
The instinct, when you feel stuck, is to add more. Another certification. Another side project. Another language or framework. More input. But the problem is not input. The problem is that the input has never been organized into a claim about what you are actually good at. Until you do that work, more credentials just make the pile taller.
What Your Job Description Actually Shows
Your job description shows what your employer needed you to do. It was written by a recruiter or a manager or a head of people who had a gap to fill. It reflects their priorities, not your capabilities.
"Collaborated with product, design, and engineering to ship three features per quarter." That sentence is doing almost no work. Every IC at every growth-stage company has a version of that line.
What that line hides: whether you were the one who caught the bad spec before engineering started. Whether you knew how to tell a VP their timeline was unrealistic and get them to move it without creating an enemy. Whether you could hold context across three simultaneous work streams with incomplete information and still produce a coherent output on each. Whether you had the read-the-room judgment to know when to push and when to hold.
Those are skills. Not the line. The line is the surface. The skill is what you had to develop in order to produce the output the line describes.
The same gap appears in almost every resume I see. People write what happened. They do not write what they learned to do in order to make it happen. Those are two completely different things, and only one of them transfers.
The Inventory That Actually Works
The exercise I use with mentees is called the HOW inventory. For each meaningful project or role in your last five years, answer three questions.
What did you do that would have failed or broken without your specific judgment?
Not what you were assigned. What actually required you. If the answer is "anyone competent could have done it," that is a useful signal. It means the role was not developing the skill you thought it was. That is fine to know early.
If you are struggling to find an answer, think about the moments you were not following a process. The decision that was not covered by any playbook. The time you went off-script because you saw something the script did not account for. Those moments are where your actual judgment lives.
What did you figure out that was not in any documentation or playbook?
These are the moments where real skills form. The undocumented fix that stabilized a system the day before a major release. The workaround that kept a launch alive when the vendor integration fell apart at 11 PM. The stakeholder relationship that turned hostile and then turned around because of a specific thing you said, or decided not to say, in a meeting where most people would have stayed quiet or escalated.
Write these moments down. They feel small in the moment. They are not small. They are the raw material of transferable skills.
Can you describe this capability in a sentence abstract enough to apply to three other roles?
This is the transferability test, and it is where most people get stuck.
"I kept the engineering team unblocked while a VP kept changing the scope" is not yet transferable. It describes a situation, not a capability. A hiring manager reading it cannot picture what they are getting.
"I manage competing stakeholder priorities under conditions of high ambiguity, buying execution teams the time and clarity they need to ship without losing the confidence of senior leadership" is transferable. It names a recognizable capability. A head of product, a chief of staff, a program manager at a scaled company, and a startup ops lead would all immediately recognize that as something they need.
The test is simple: can you name three roles, in three different industries, where this capability would matter? If yes, you have a transferable skill. If not, keep abstracting.
The Trap Most People Fall Into
There is a version of this exercise that looks like it is working but is not.
It is when someone runs the inventory and keeps stopping at the outcome instead of the capability. "I grew the engineering team from four to twelve." That is an outcome. What did you develop in order to do it? "I built a hiring process from scratch in a company that had never hired engineers before, which required me to develop a sourcing approach, a technical screen, and a calibration framework with no internal benchmark to start from." That is a capability.
The other common trap is the impostor instinct. You surface a real skill, and the immediate reaction is "anyone in my position would have figured that out." That reaction is almost always wrong. The reason it feels obvious to you is because you learned it. People who did not have to learn it in your specific context do not have it. That is the point.
A good mentor catches both traps. The first one is usually visible from the outside. The second one requires someone to hold the mirror steady until you can see what they see.
Why This Changes What You See
When you run this inventory seriously, something shifts. You stop looking at job boards through the lens of "does this title match my history?" You start asking "does this role need what I am actually good at?"
That second question opens a much larger map.
I worked with an operations manager at a mid-size logistics company who was certain her career options were "more senior ops roles at logistics companies." After running the inventory, we identified that her core capability was designing high-reliability workflows under regulatory constraint and then training cross-functional teams to execute them. That capability is needed in healthcare operations, financial services compliance, regulated SaaS environments, and government contracting. None of those were on her radar because she had been searching by industry and title, not by capability.
She did not change who she was. She changed how she described what she could do. The map got larger without any additional input.
The most satisfying career pivots I have seen were not pre-planned. They were "I had no idea this role existed, and it turns out everything I have been doing is directly relevant to it." That kind of discovery is only possible after the inventory. You cannot search for a role you have never heard of. But once someone puts it in front of you and you can see the match, the path becomes obvious.
The unlock is not more credentials. It is translation. You already have more than you have given yourself credit for. The work is learning to describe what it is, precisely enough that someone in a completely different context immediately recognizes its value.
Where to Go From Here
Once you have the inventory, three things open up.
First, a narrative. Not a list. A connected claim about what you are good at and why it composes into something distinctive. This is what differentiates you in a conversation, not on a resume. Most people can recite their job history. Almost nobody can say, in two sentences, what they are actually built to do and why a specific kind of role would benefit from having them.
Second, a different search. Now you are looking for roles that need the specific capabilities you surfaced, even if the title is unfamiliar. You are also looking for companies at the stage and in the environment where your specific judgment was forged. Someone who developed their skills in high-ambiguity early-stage environments is often miserable in fully-structured enterprise roles, even when the title looks like an upgrade. The inventory helps you see that before you take the wrong job.
Third, a concrete 12 to 18 month target. Once you know what you have and what you are aiming for, you can identify the gaps precisely. Not "I should probably learn more about AI" but "the roles I am targeting require X, I do not have X yet, and here is the fastest credible path to build it." That is actionable. Everything before the inventory is not.
This is the work that most career advice skips. It assumes you already know what you are good at. Most people do not, not because they lack skill, but because nobody has ever asked them to articulate it in a way that transfers, and they have never had a reason to do the work themselves.
The inventory is not the destination. It is where everything else starts.
