Transferable Isn't the Same as Compatible

Fish out of water photo by Vinayak VN / Unsplash

I've spoken at length before about the differences between different fields of design or product roles. Some folks may say, "So what, I can learn what I don't know?" And I would agree with you. If you recognize the differences, I am confident many people can learn where they're lacking to bridge one field to another. But what about the things you have to unlearn? What about the things you already know that are counterintuitive or even damaging to your success if you want to change roles?

Picture this

It has been 6-18 months since the past leadership decided to change a designer from marketing-based to product design, and now they're disappointed with them and starting to think it's not a fit. This is a marketing designer who's used to graphic design, advertising, branding, or related fields. No one has invested in their success until I showed up, partially because they didn't know the difference between these types of design.

This exact scenario has happened to me a few times now, and I always notice the same things:

Management that assumes fields are related enough to make a full switch of roles
Treating confidence or a desire to help as competence
Not helping coach or set expectations for these people as their roles change
Providing subjective instead of objective feedback and direction
The person continues to operate as they always did, because that's how they were taught, and no one is teaching them any differently

And, to be honest, it makes me furious. Not at the marketing folks, mind you, but at the near-sighted, incurious leadership that allowed this to happen. Because it's not a dang skills problem; I have coached many a marketing person into a successful product contributor and collaborator. Allow me to elaborate.

Comforting lies

There's a weird career-change industry that's formed over the last few decades. Influencers, hiring agencies, bootcamps, and bad leaders are selling reassurance to folks: "you already have 80%, just learn the missing 20%!" There's also frequently a standard framing pitched to folks, treating things as a focus shift, e.g. changing language from "customers" to "users," and the rest is easy. This simply isn't the case, though.

Every successful product person I have coached who came from a different background succeeded because we worked through how much of the 80% of their old role that was load-bearing may actually be destructive in their new one. Yes, you heard me right. Not gaps to fill, but things to remove. We have to actively identify what works and what doesn't, which behaviours help or hinder, and what needs coaching or training.

Let me put this another way: If you think your skills in visual design mean you're qualified for a position based in psychology and research, you're out to lunch. If you think your project management skills suddenly make you an expert in product discovery and validation, you've got marbles rolling around in your head. And if you think your experience building bulletproof briefs and spec docs means you're going to be a rockstar when it comes to navigating ambiguity, getting people communicating and collaborating transparently and safely, then you've completely lost the plot.

People can learn. You can absolutely switch roles, and even do so to a vastly different one. But it only works when behaviour gets rebuilt, and you must budget for that.

Skills vs. behaviours vs. norms

Not everything is portable:

Skills: These are portable. For example, typography skills move across roles. Research moves.
Behaviours: habits the old role rewarded. These don't move cleanly; some even invert. Some of the hardest to rewire.
Norms: the invisible operating system: what "done" means, how you treat a request, who you answer to

I believe there's something very counterintuitive to beat here, too. The deeper your tenure, or the more senior you are, the harder you'll fail. Veterans have much more to unlearn than juniors. Sometimes culturally at the org, sometimes from a lifetime of working a certain way. I have seen folks get depressed, get angry, let their egos out, or just silently fail and disappear.

In my experience, this can be very hard for some folks to wrap their heads around.

I've watched this calcify into identity at many different levels. It might be the intermediate designer who won't start work until they have a full brief, or the VP of Product who can't stick to a roadmap and distracts her people by saying yes to everything. It comes in many forms and consistently harms the person trying to switch roles without support, as well as the folks that report to them or work alongside them.

Conflicting behaviours

Here are some common behaviours that might conflict when trying to move from one function to another. These are framed mostly as folks trying to move into product management or product design.

The Service Posture

Behaviours: Waterfall, top-down, say-yes-to-everything, request-as-spec
Works over there: the client is the authority, the ask is the brief
Breaks over here: treating a request as a spec is malpractice; the job is to interrogate it, sometimes refuse the literal ask
When disguised: reads as "responsive, low-maintenance, easy to work with"

The Gate Fixation

Behaviours: Briefs and specs as the unit of work
Works over there: clarity, sign-off, scope control
Breaks over here: in product, the spec is an output of discovery, not the input. Waiting to be told what to build reproduces the exact dysfunction
When disguised: reads as "organized, process-driven"

The Finish Line Fallacy

Behaviours: "Done when shipped"
Works over there: campaigns have a terminal point, like "launch, report, and on to the next"
Breaks over here: shipped is when measurement starts. Product is a loop, not a line
When disguised: reads as "delivers, closes things out"

Reactivity over Strategy

Behaviours: High responsiveness as the dominant mode
Works over there: a virtue
Breaks over here: crowds out discovery, roadmap, proactive thinking
When disguised: reads as "always available, hustles"

The enchantment problem

Sales and marketing people are trained to pitch, sell, and project confidence. The problem with that is that if you're in a more nebulous field like product, where ambiguity is important to disclose and navigate, leaders can't always see the work directly, so they rely on confidence and articulateness. In other words, a great pitcher reads as a great practitioner. Suddenly, you have the first-year medical student doing neurosurgery simply because they were the most charismatic.

After this, the damage compounds silently because the one person fluent at managing upward perception is the one doing the damage. You don't just get a struggling IC. You get a struggling IC whose self-presentation actively suppresses the signal that they're struggling. This is far, far worse than a quiet underperformer. The most fluent self-advocate is the least scrutinized.

What this should mean for you as a leader

Having people, even credentialed, confident, "they know their shit" people, is not having the right people for this operating model (highly collaborative, ambiguous, transparent areas like product management and product design).

What I recommend to leaders that think they may have one of these folks, or are aiding someone transitioning roles:

Active 1:1 coaching time. ACTIVE, not nominal. And not after the first failure.
Growth plans that name behaviours to unlearn explicitly, not just skills to learn.
Checks and balances that surface the work itself, not the person's account of the work/status updates.
A realistic unlearning timeline.
The move isn't erasing someone's background; it's re-pointing it. Recognize prior experience while rebuilding behaviour.
Form and revisit working agreements.
Dig deep in retrospectives, focusing on areas of improvement and accountability.
Actively avoid mistaking confidence and polish for competence in the new mode. This goes double for a beautiful-looking portfolio that says nothing about cultural fit or process.
Get others to elaborate on what they say about these reports, as something that seems good, like "they're so easy to work with," may mean "they say yes to everything."

What this should mean for you as an IC

Recognizing where you're coming from and that where you're going are two completely different fields is half the battle.

What I recommend to individual contributors transitioning roles:

Assume your defaults are wrong until proven otherwise.
Treat "done" as the start of measurement and potential iteration.
Interrogate the hell out of requests instead of executing them.
Avoid leading with any kind of pitch before you have the substance. For the love of all that is right in the world, use the words "I don't know."
Do not mistake old fluency for new competence.

Closing

There are a lot of paths and forms this can take for people. I've seen folks go from Sales to Product at an Agency (not the same), to Product Person, and then floundering. I've seen the most charismatic "Yes Men" turn into "Never again, please" for their organizations.

It's the same shape every time: fish out of water. The behaviours the old role rewarded are the ones the new role punishes.

As a leader, be aware, and only hire or move these people if you're willing to invest, coach, and mature honestly. As an IC, only accept or attempt a move if you have the humility and gumption to let go of the old and invite in the new.