I stopped a product launch. Marketing was doing its job.

The technology had been created for a perfectly sensible reason.

We had an endpoint protection product that was causing issues in the field, and we needed better telemetry to understand what was happening when it updated.

The idea was fairly straightforward. Before an update ran, the new technology would check the state of the endpoint. Once the update had completed, it would check again. That would give us much better information about what had changed and, importantly, help us understand when something had gone wrong.

There was a genuine problem to solve, and the people who built it were trying to solve it in good faith.

There was just one fairly significant issue.

I didn’t think we should ship it.

A good idea with a bad delivery mechanism

Endpoint protection software operates in an unusually sensitive part of a customer’s environment. At a very basic level, part of its job is to change and remove files from endpoints.

Get that wrong and the consequences can be catastrophic.

We’ve seen very public examples of what happens when endpoint security updates go badly wrong. CrowdStrike’s 2024 outage is the obvious recent example, but the industry had been here before.

In 2010, McAfee DAT 5958 falsely identified svchost.exe, a legitimate and critical Windows system file, as malware on Windows XP SP3 machines. Depending on the action configured, the file could be removed or quarantined, leaving affected machines without network connectivity, stuck in reboot loops, or otherwise unusable.

I knew that incident particularly well.

I was at McAfee.

Customers have very good reasons to care about exactly what endpoint security software is doing to their systems.

Against that backdrop, the delivery mechanism for our new telemetry technology worried me.

Customers couldn’t properly control the installation. They couldn’t properly control the telemetry. Something they hadn’t explicitly chosen to install would arrive through an existing trusted process and then behave in ways they weren’t necessarily expecting.

There is an uncomfortable word for software that arrives through something you trust and then does something unexpected.

Trojan.

I wasn’t suggesting for a second that anyone had built one maliciously. They hadn’t. The intent behind the technology was entirely legitimate.

But intent wasn’t the issue.

I was looking at what our customers would see.

Our endpoints didn’t all live in the world we had designed for

There was another fairly fundamental problem with the telemetry model.

Not every enterprise endpoint can connect to the internet.

Some of the systems our customers protected were deliberately isolated. If you’re running an internal server that should never communicate with the outside world, software repeatedly attempting to send telemetry externally isn’t merely pointless.

At best, it looks odd.

Depending on the environment, it could create alerts or raise entirely reasonable questions about why a security product was attempting network activity that nobody had expected or authorised.

From inside the company, we knew exactly why it was happening.

The customer didn’t have that context.

That’s an important distinction.

The communications plan wasn’t going to fix it

The proposed approach was essentially to tell customers that the technology was coming and explain why we were doing it.

I didn’t think that was enough.

The problem wasn’t that we hadn’t found the right words to explain the technology. We hadn’t done enough to understand what customers would need in order to make the technology acceptable in their environments.

Could they centrally control which machines received it?

Could they decide whether it ran at all?

What happened in environments without internet connectivity?

Could they control the telemetry?

How would this behaviour appear to their own monitoring and security controls?

Those weren’t messaging questions. They were product questions.

And no amount of beautifully crafted launch communications was going to turn them into messaging questions.

So I stopped the launch.

Saying no wasn’t enough

Stopping something is easy if all you’re bringing to the conversation is an objection.

I needed to know whether I was right.

So I went to customers and asked them.

I talked to them about the technology, how it would work, and what they would need in order to be comfortable with it in their environments. Their feedback helped us understand where the gaps were and what needed to change.

I also took the concept to a major external analyst firm to get a wider view. I wanted to pressure-test whether this was simply a concern among the customers we’d spoken to or whether the problem stood up when looked at across the broader enterprise market.

It did.

The launch stayed stopped.

We went back and worked on the features and controls customers needed, alongside a communications plan that reflected how the technology would really be received and operated in enterprise environments.

Then we could think about taking it to market.

Marketing isn’t there to make every decision look exciting

There’s a version of marketing where the product gets built, the launch date gets chosen, and marketing’s job begins when somebody asks for the messaging.

I don’t think that’s good enough.

If you’re leading marketing and you understand the product, the customers, and the market, you’re in a position to spot problems that sit between all three.

That doesn’t mean marketing should dictate the product roadmap, and it certainly doesn’t mean marketers should wander around engineering organisations vetoing things they don’t understand.

It means marketing should understand enough to ask difficult questions when something doesn’t add up.

In this case, the question wasn’t whether the technology worked as designed.

It was whether customers would accept the way we planned to put it into their environments.

That’s a go-to-market question, but answering it changed the product.

Sometimes stopping the launch is the commercial decision

Delaying a launch is uncomfortable. People have put work into the product. Plans have been made. Dates may have been communicated internally. Nobody particularly enjoys being the person who arrives and says we’re not ready.

But the alternative here would have been worse.

We could have shipped the technology and explained afterwards why customers shouldn’t be concerned about behaviour they hadn’t expected.

We could have asked account teams to manage the objections.

We could have discovered through complaints what we could have learned by talking to customers beforehand.

Instead, we asked before we launched.

The answer wasn’t “don’t build this”.

The underlying idea was good.

The answer was that if we wanted customers to accept it, we needed to build it in a way that worked for their environments, give them the control they reasonably expected, and communicate with them properly about what was changing and why.

That’s not marketing getting in the way of a product launch.

That’s marketing doing its job.