The Change Manager's real job (and why most get it wrong)
How change managers can use problem validation tools to design better change plans.
Most change managers spend their time in the wrong place.
They're writing communications for changes that shouldn't happen. They're designing training for solutions that don't work. They're trying to drive adoption of things that solve the wrong problem.
Here's the thing: it's not their fault.
By the time most change managers get involved, the decisions have been made. The solution is locked in. Their job becomes:
Make people use this thing we've already built.
But the best change managers? They ask different questions. And they use those insights to design better change plans.
The change plan problem
Your job is to design a change plan that gets people to adopt the solution. But here's what makes that nearly impossible: most solutions were never properly validated in the first place.
You're asked to create communications, training, and engagement strategies for something that might not even solve the right problem. It's like being asked to sell a product that nobody wants.
So what can you do? You can't redesign the solution, but you can understand the real problem it's supposed to solve. And that understanding changes everything about how you approach the change plan.
Build this into your discovery process
Before you start writing communications or designing training, spend a week doing discovery: change discovery.
Use the Requirements Compass in your stakeholder interviews. Instead of just asking:
"What's changing?"
Ask:
"What problem is this solving?"
Map out whether you're dealing with validated problems, technical constraints, business preferences, or assumed solutions.
This tells you what story you need to tell. If it's a validated problem, you can lead with the pain it's solving. If it's a business preference, you need to focus on benefits and buy-in. If it's an assumed solution, you need to be extra careful about adoption barriers.
Next, use the Behavior Lens to observe people in their actual work environment. Don't just interview them. Watch them work for an hour or two. See how they currently handle the process you're trying to change.
You might discover things like: people email invoices because they trust that method, but they don't trust the new form because it doesn't give confirmation. Now your change plan can address trust, not just process compliance.
Finally, use the Solution Field Map to think through what type of change strategy you actually need. Is this fundamentally a process change? A technology adoption challenge? A behavior shift? Or a communication issue?
Each type needs a different approach. A process change needs clear workflows and role clarity. A technology adoption needs hands-on practice and troubleshooting support. A behavior change needs reinforcement and social proof. A communication issue needs better messaging and feedback loops.
As you go, capture everything in the Evidence Box. Not just what people tell you, but what you observe, what assumptions you uncover, and what resistance patterns you see.
Design your change plan
Now when you sit down to design your actual change plan, you're not guessing.
Your communications can address the real concerns instead of generic change messaging. If people don't trust the new system, your comms focus on reliability and transparency, not just features.
Your training can tackle actual friction points instead of just explaining how the tool works. If people struggle with a specific step, you build practice around that step.
Your engagement strategy can target the real influencers and address the real barriers. If managers are worried about losing visibility, you show them how they'll actually gain it.
Your success metrics can track behavior change, not just system usage. Instead of measuring “form submissions,” you measure “invoice processing time” or “approval clarity.”
Track what's actually working
As your change plan rolls out, keep using the Evidence Box to track what's working and what isn't. Not just adoption rates, but the underlying behaviors and problems.
Are people using the new process but finding workarounds for certain steps? That tells you where to adjust your approach.
Are communications landing well with some teams but not others? That tells you how to segment your messaging.
This way, when you need to course-correct (and you will), you're making decisions based on evidence, not instinct.
The bottom line
Good change management isn't just about execution. It's about designing a plan based on reality, not assumptions.
These tools don't replace your expertise in communications, training, and engagement. They give you better inputs to work with during your discovery phase, so your change plan actually addresses what's happening on the ground.
And when your change plan is grounded in real problems and real behaviors, people don't just comply, they actually adopt the change.
Liked this piece? Go deeper:
See it live: Join a free Proof Lab to catch one of the tools in action.
Read more stories: Subscribe to the newsletter.
Explore the method: Visit proofsprint.com for the full toolkit.
You are golden! I needed this today!! Thank you Pragati!!
Once this outstanding change management process is completed, at least the first iteration, how do you effectively disseminate the change, to colleagues or customers?