Hey folks! 👋

Welcome to another edition of Debug, where I answer your growth and go-to-market questions!

In Debug 004 I’m answering a question from a founder who’s team is frequently hindered by technical champions for an incumbent competitor.

TOGETHER WITH INFLECTION.IO

Inflection.io’s thought leader content team spent 3 years curating and creating an extensive collection of product-led growth go-to-market resources. From ebooks and idea lists to guides, videos, webinars, and insightful posts – they’ve put it all together for you. 1000s of pages of content all hand-written - no AI.

And for the first time ever, they're giving it all away as one offer.

If you’re in marketing, sales, a founder, or in other GTM tangential roles, check it out:

Please support our sponsors!

DEBUG

Debug 004: The Incumbent Gatekeeper

"Your product is better in most ways, but we're staying with <competitor>."

Sound familiar?

In the last few weeks, I've heard various twists on this scenario from 3 different founders and GTM leaders.

Each time, they were blocked not by features, pricing, or security – but by something far more powerful: professional identity.

And last week a founder and Product-Led Geek reader sent me an email asking:

Time to debug…

This is a tricky situation, and common in enterprise product-led sales contexts.

You might have amazing product, objectively superior to the incumbent solution.

But then you hit a wall.

A big, well-defended wall.

A power user, an admin who’s built their career, their workflows, their identity around the existing tool.

They’re the “Jira Guru,” the “Salesforce Wizard,” - the person everyone in the company goes to for help.

And whether it's due to security mandates, compliance requirements, or the deep integration of existing systems, the typical PLG playbook - land and expand, prove value team by team - isn't an option here.

This creates two distinct challenges:

1. Psychological: You're not only replacing a tool; you're threatening someone's professional identity

2. Technical: You need to facilitate a complete system transition while maintaining business continuity

Here’s a way tackle both challenges cohesively.

The Psychology of Technical Change

It’s easy to treat this as a technical problem when it's actually an identity crisis.

Your power user has spent years becoming the go-to expert for the incumbent tool.

They've built custom workflows, solved complex problems, and earned respect for their expertise.

Asking them to switch tools is much more than a technical request.

It's asking them to risk their professional standing.

These power users are typically motivated by at least one of three core drivers:

• Technical mastery and expertise

• Organisational influence

• Career progression

This requires a fundamental mindset shift from replacing their tool to helping them become even more valuable to their organisation.

A big part of the solution here is in something I call ego engineering.

Ego Engineering

Each step here is designed to protect and enhance the power users’ status while facilitating change.

1. Status Projection / Reinforcement

Acknowledge their expertise and impact with specific examples. Make it clear their value transcends any particular tool: "The workflows you've built have saved the team countless hours. That kind of process expertise is exactly what we need."

2. Position Them as the Change Visionary

Help them take ownership of the improvement vision: "With your deep understanding of the team's needs, what opportunities do you see for evolution?" Let them identify and articulate the potential for change.

3. Establish the Why Now?

Work with them to identify and articulate the business case for change. Their frontline experience with team pain points makes them ideal for connecting technical limitations to business impact.

4. Expertise Transfer

Demonstrate how their existing expertise becomes even more valuable with your solution. Highlight specific ways they can expand their impact through new capabilities, certifications, and leadership opportunities.

5. Involve them in Product Discovery

Make them a key stakeholder in your product development process. Give them early access to prototypes, seek their input on feature prioritisation, and create formal channels for ongoing influence. Position them as a product insider, not just a user.

6. Involve them in Implementation / Migration Planning

Put them in charge of the migration strategy. Give them ownership of planning workshops, documentation, and critical decisions. Make them the migration architect with real authority over the transition process.

Supporting The Transition Across the Customer Lifecycle

While understanding the psychology is crucial, you need practical strategies across the customer lifecycle to support these transitions.

Here's what to focus on at each stage:

1. Discovery & First Impressions

Power users need to see themselves succeeding with your product before they'll consider it seriously. Show them how others like them have made the switch. Give them hands-on access to technical features early. Let them test things privately without pressure. Your marketing should speak their language - technical and specific, not sales-focused.

2. Technical Evaluation

At this stage, power users want proof that switching won't break things. Give them tools to test your product alongside their existing system. Open up your APIs during trials. Write documentation that respects their expertise. Help them assess the real work involved in switching.

3. Migration Planning

Once they're interested, they need to see a clear path forward. Help them map their current workflows to your system. Let them move things over in stages. Build tools that track progress and highlight risks. Most importantly, let them influence the process.

4. Implementation Support

Make it easy to move data between systems. Build in safety nets like rollback options. Show clear progress metrics. Support running both systems together during the transition. Let teams move over gradually instead of all at once.

5. Long-term Success

The switch is just the start. Give power users tools to continue to enhance their expertise. Connect them with other experts using your product. Help them share what they learn with their teams, and help them demonstrate and showcase the impact of the transition.

Handling Common Resistance Points

Power users will often raise objections that sound technical but mask deeper concerns. Here's how to address them:

• Surface concern: Sunk cost

• Real concern: Fear of wasted expertise

• Response: "Let's map out how your customisations could work even better in our system"

• Surface concern: Team disruption

• Real concern: Loss of status

• Response: "We need your expertise to lead this change successfully"

• Surface concern: Technical feasibility

• Real concern: Control and ownership

• Response: "Show us your most complex workflows. Let's prototype them together"

Remember: Address the status and identity concerns behind the technical objections.

The Identity-First Approach to Technical Change

When facing power user resistance, remember:

1. Technical superiority isn't enough

2. Identity and status matter just as much (if not more than) features

3. Position the change as evolution, not replacement

4. Help them expand their impact, not diminish it

Success comes from helping power users see your product as a way to enhance their expertise, not replace it.

Hope that helps!

THAT’S A WRAP

Before you go, here are 3 ways I can help:

Take the FREE Learning Velocity Index assessment - Discover how your team's ability to learn and leverage learnings stacks up in the product-led world. Takes 2 minutes and you get free advice.

Book a free 1:1 consultation call with me - I keep a handful of slots open each week for founders and product growth leaders to explore working together and get some free advice along the way. Book a call.

Sponsor this newsletter - Reach over 8000 founders, leaders and operators working in product and growth at some of the world’s best tech companies including Paypal, Adobe, Canva, Miro, Amplitude, Google, Meta, Tailscale, Twilio and Salesforce.

That’s all for today,

If there are any product, growth or leadership topics that you’d like me to write about, just hit reply to this email or leave a comment and let me know!

And if you enjoyed this post, consider upgrading to a VIG Membership to get the full Product-Led Geek experience and access to every post in the archive including all guides.

Until next time!

— Ben

Thanks again to our sponsor: Inflection.io