ADKAR change management for PM interviews

ADKAR is the framework that PM interview prep sites have mostly ignored, which is exactly why knowing it fluently separates you from candidates who only know CIRCLES and RICE. Developed by Prosci founder Jeff Hiatt in 1998 after studying change patterns across 700+ organizations, ADKAR diagnoses where an individual is stuck when a product, process, or workflow changes: Awareness, Desire, Knowledge, Ability, Reinforcement. The diagnostic logic matters far more than the acronym.

The five stages and what they actually mean for PMs

Awareness: Does this person understand why the change is happening and what happens if nothing changes? Not “did they receive the announcement” but “do they understand the business case well enough to explain it to a colleague?”
Desire: Do they want to participate and support the change? This is where most PM-led rollouts fail. People can know exactly why a new tool or workflow exists and still choose to resist it.
Knowledge: Do they know how to change? Training, documentation, and demos live here.
Ability: Can they actually perform the new behaviors consistently? Knowledge and Ability are not the same: someone can understand a new workflow in theory and still be unable to execute it under real conditions.
Reinforcement: Are the right signals in place to sustain the change? Recognition, feedback loops, consequence systems. Without this, people revert to defaults.

The Barrier Point: the only insight that matters

Each ADKAR stage can be assessed on a 1-5 scale. The Barrier Point is the first stage that scores below 3. No downstream stage should receive intervention until the barrier is cleared. This is the model’s diagnostic core, and almost nobody applying ADKAR in interview answers mentions it.

The practical implication: running training sessions (Knowledge) when the real problem is Desire is waste. You can run the most thorough onboarding program in the company’s history and achieve nothing if people simply do not want to change. The Barrier Point forces you to intervene at the right layer, not the most visible one.

A worked PM example

strong

"When we migrated our internal data team (18 analysts) to a new LLM-assisted reporting pipeline, I ran an informal ADKAR diagnostic before we wrote a single line of documentation. I interviewed six analysts and found that Awareness was fine: everyone understood why. But Desire was the barrier. Senior analysts felt the tool would make their expertise invisible and commoditize their judgment. That is a fear problem, not a knowledge problem. So I stopped the training track we had planned and spent time on Desire first: I brought the two most skeptical senior analysts in to design the output format, which gave them authorship over what 'good' looked like. Only after their resistance softened did I move to Knowledge (structured walkthroughs) and then Ability (low-stakes pilot sprints with permission to fail). We tracked adoption via weekly active users on the new pipeline and time-to-report as a proxy for Ability gains. Eight weeks post-launch, 15 of 18 analysts were using it as their primary tool, and time-to-report dropped 40%. The three holdouts had a Reinforcement gap: they were not seeing recognition for the new output format. I worked with the analytics lead to change how report quality was highlighted in team standups. I would have wasted six weeks on training if I had not diagnosed the barrier first."

weak

"I used the ADKAR framework to drive stakeholder alignment on our new feature rollout. I made sure people were aware of the change, provided training, and reinforced it afterward. Everyone eventually adopted it."

Why it fails: No Desire or Ability stages named. No Barrier Point diagnosis. No metrics. 'Stakeholder alignment' is vague. 'Everyone eventually adopted it' is not a result. The interviewer learns nothing about how this PM thinks about human change dynamics.

ADKAR vs. Kotter: when interviewers probe the distinction

ADKAR is individual-level: where is this specific person stuck? Kotter’s 8-step model is organizational-level: what must leadership do to create the conditions for change? They are complementary. Kotter without ADKAR loses the people; ADKAR without Kotter loses governance.

The practical read for interviews: use ADKAR when you are asked about a specific rollout where resistance or slow adoption was the problem (your PM levers are diagnosis and targeted intervention). Use Kotter framing when the question is about organizational change at scale, where the issue is leadership alignment and creating urgency at the top. Mature enterprise companies (especially those with consulting heritage) may ask which you would use and why. The right answer names both and explains the scope distinction.

One note on the Prosci research: the “six times more successful” stat comes from Prosci’s own research program of 25,000+ participants over 25 years, not independent academic literature. A sophisticated interviewer may probe this. The honest answer is that the stat reflects Prosci’s self-reported dataset, but the diagnostic utility of Barrier Point identification is conceptually sound regardless of the correlation.

When to name ADKAR explicitly vs. just use the logic

At enterprise companies with established change management practices (large financial institutions, healthcare systems, enterprise software vendors), naming ADKAR signals fluency in a language the company already uses. At early-stage startups, naming frameworks reads as cargo-culting: use the logic without the label. The tell is whether the company has a change management function or dedicated program managers. If it does, the label is safe.

The 2026 context: AI rollouts are ADKAR problems

In 2026, most “drive adoption” questions in PM interviews are really about AI features or agentic workflows, because rolling out an AI copilot or an LLM-assisted process is not a UI change: it is a behavioral and cognitive change. When users can delegate judgment to an agent, the question is not “do they know how to use it?” The question is “do they want to give up that judgment, and have they built the muscle memory to calibrate when to trust the output?”

That is Desire and Ability, exactly. A PM rolling out an internal coding copilot, an LLM-assisted triage tool, or an agentic reporting pipeline needs to diagnose resistance at the individual level before any tooling decision makes sense. The barrier for senior engineers adopting a coding copilot is almost never Awareness or Knowledge: it is Desire (concern about skill atrophy or being evaluated on volume rather than quality) and Reinforcement (whether the team’s definition of a good engineer has updated to include effective AI delegation).

This connects directly to what makes a product lovable in the current environment: meeting people where they work means understanding the resistance they have to ceding control, and designing the adoption experience around that resistance rather than papering over it with training and documentation.

For structuring behavioral answers around influence and resistance, see the STAR method and influencing without authority. For the broader case against reaching for frameworks by reflex, see beyond frameworks.