How AI Changed the Product Manager Hiring Process

When I started applying for Product roles, I assumed the hardest part of the process would be getting through the resume screen.

I was coming from a Software Engineering background with around three years of experience and trying to transition into Product. Without an official Product Manager title on my resume, I expected I would have to work harder to demonstrate that I understood product thinking, could reason about business problems, and could take an idea from discovery to execution.

What I did not expect was for the hiring process itself to start looking so much like the job I was applying for.

Across the Product, Growth, Associate Product Manager and Product Engineering processes I went through, I was asked to work on problems involving growth strategy, opportunity sizing, customer feedback, prioritisation, regulatory research, go-to-market strategy, prototyping, data analysis and gameplay telemetry.

And increasingly, there was another tool involved in solving those problems: AI.

Not as a shortcut, and not as a replacement for thinking. AI was becoming part of the actual working process.

That changed how I started looking at Product hiring. I don't think AI has simply made take-home assignments easier. I think it has changed what companies can reasonably ask candidates to do, and more importantly, what they can evaluate.

The question is no longer only, "Can you solve this Product problem?"

It is increasingly, "Can you use the tools available to you, including AI, to investigate the problem, challenge what you find, make decisions with incomplete information and still take responsibility for the final answer?"

Product Hiring Is Starting To Look Like Real Product Work

Traditional Product interviews are designed to test how someone thinks under pressure. You might be asked to design a product for a particular user, improve an existing experience, estimate a market, diagnose a drop in conversion, prioritise a roadmap or explain how you would launch a feature.

Those questions are useful because they reveal how a candidate structures an unfamiliar problem. But the interview environment also puts a natural limit on how much real work can be evaluated. You have perhaps an hour, limited information and no opportunity to spend several hours investigating the problem.

AI changes that equation.

A company can give a candidate a much larger and more realistic problem because the candidate now has tools that can help with research, analysis, coding, prototyping and iteration.

Instead of asking how you would approach growth, a company can give you a messy dataset and ask you to clean it, identify the opportunity, quantify it, account for constraints and recommend where the business should focus.

Instead of asking how you would design a marketplace, a company can ask you to define the problem, map the user journey, design the interface and build a working prototype.

Instead of asking a Product Engineer how they would analyse player behaviour, a company can provide actual gameplay telemetry and ask them to turn it into a tool that a Level Designer could use.

The assessment starts looking much closer to the work itself.

That is exactly what I started noticing in the assignments I worked on.

My Take-Home Assignments Started Looking Like Real Product Problems

The assignments were very different from one another, but there was a common thread.

They rarely asked me to simply produce an answer. They gave me a situation, a set of constraints and some imperfect information, and asked me to make a decision.

One Growth Product Manager assignment, for example, gave me a B2B SaaS business with several add-on products, account-level usage data, customer feedback, pricing information and historical conversion data. The goal was to identify a path towards a specific amount of additional annual recurring revenue.

At first, this sounds like an opportunity-sizing exercise.

It wasn't.

There was a major constraint: only two expansion sales representatives were available, and each could handle roughly twenty qualified expansion conversations per month. That meant the theoretical size of the opportunity was not enough. I had to think about which accounts were actually serviceable, how likely they were to convert and where the limited sales capacity should be spent.

The assignment also asked me to identify the number I trusted least and explain what I would do in the first week to make it more reliable.

That detail stood out to me because it reflects how Product decisions actually work.

You rarely have perfect information. The job is not to eliminate uncertainty before making a decision. It is to understand which assumptions matter, make the best decision possible and know what would cause you to change your mind.

Product Problems Are Becoming Constraint Problems

Another Growth exercise involved a marketplace where demand and supply were closely connected.

The business was acquiring paying users through different channels, so the obvious instinct was to look at acquisition efficiency and move more budget towards the better-performing channels.

But the supply-side data told a different story.

The number of live partners was falling, monthly partner churn was increasing and the match ratio was moving further above its target. In a marketplace, acquiring more users when supply is already constrained can create a very different outcome from what the acquisition numbers alone suggest.

The problem therefore wasn't simply, "Which channel should receive more budget?"

It was, "What is actually limiting this business right now, and what happens if we optimise one side of the marketplace without fixing the other?"

That distinction is important because AI can calculate the numbers very quickly. It can compare channels, summarise trends and produce a recommendation. But someone still has to understand the system those numbers describe.

This is where I think Product judgment becomes more valuable, not less, in an AI-assisted workflow.

Another Assignment Started With Regulation And Ended With A Prototype

A different Product Manager assignment began with a completely different problem.

The first part involved researching the compliance and go-to-market landscape for an equity algorithmic trading product in India. The task required understanding the relevant regulations, licensing requirements, partnership models and trade-offs between different ways of entering the market.

