Your job title is a cage

Walter Murch edited films with a razor blade.

Not metaphorically. Literally. He would hold strips of celluloid up to the light, mark a frame with a grease pencil, cut with a blade, and splice the pieces together by hand. He did this for Apocalypse Now. He did it for The Godfather. He won an Oscar for it.

When digital editing arrived, his entire physical world changed. The light tables went. The splicing blocks went. The specific feeling of holding a scene in his hands before deciding what to cut, that went too.

Murch switched. He became one of the first major editors to fully embrace Avid, the software that moved editing from physical film to a screen, and went on to win another Oscar.

But the part that gets missed when people tell this story as a triumph of adaptability: Murch didn’t succeed because he learned new software. He succeeded because he had always known, somewhere underneath the razor blade and the celluloid, that his job was never really about the cut.

It was about what the audience felt when the cut happened.

Most job titles in product are secretly descriptions of an instrument.

“Product designer” means, in most teams, the person who works in Figma. “Product manager” means the person who writes the PRD, which is the document that describes what gets built and why, and runs the weekly sprint. “Researcher” means the person who conducts the interviews. The title describes the method. It doesn’t describe what the role is actually for.

This was fine for a long time. When the only person who could produce a designed interface was the person with ten years of design training. When the only person who could make sense of user research was the person who had sat through fifty interviews.

AI is cutting that thread. Fast.

And the people who feel it most are the ones who built their professional identity around being the person who operated the instrument.

Your title describes how you delivered value, not what value you carry.

Early in my career I was at a company where the head of design had been there for eleven years. He had built the design system from scratch. Every component, every visual rule, every repeating pattern in the product had passed through his hands at some point. When new hires joined, the unofficial orientation involved someone quietly telling them: when he speaks in a design review, you listen.

When the company brought in an AI tool that could generate screen variations from a text prompt, he was the most resistant person in the room. Not loudly. He was too experienced for loud resistance. But in every discussion about the tool, his questions circled back to quality, craft standards, the risk of shipping something that didn’t meet the bar.

He wasn’t wrong that the bar mattered. But what he was really doing, without quite saying it, was defending the gatekeeping function his expertise had always performed. His value to the organisation was partly that nothing got through without him. The AI didn’t just threaten his craft. It threatened his position as the person you couldn’t go around.

That’s a different problem. And it needed a different solution than better prompting.

But he never quite named it, so he never quite solved it.

The job title said “Head of Design.” What it really meant was “the person whose judgment this organisation has agreed to trust on visual and interaction decisions.” The first description is about the instrument. The second is about the outcome. Only one of them stays true when the instrument changes.

The editors who disappeared had confused their hands for their minds.

When Avid arrived in editing rooms in the early nineties, it didn’t just replace the razor blade. It changed what editing cost. A cut that used to take two days could happen in two hours. You could try things you would never have tried on celluloid because trying something on celluloid cost real time and real money. The creative space got bigger overnight.

Some editors found this liberating. Others found it terrifying in a way they couldn’t fully explain.

The ones who struggled weren’t always the ones who resisted learning the software. Some of them learned it fine. They struggled because the thing that had made them valuable, that slow, deliberate, expensive judgment of knowing exactly which cut to make before you made it, was suddenly worth less. You didn’t need to be certain anymore. You could just try it.

Certainty had been the asset. The asset became a liability.

I’ve watched a version of this in almost every product team I’ve spent serious time with. The senior PM whose value was holding the entire product history in their head. Knowing without checking what had been tried, why it failed, what the team had already ruled out. When AI tools started doing that same synthesis faster and more completely than any person could, the PMs who thrived were the ones who understood that their real asset was judgment, not memory. The ones who struggled were the ones who had built their identity around being the person who remembered everything.

Memory isn’t judgment. It’s just what judgment used to require.

The title becomes a cage when you start defending it instead of expanding it.

At a software company I know well, the research team had a running tension with the product team about who owned user insights. The researchers felt anything involving user data should come through them. The product team was increasingly pulling insights from AI tools that analyse recorded user sessions, where you watch real people navigate your product, and making decisions without a formal research process.

Both sides had legitimate points. But the argument they were actually having, dressed up in language about process and rigour, was about territory. About who got to be the person whose job it was.

The researchers were defending a title. The product team was solving a problem.

Titles are useful. They signal expertise, set expectations, create accountability. But the moment you start making decisions primarily to protect what the title implies, rather than to produce what the title is supposedly in service of, something has gone wrong.

The film editor who insists a cut should only be made a certain way because that’s how editors make cuts is not thinking about the audience anymore. They’re thinking about being an editor.

I’ve done this. Everyone who’s been in a senior role long enough has done this. You stop asking “what does this product need” and start asking “what does someone in my position do here.” It’s subtle. It feels like professional standards. It is, at its core, fear dressed up in process.

The tell is always the same: you know you’re defending the title when the outcome you’re optimising for is your own continued indispensability.

Murch didn’t adapt by learning software. He answered a harder question first.

Murch wrote and spoke often about what editing was actually for. Not the technique, not the tools. The purpose underneath.

His answer, in plain terms: find the moments in a performance that feel true, then put them in an order that lets the audience feel what the story needs them to feel. The razor blade, the light table, the Avid software, all of it was just how you got there. The getting there was the job.

Once you are clear on that, the tool question becomes simple. You use whatever gets you to the true moment. If that’s Avid, you use Avid. If it’s a razor blade on a Sunday afternoon because you love the feel of it, that’s fine too. But the instrument is not the identity.

Most product people haven’t answered this question for themselves. Not because they’re not thoughtful. The question just never felt urgent before. When the instrument and the outcome were bundled together, inseparable, you never had to pull them apart.

They’re pulled apart now.

A product designer whose answer is “I help people accomplish something they couldn’t do easily before” is in a completely different position than one whose answer is “I design screens in Figma.” A PM whose answer is “I make sure we’re building the right thing in the right order” is in a different position than one whose answer is “I write the PRD and run the sprint.”

Same titles. Completely different relationship to what’s coming.

The resistance is never really about the tools.

When I’ve had this conversation with designers and PMs, and I’ve had it more times than I can count over the last two years, the real sticking point is never AI. It’s identity.

“If I’m not the person who makes the design decisions by hand, who am I?”

It’s an honest question. It deserves an honest answer rather than a motivational poster about growth mindsets.

The job title was always a simplification. “Designer” and “PM” are labels that bundled a set of tasks together with the judgment required to do those tasks well, then gave the whole thing one name, as if it were one thing. AI is now picking up the tasks. The judgment is what’s left.

What’s left isn’t less. But it is different. And different requires a different answer to “who am I at work.”

The editors who made it through the digital transition weren’t the ones with the best attitude about change. They were the ones who, somewhere in the middle of everything shifting, got honest about which part of the work they actually cared about. Which part gave them the feeling of having done something real.

For Murch, it was finding the true moment in a performance. Getting to that moment faster was not a threat. It was just more time to look.

What’s your version of that? Not the task. Not the deliverable. Not the thing your title says you do.

The thing underneath it.

Most people reading this will think the point is to be more open to AI tools.

It isn’t.

The tools are the easy part. The hard part is what Walter Murch had to figure out in an editing room in 1991, holding a razor blade he’d used for twenty years, looking at a screen that could do in two hours what had taken him two days.

Not: should I learn this?

But: what was I actually doing here?

Answer that honestly, and the rest gets easier. Avoid it, and the title you’ve been protecting quietly becomes the thing that holds you in place.