Stop Demoing Your AI Rollout. Find the Unavoidable Project.

From everybody’s perspective, if I’m a developer on a team, it’s not unavoidable right now. I don’t really have to use it right now. I can keep on developing. And at some point, somebody might tell me you have to use it. If I’m told I have to use it, then that’s the only reason I do it. Because it’s mandated. And I still don’t feel the pull.

How will that resistance manifest itself? I’ll just use tokens: I’ll use it, I’ll do some demo, but I won’t really believe in it. I’ll go through the motions.

One path that leaders often take is to follow initial promising results with a mandate to follow new ways of working throughout the organization. This brute force approach can work in some environments but more often stalls. One frustration is that if you don’t mandate, people don’t change.

A lot of the things that I do is to take concepts that people use in other domains and apply them to change management. In the world of product, you cannot really push a product. You can try, but people buy when there’s pull.

What does that mean? People buy your product when there’s something that they’re trying to do that’s unavoidable right now, and the options they look into are lacking. They look at options, and they only find lacking options. When that’s the case, they will pull from you, whether you are the transformation consultant on the outside that’s selling services, or a transformation coach on the inside, trying to sell change.

Change is a Product. It should be customer-centric, designed for the context. As long as the transformation you’re trying to “market/sell” internally is nice to have, you’re not going to have much success. You will be stuck in the “pain cave”, struggling to convince people to transform and tempted to use brute force.

Giving demos is not gonna get people to change. One of the things that Rob Snyder says is you can’t sell a product by demo. Product demos are a waste of time.

Our role as change agents is to assess pull, and to create pull. You need to find what are the unavoidable projects that your product will help people do. You need to find the people that have an unavoidable project that they cannot currently do well. I couldn’t care less about proving the concept. It’s not about the solution. It’s about: do people have a problem that they need this for?

So what are the examples of pull that did happen? What are the case studies? Was it a feature that we needed to develop very fast? What couldn’t we do without AI? Find the case studies inside the organization where the transformation addressed a must-have to-do list item. Use these case studies to sell/market the transformation and look for similar opportunities where it could potentially be a must-have.

Some people are early adopters, the way they’re wired. There are the innovators, the people that will do something just because it’s new. The early adopters are different.

The early adopters are exactly the people that have pull. They have such a big problem that they’ll be willing to use your product even though it sucks. Not because they’re willing to try new things. It’s a combination of: they’re willing to try new things, and they have an unavoidable project that they don’t have a good solution for. So they’re already doing some things that are workarounds. This would actually make their life better.

Every time you’re trying to drive a product to market, that’s the first group that you need. And if there’s no problem in the audience, you have no chance.

In order to cross the chasm between these early adopters and the early majority, that needs proof and proper solutions, there’s a whole body of work on a full kit. That’s where you need the playbook. That’s where you need to show successes from others. Show the small wins.

But it doesn’t make sense to try and cross the chasm before you get to zero to one. To initial product-market fit. So it’s different stages of the product life cycle. And a lot of the time in organizational transformation, we’re just saying, yeah, let’s do it for everybody.

If you force a solution that is not ready for the mainstream, you kill its credibility.

I agree that at some point, the organization will create the context where people will understand: jump on the AI wagon, or you don’t have a role in the industry. Like, it’s happening, it’s unavoidable. You need to learn how to work with AI.

But it might be the case that people actually have pull right now, and they’re refusing the CLI because it really sucks. It’s hard to use. So maybe if the solution gets improved a bit, we’ll be able to serve this pull.

I know the dynamics of what the developers are really saying and where they are, but that’s part of the empathy that you need to build in. If it was your role to drive the adoption of the CLI, that’s where you would need to think about it. Do we have pull, and the problem is the solution? Do we lack pull? Where are we stuck? Those are some of the conversations that need to happen.

You can apply all of the product thinking. You can think about product metrics and telemetry. Our metrics essentially look at: are we acquiring potential users internally? Are we activating them? Like, in the case of the CLI, are we building a list of people that want to try it? Are we able to give them access quickly enough? Are they continuing to use it after they ran it for the first time? Or are we churning these people?

If we’re churning people very quickly, it doesn’t make sense to bring in new ones until we make the solution better. If we’re not even getting to the point that we’re activating people, it’s not about the solution necessarily. It’s about, you know, is there enough pull?

Are we getting people to get value from this? Are we getting people to refer, to bring others? Are people asking for this because they’ve seen other people do it? That’s the ideal scenario that you want to have.

It might take more time than brute force, but after a couple of home runs on critical opportunities, your constraint will be keeping up with demand.

If your AI rollout is running on demos and mandates, let’s talk about finding the pull first.