The second part moved from research into product design. The challenge was to take an existing portfolio-basket experience and turn it into a marketplace where users could discover products, evaluate them using backtesting information and move towards deploying capital with confidence.

That meant defining the product, identifying the target user and problem, mapping the journey from discovery to deployment, designing the interface, building a working prototype and deciding how success should be measured.

What I found interesting was that the assignment was not simply evaluating whether the final prototype looked good. It explicitly focused on reasoning, product judgment, design taste and honesty about trade-offs and open questions.

That is important in an AI-heavy world because producing something polished is becoming increasingly easy.

Knowing what should actually be built is still hard.

Product Prioritisation Is Also Becoming More Realistic

Another assignment presented a situation that felt almost exactly like a normal Product conversation.

The CEO believed onboarding felt clunky and wanted it to become more delightful. Support had data showing that users who failed to complete their first workout by day two were much more likely to churn. Sales wanted a social leaderboard because a competitor had launched one and prospects had started asking about it. The backlog also contained a progress indicator, a referral programme and a device integration.

The constraint was simple: there were only two engineering sprints available.

The candidate had to choose two things to build and explain why the others should not be built.

This is where Product Management gets interesting.

Almost every feature can be made to sound important when viewed in isolation. The difficult part is deciding which problem deserves scarce engineering capacity right now.

The exercise also asked for one metric that would genuinely demonstrate whether the chosen work had succeeded and another metric that might look good without actually proving anything.

That distinction between activity and impact is something I have started seeing repeatedly in Product assessments.

Then AI Became Part Of The Evaluation

This is where I think Product hiring has changed the most.

One of the Growth Product Manager assessments I encountered explicitly required AI use. It wasn't simply allowed. Candidates were asked to submit the complete, unedited AI transcript alongside their work, including prompts, responses, dead ends and rejected ideas.

The reason was unusually explicit.

The assessment was not only trying to understand the final answer. It wanted to understand what the candidate asked, what they challenged, what they refused to accept and where they overrode the model.

That completely changes how I think about AI-assisted work.

The question wasn't, "Did you use AI?"

It was, "How did you use AI?"

That is a much more interesting question.

AI Is Becoming A Second Brain, Not A Second Candidate

I think the easy interpretation of AI in hiring is that everyone now has access to the same powerful tools, so everyone can produce better assignments.

I see it differently.

If everyone has access to an AI assistant, then the quality of the interaction with that assistant becomes part of the skill being evaluated.

Imagine two candidates receiving the same dataset.

The first candidate asks the model to analyse it and provide the best recommendation. The model produces a polished answer, complete with a framework, supporting arguments and a confident conclusion.

The second candidate starts somewhere else. They ask the model to identify the assumptions hidden in the problem before making any recommendation. They ask which pieces of data should be validated. They ask the model to challenge its strongest conclusion, identify evidence that would disprove it and provide an alternative interpretation of the same information.

The second candidate is using AI as an analytical sparring partner.

That is very different from using AI as an answer generator.

And I think that distinction is going to matter more as AI becomes a normal part of knowledge work.

The Problem Is That AI Can Be Convincingly Wrong

This has probably been the most important lesson for me.

AI is extremely good at producing something that looks finished.

That can make it dangerous.

A model can misunderstand a definition and still produce a coherent analysis. It can make a recommendation even when the data is insufficient to support it. It can connect two metrics that happen to move together and imply causation where there isn't any. It can choose the most obvious feature because the argument for it sounds strategically convincing.

The problem is not always that the answer looks obviously wrong.

The problem is that it can look reasonable.

That means the skill I have found myself developing is not just prompt engineering. It is learning how to interrogate the model.

I want to know why it reached a conclusion, what assumptions it made, what evidence supports it and what evidence would make it change its mind.

The Best AI Prompt Is Sometimes A Challenge

I started changing the way I worked with AI during these assignments.

Instead of repeatedly asking it to make an answer better, I started asking it to make the reasoning harder to defend.

I would ask questions such as: What assumption am I making here? What evidence would disprove this? What am I ignoring? What would an engineer challenge? Which metric could be misleading? What conclusion does the data not support? What is the strongest argument against this recommendation? What information would actually change the decision?

Those prompts were often more valuable than another round of polishing.

Product work is full of uncertainty. A polished answer can hide uncertainty, while a good analytical process exposes it.

That is one of the biggest differences I have noticed between using AI to write something and using AI to think through something.

AI Is Changing What A Take-Home Assignment Can Be

Before generative AI became widely accessible, companies had to be more careful about the scope of take-home assignments.

