TL;DR
- Applied AI and forward deployed engineer teams are not hiring researchers. They are hiring people who can take a messy customer problem, build something with a model in it, get it into production and stay responsible for whether it gets used.
- A PhD gives you three of the five things they want. Ambiguity tolerance, technical depth and fast learning are already there. What is usually missing is shipping evidence and customer-facing proof.
- You can build the missing evidence in six to ten weeks with one real end-to-end project for a real user, not another notebook.
- Target applied AI engineer, solutions engineer and FDE roles at companies whose product needs deploying inside customer environments. Skip research scientist postings and skip pure platform roles for now.
- Rewrite the CV around outcomes a hiring manager could repeat to a colleague, and prepare for interviews that are half system design and half role play with an awkward customer.
Most of the people booking my coaching calls in the last few weeks have wanted the same thing. They have a PhD or a few years in research, they can see that applied AI and forward deployed engineer roles are where the hiring is, and they cannot work out why their applications go nowhere. The CV is full of models. The postings are full of models. It should match.
It does not match, and once you see why, the fix is fairly mechanical. I went through a version of this myself in the 2026 UK market, interviewing for AI and solutions architect roles with a research background behind me. Here is the route I now walk people through on calls.
What these teams are actually hiring for
Read five applied AI or FDE job descriptions side by side and strip out the buzzwords. What is left is one job. Somebody has a messy real-world problem and a budget. You go and understand the problem properly, build something with a model in it that solves it, get that thing into production inside an environment you do not control, and then stay on the hook for whether anyone uses it.
Notice what is not on that list. Nobody is asking you to beat a benchmark. Nobody cares about your novel architecture. The model is usually an API call. The hard part is everything around it, the data that is never where the customer said it was, the security review, the stakeholder who wanted a dashboard rather than an agent, the demo that has to work on their laptop and not yours.
That is why your research CV lands flat. It answers a question they did not ask.
Three of the five boxes are already ticked
Here is the encouraging bit. When I break those roles down into what they really need, I get five things. Tolerance for ambiguity, technical depth, fast learning in unfamiliar territory, evidence of shipping to production, and evidence of working with a customer or stakeholder who could say no.
A PhD hands you the first three without trying. You spent years on a problem nobody had defined properly, you went deep, and you learned whatever tooling the work demanded. Most engineers coming from a product background are weaker on at least one of those. The trouble is that your CV presents them as research, and the reader is skimming for the other two.
So the whole exercise is this. Reframe the three you have, and go build the two you are missing. Do not try to fake the missing two with language. Hiring managers for these roles read a lot of CVs and they can smell a notebook dressed up as a deployment.
Build the missing evidence in six to ten weeks
The fastest way to get shipping and customer evidence is one real project for one real user. Not a portfolio of six demos. One thing, used by someone who is not you.
Pick a person with an actual problem. A lab mate who spends every Friday cleaning spreadsheets. A small business owner you know. A university admin team drowning in enquiries. Ask them what the problem costs them, build the simplest thing that fixes it with a model somewhere in the loop, deploy it somewhere they can reach without your help, and then go back two weeks later and find out whether they are still using it. Write down what broke and what you changed.
That single loop gives you everything the CV needs. A stakeholder, a discovery conversation, a scope decision, a deployment, an adoption number, and a failure you handled. It also gives you the interview stories, which matter more than the CV once you are in the room.
If you are still in a research role, the project is often sitting right in front of you. The analysis pipeline three people in the group depend on is shipped software with users. Treat it that way on paper. The piece on translating a PhD into an industry CV goes into how to do that translation line by line.
Target the right roles, in the right order
This is where I see the most wasted applications. People with a research background apply to research scientist postings because the title feels safe, and to anything with AI in the name because the market is hard. Both are mistakes.
Research scientist roles at the big labs are a different competition with a different bar, and you are up against people who stayed in research on purpose. Pure ML platform or infrastructure roles want years of production systems experience you do not have yet. Neither of those is the obvious next step from where you are.
The obvious next step is the band in the middle. Applied AI engineer, AI solutions engineer, forward deployed engineer, and the customer engineering or implementation roles at companies whose product only works once somebody makes it work inside a customer. Look at AI startups selling into enterprise, consultancies building AI delivery practices, and the forward deployed teams at the model providers and the data platforms. These teams hire for exactly the shape you can present, and they hire people without the title all the time.
Then apply in the right order. Pick the three roles where your last two years are the clearest answer and go after those first with a tailored CV each. When I score roles for people in OutRung, the research-heavy profiles almost always score higher on FDE and applied AI postings than on the research scientist ones they were drawn to, and lower on the platform roles they thought were a safe fallback. Scoring the role before you apply saves you from a lot of silence. And whatever you target, check the age and applicant count on the posting first, because a two-week-old role with three hundred applicants is not a job, it is a lottery ticket.
Rewrite the CV around what somebody could repeat
Your research CV lists techniques, datasets, publications and methods. An FDE hiring manager reads it and learns what the field was, not what you did with it.
Go through every role and project and write one line of evidence a hiring manager could repeat to a colleague without looking at the page. Built a retrieval tool for a twelve-person group that cut literature triage from a day to an hour, still in use eighteen months on. Took an industry partner’s unlabelled sensor data from raw files to a deployed anomaly detector in eight weeks. If the line cannot be repeated, it is not evidence yet.
Keep your real titles. Put the customer, the deployment and the outcome in the bullets. Drop the publication list to a single line unless the role asks for it. There is a full walkthrough of this in the forward deployed engineer resume guide, and if you lean more towards product teams than customer sites, the AI engineer resume examples cover the same translation for that side.
Prepare for a different kind of interview
The interviews for these roles catch researchers out because they are not technical in the way a PhD viva is technical. Expect roughly three kinds of round.
A system design conversation where you are given a vague business problem and asked how you would solve it with AI. They are watching whether you ask about the data, the users and the constraints before you start drawing boxes. Start with questions, not architecture.
A customer role play or case, where somebody plays a sceptical stakeholder and you have to scope the work, push back on a bad idea and still leave them feeling heard. This is the round that decides it for most people. Practise it out loud with a friend playing difficult.
And a practical build or take-home, usually small, usually judged more on what you chose not to do and how you explained the trade-offs than on the code. Write a short readme that says what you would do with another week.
Your research stories map onto all of this better than you think. Negotiating scope with a supervisor who wanted everything is stakeholder management. Rescuing a project when the data turned out to be wrong is production incident handling. Tell those stories as delivery, not as research.
If you want a second pair of eyes
Most of what I have written here is something you can do alone in a few evenings and a couple of months of focused building. If you want someone to tell you honestly which of the five boxes you have actually ticked, which roles to target first and what to change on the CV before you send another one, that is what the free 15-minute call is for. I have done this move myself and I now spend most weeks helping other people do it.
Either way, stop applying to the research scientist roles out of habit. The job you are already qualified for has a different title.
Related questions
Yes, if you can show one piece of shipped, used software with a model in it and you can talk about a customer or stakeholder you built it for. The PhD itself covers depth and ambiguity. The gap is almost always deployment and customer evidence, and that gap can be closed in a couple of months.

About the author
Tian
Tian is an AI professional, builder, and the founder of OutRung. Holding a PhD in deeptech, Tian navigated the frustrating modern job market first-hand before transitioning into the AI space. OutRung was built to share the exact strategies that made that transition successful. Tian's goal is to help everyday job seekers use AI to find their ideal roles efficiently, without needing to be computer experts themselves.



