change management

Most PMs think change management is an HR thing. Big company stuff — restructurings, ERP migrations, the kind of project that gets a dedicated “transformation office” with a PowerPoint and a Gantt chart.

That is wrong. Every time you introduce a PRD process where there was none, push for sprint planning in a team that ships ad hoc, migrate users to a new checkout flow, or convince your engineering team to adopt a testing framework — you are doing change management. You are asking people to stop doing something comfortable and start doing something unfamiliar. And most of the time, nobody asked for the change. You did.

The PMs who understand this become leaders. The PMs who do not understand this keep wondering why their “great ideas” die in execution.

Why PMs need to own change (even when it is not in the job description)

In most Indian companies, change management is formally owned by HR or a “transformation” function. A student of mine put it bluntly: “In our organization, it is considered an HR thing. It is not really a product manager or even a product owner thing.”

That is the organizational chart talking. The reality is different. Product managers are the ones introducing changes to how teams work, how customers interact with the product, and how the business operates. You do not need the title of “change manager” to be the person responsible for whether the change actually sticks.

Think about what product work actually involves. You launch a new feature — users have to change their behavior. You introduce a new process — your team has to change their workflow. You shift the pricing model — sales, marketing, and customers all have to change how they think about the product. Every product decision is a change management decision, whether you frame it that way or not.

The question is not whether you will manage change. It is whether you will do it consciously or stumble through it.

The ADKAR model — the simplest lens that actually works

There are dozens of change management frameworks. Most of them are built for consultants running year-long transformation programs. For PMs, I teach one model that scales from a feature launch to a company-wide migration: ADKAR.

Awareness. Do people understand why this change is happening? Not what the change is — why it matters. If your engineering team does not understand why you are introducing PRDs, they will see it as bureaucracy, not as structure that prevents the site from crashing every other week.

Desire. Do people want to participate? Awareness alone does not create willingness. A developer might understand perfectly well why testing is important and still not want to write tests because it slows them down. You have to communicate the personal benefit — not just the organizational one.

Knowledge. Do people know how to change? You cannot introduce a new sprint planning process and then not teach anyone how to write a good sprint goal or estimate a ticket. Knowledge gaps disguised as resistance are the most common reason changes fail.

Ability. Can people actually do the new thing? Knowledge is theoretical. Ability is practical. Someone might understand how a PRD works but still need coaching through their first three PRDs before they can write one independently.

Reinforcement. Will the change stick after the initial push? This is where most PM-led changes die. You introduce a process, enforce it for two sprints, get busy with something else, and six weeks later nobody is doing it anymore. Reinforcement means celebrating early wins, correcting drift, and building the new behavior into the team’s identity.

The entire ADKAR sequence can take five minutes for a small change — or two months for an organizational one. But skipping any step guarantees failure.

Kotter’s 8 steps — the execution playbook

ADKAR tells you what needs to happen in people’s heads. Kotter’s model tells you what to do in the organization. Eight steps, in order. Skip one and the change collapses.

1. Create urgency. Notice the word is “create.” If the urgency were obvious, the change would have already happened. Your job is to make the cost of not changing visible. Show the data: the crash logs, the churn numbers, the competitor who just shipped what you are debating. When Freshworks’ CEO said “if you do not have AI in your roadmap, throw away your roadmap” — that is creating urgency at scale.

2. Form a coalition. If you are the only person in the company saying this change is needed, your team will listen because they want to stay employed — but they will not have faith in what you are saying. Find two or three influential people who agree with you. Get the engineering lead on board. Get a senior designer. Get one business stakeholder who has felt the pain. When three people say “this needs to happen,” it is a movement. When one person says it, it is an opinion.

3. Create a vision for change. Not a 40-slide deck. One clear statement of what the future looks like after the change succeeds. “In three months, we will ship weekly without a single production incident” is a vision. “We need to improve our development processes” is not.

4. Communicate the vision. Once is not enough. Five times is not enough. The vision needs to be repeated in every sprint planning, every retro, every 1:1. People absorb change messaging slowly. What feels like overcommunication to you is the minimum for the team.

5. Empower action. Remove the obstacles that prevent people from changing. If you want engineers to write tests but the test infrastructure is broken, fix the infrastructure first. If you want the business team to fill out a brief but the template is 30 fields long, cut it to 5.

6. Generate short-term wins. This is critical. Big changes take months. Motivation does not last months without evidence that things are working. After two sprints of using PRDs, show the team that zero production incidents happened. Celebrate it. Make it visible. Short-term wins are proof that the change is worth the discomfort.

7. Consolidate gains. Do not declare victory after the first win. Use the momentum from short-term wins to tackle the harder parts of the change. The first sprint with PRDs worked — now extend it to the business-initiated requests, not just engineering-initiated ones.

8. Anchor in culture. The change is not done until it is “how we do things here” rather than “the thing the PM is making us do.” When new hires are onboarded into the process as a default, when nobody remembers the old way — that is when the change is anchored.