A large dataset could take too long to analyse manually. Building a prototype could take days. Researching an unfamiliar industry could consume a significant amount of a candidate's time.

AI reduces some of that friction.

A candidate can now reasonably be asked to analyse a large collection of customer feedback, build a theme taxonomy, compare prioritisation approaches, clean a dataset, research an unfamiliar regulatory environment, prototype a product and document the reasoning behind the final recommendation.

That doesn't automatically make hiring better.

There is a real risk of companies turning take-home assignments into unpaid projects that are far too large.

But when the scope is reasonable, AI allows an assessment to get much closer to the actual work a Product person would perform.

And that is probably the most positive change I have seen.

The Lila Games Assignment Was A Different Kind Of Problem

One of the most memorable assignments I worked on was for a Product Engineering role at Lila Games. This was the first round of the process after I applied for the role.

I already have a detailed article here

The assignment provided five days of production gameplay telemetry from LILA BLACK, minimap images for three maps and documentation explaining the data format and coordinate system. The objective was to turn that raw telemetry into a browser-based tool that could help a Level Designer understand how players actually moved through the game's maps.

What initially looked like a visualisation problem quickly became a combination of data analysis, engineering and Product thinking.

I had to understand the telemetry, interpret the coordinate system, map game-world coordinates onto the minimaps, determine how player journeys should be represented, distinguish players and bots, visualise gameplay events and create ways for a Level Designer to investigate the data.

I built the product in phases over three days, and honestly, I enjoyed the process.

The first phase was about understanding the data rather than immediately building the interface. I wanted to know what the telemetry actually represented and what the documentation guaranteed before making assumptions about the product.

The first major roadblock came when I had to map the game-world coordinates onto the minimap. The raw coordinates and the 1024 × 1024 map images did not line up directly, so I had to work out the transformation and validate that the resulting positions were actually appearing in the right locations.

That problem taught me something I find particularly relevant to Product Engineering: a technical detail can become a product problem very quickly. If the coordinate transformation was wrong, every player journey and every heatmap built on top of it would also be wrong.

Once the mapping was reliable, I built the player journey visualisation and then layered gameplay events on top of it. Instead of treating the telemetry as thousands of disconnected points, I wanted the user to be able to see movement, kills, deaths, loot and storm deaths in the context of the map.

Then I added playback.

A static map can tell you where players went, but it doesn't necessarily tell you how a match unfolded. Playback made it possible to investigate movement and events as a sequence rather than just as a collection of points.

The final layer was aggregation. I added High Traffic, Kill Zones and Death Zones as separate heatmap views so that the tool could answer questions about recurring player behaviour rather than only individual journeys.

Throughout the three days, I kept coming back to the same question: "Why should the user see this?"

That question influenced the product much more than the technology did.

AI Helped Me Build It Faster, But It Didn't Decide What To Build

AI was useful throughout the Lila Games assignment, just as it was in the other Product exercises.

It helped me explore implementation approaches, think through data transformations, debug code and move faster when I already understood what I was trying to accomplish.

But it couldn't make the important product decisions for me.

It couldn't decide what a Level Designer actually needed from the telemetry. It couldn't tell me with certainty whether a coordinate transformation was correct. It couldn't decide whether a particular visualisation was useful or simply added noise.

And it couldn't take responsibility for the final experience.

That distinction has become increasingly important to me.

• AI accelerated execution.
• I still had to own the direction.

AI-Assisted Work Is Different From AI-Generated Work

This is probably the simplest way I can describe the difference.

AI-assisted work means that I understand the problem, use AI to explore possible solutions, validate what it suggests, reject what doesn't make sense and take responsibility for the final result.

AI-generated work is when I give the problem to AI, accept the answer and package the output.

The two can look remarkably similar from the outside.

• A polished document doesn't tell you how much the person understood.
• A working prototype doesn't tell you whether the person understands why it works.
• A confident strategy doesn't tell you whether the assumptions behind it were ever questioned.

That is why I understand why some hiring processes are beginning to look at the working process itself.

What Product Hiring Is Starting To Measure

Looking across the assignments I have worked on, I think Product hiring is gradually expanding beyond the traditional idea of Product sense.

Problem framing is becoming important because candidates are often given an ambiguous request rather than a clearly defined problem.

Data reasoning matters because candidates are increasingly expected to work directly with datasets and distinguish useful signals from misleading ones.

Prioritisation matters because the constraints are becoming more realistic. You may have two engineering sprints, two sales representatives or a fixed budget, and your job is to decide what deserves those resources.

Systems thinking matters because optimising one part of a product can damage another part.

Technical fluency matters because Product people can now prototype, analyse data and work directly with engineering tools rather than treating implementation as a black box.

AI fluency matters because using AI effectively is becoming part of the job itself.

And finally, judgment matters because none of the other skills are useful if you cannot decide what to believe and what to do.

I also think intellectual honesty is becoming increasingly valuable.

Being able to say, "I don't know," "this assumption might be wrong," or "the data doesn't support that conclusion yet" is not a weakness in Product.

It is often the difference between a responsible decision and a confident mistake.

The New PM Skill Might Be Knowing What Not To Delegate

AI has made delegation incredibly cheap.

That creates an interesting Product problem.

If almost everything can be delegated, what should remain yours?

For me, the answer is the problem definition, the decision criteria, the trade-offs, the assumptions I am willing to make, the risks I am willing to accept and ultimately the recommendation.

AI can participate in all of those discussions. It can challenge them, expand them and help me see alternatives. But I don't want it to silently make those decisions for me.

The more powerful the tool becomes, the more important it becomes to know where to draw that line.

AI Also Makes Weak Thinking Easier To Hide

There is an uncomfortable side to all of this.

AI can make someone who doesn't fully understand a problem sound like they do.

A weak Product answer can be wrapped in polished language. A generic framework can be turned into a sophisticated-looking strategy document. A shallow prioritisation can be surrounded by terminology that makes it appear rigorous.

That means hiring teams will have to become better at evaluating thinking rather than presentation.

Candidates will have to become better at demonstrating how they reached a conclusion rather than simply presenting the conclusion.

This may explain why more assessments are starting to ask candidates to show their working.

Not just the final answer, but the assumptions, the rejected ideas, the mistakes, the corrections and the reasoning.

The process becomes evidence.

The Best Assignments Are Starting To Resemble Real Work

This is probably what I like most about the shift.

The strongest assignments I encountered did not simply ask, "Tell us what you would do."

They gave me something closer to:

"Here is the situation. Here is the data. Here are the constraints. Make a decision."

That is much closer to actual Product work.

In a real company, nobody gives you a perfectly framed Product Design question.

Someone sends a Slack message. A dashboard shows a worrying number. Sales asks for a feature. Support reports a recurring problem. Engineering tells you there is limited capacity. A competitor launches something. A customer says something that doesn't fit the existing narrative.

Then someone asks:

"So what should we do?"

That is the job.

AI does not remove that ambiguity.

If anything, it gives us more tools to investigate it.

What I Expect To Change Next

I expect Product hiring to continue moving in this direction.

Take-home assignments will become more open-ended and more closely connected to real business problems. Datasets will become more realistic. Prototyping will become faster. AI usage will become increasingly visible.

I also expect interviews to spend less time testing whether someone can produce a polished answer from scratch and more time challenging the assumptions behind that answer.

We may see more assessments where candidates are explicitly given AI tools and evaluated on how they collaborate with them. We may also see live interviews where interviewers deliberately introduce contradictory information to see whether a candidate can recognise that their original recommendation no longer holds.

The evaluation may gradually shift from "Can you come up with the right answer?" to "Can you reason your way towards a defensible decision?"

I think the second question is much harder to fake.

What This Means For Candidates

If you're applying for Product roles today, I don't think the answer is simply to become better at prompting.

Learn to use AI, absolutely. But learn the skills around it as well.

Know how to work with data. Learn how to build a basic model. Learn how to prototype. Learn how to validate assumptions. Learn how to read technical documentation. Learn how to break down an ambiguous problem. Learn how to argue against your own recommendation.

Most importantly, learn to recognise when AI is giving you an answer that sounds better than the evidence actually supports.

AI is becoming easier to access.

Judgment is not.

Final Thoughts

When I look back at the Product hiring processes I've gone through, the biggest change isn't simply that companies are allowing AI.

It is that the presence of AI is changing the kind of work they can ask candidates to do.

A Product Analyst can be asked to investigate a much larger dataset. An Associate Product Manager can be asked to reason through a realistic growth problem. A Growth PM can be asked to connect quantitative opportunity sizing with qualitative customer evidence. A Product Manager can be asked to move from regulatory research to product strategy to a working prototype. A Product Engineer can be given raw gameplay telemetry and asked to turn it into a tool that another professional can actually use.

And the candidate can use AI throughout the process.

But the final responsibility remains with the candidate. That is the part I find most interesting. AI has made producing an answer cheaper. It has not made knowing whether the answer is good any easier. If anything, it has made that distinction more important.

For me, the biggest lesson from these hiring processes has been simple: the future of Product hiring may not be about proving that you can work without AI. It may be about proving that you can work extremely well with AI without outsourcing your judgment to it.

And honestly, that feels a lot closer to the Product job I want to do.