The real story: introducing PRDs at a hypergrowth startup

Let me tell you how this plays out in practice. At a fast-growing travel-tech company — 100 to 250 people, new funding coming in, inflection point — the product team had no documentation process. Business stakeholders would ask for changes and they would go straight to production the same day.

The speed felt great. Until the site started crashing. Checkouts would break. Random bugs appeared. The business team was happy with turnaround but furious about reliability.

Here is what the PM did, and this is a textbook application of the frameworks above:

Started small. Did not try to change the entire company. Introduced PRDs only within their own team — maybe 15 people out of 250. This is coalition-building at the smallest viable scale.

Absorbed the burden. Did not ask business stakeholders to write PRDs. Took the writing work and only asked for a 15-minute conversation per request. This removed the biggest obstacle — nobody had to learn a new skill.

Used the pain as urgency. When the site crashed during a peak period, pointed directly at the absence of documentation. “Last week the website crashed. Here is why. This is the cost of not having a process.”

Educated stakeholders. Repeatedly brought awareness to the business team. Showed them the connection between “change pushed at 4 PM with no review” and “site down at 6 PM.” This took weeks, not days. Awareness is not a one-time presentation.

Built evidence. After two months, the team had measurable improvement in stability. That evidence became the argument for expanding the process to other teams.

The change took months, not days. The PM who expects organizational change to happen in a sprint is the PM who gives up after two weeks.

Notice the reinforcement happening in that Slack thread. The PM is not just reporting a win — he is using it to create urgency for the next team. He is building a coalition with Deepak by showing evidence, not making demands. The change spreads because it proved itself, not because someone mandated it.

The hotel general manager problem (or: change fails at the last mile)

Here is a story that illustrates why the last mile of change management is the hardest.

A hospitality company built a new daily reconciliation system — Salesforce integration, SAP backend, automated collection workflows. Technically sound. The entire system depended on one thing: general managers at individual hotels closing their daily ledger before 5 PM, because at 5 PM the collection agent would arrive to pick up the cash. If the ledger was not closed, the process failed. The money did not get collected.

The technology was ready. The process was designed. But the general managers — hundreds of them, at hundreds of hotels — had been closing their ledgers whenever they felt like it for years. Getting them to change a daily habit required more effort than building the entire system.

This is the gap between building something and making it work. The PM who builds the feature and throws it over the wall has done maybe 40% of the job. The PM who ensures adoption has done 100%.

Every change you drive as a PM has a “general manager” somewhere — the end user, the operations team, the sales rep — whose daily behavior has to shift for your change to deliver value. Find that person. Understand their current habit. Design the change to make their new behavior easier than their old one.

Common change management mistakes PMs make

Assuming that a good idea sells itself. It does not. The best feature, the best process, the best tool — all require active selling to the people who have to use them. If you build it, they will not come. They will continue doing what they were doing unless you give them a reason and a path to change.

Trying to change everything at once. Scope the change to the smallest viable unit. One team. One process. One workflow. Prove it works. Then expand. The PM who tries to transform an entire organization in one quarter ends up transforming nothing.

Skipping desire and jumping to knowledge. You scheduled a training session on the new tool. Nobody paid attention. Because you never made them want to use the tool. They do not have a knowledge gap — they have a motivation gap. Fix desire before you invest in training.

No reinforcement plan. You introduced the change and moved on to the next project. Three months later, nobody is following the process. Every change needs a reinforcement mechanism — a weekly check, a visible dashboard, a team ritual that keeps the new behavior alive.

Underestimating emotional resistance. Change feels like a threat. Even when it is objectively better, people resist because the current state is familiar and safe. The developer who has been shipping without tests for three years is not lazy — they are comfortable. Acknowledging that comfort, rather than dismissing it, is the first step to moving someone forward.

Change management for your customers, not just your team

Everything above applies to internal changes. But PMs also drive changes that affect customers — pricing model shifts, UI overhauls, workflow migrations, feature deprecations.

When you move from a one-time fee to a subscription model, your existing customers experience change. When you redesign a dashboard that people use eight hours a day, those users experience change. When you deprecate an API that partners have built integrations on, those partners experience change.

The same ADKAR logic applies. Create awareness (why is this changing). Build desire (what is in it for the user). Provide knowledge (how does the new thing work). Enable ability (migration tools, onboarding flows, documentation). Reinforce (follow-up communications, support channels, success stories).

The PMs who treat customer-facing changes as “we shipped it, now it is marketing’s problem” are the PMs who cause churn. The PMs who treat customer-facing changes as change management problems are the ones who retain users through transitions.

Test yourself

Where to go next

• The skill that makes change stick: Influence Without Authority — you cannot mandate change, so you must influence it
• Managing the people affected by change: Stakeholder Management — mapping who is affected, who resists, and who champions
• Communicating change to leadership: Presenting to Leadership — framing the case for change in five minutes
• When change involves new ways of working: Agile for PMs — the most common process change PMs introduce, and how to do it without creating enemies