We've Seen That Movie, Part 2: The Appearance of Progress

Tom Williams, CEO

When launching a sequel, the obvious temptation is to blindly follow the assumption that whatever worked the first time will work even better if you dial it all up a notch: bigger budget, bigger cast, bigger set pieces.

Which, as it happens, is not a terrible description of how technology marketing sometimes works.

In Part One, we looked at alignment, program design, and community. This time, we’re interested in something slightly different: the appearance of progress.

Because some of the most convincing signs of momentum are not necessarily evidence that the underlying system is working: a product launching before the surrounding experience is ready to support it; a campaign generating enormous engagement, but little corresponding adoption; a company copying the visible features of a successful developer program without understanding the conditions that made them effective in the first place.

From the outside, all three can look like success. The gates are open. Everyone is talking. The trick gets applause.

But launches can look like readiness. Engagement can look like adoption. Imitation can look like capability.

Part Two is about the gap between the visible effect and the machinery underneath it.

Three absolute bangers, plenty of smoke and mirrors, and, in at least one case, a dinosaur theme park apparently supported by a single network security consultant.

What could possibly go wrong?

We are so back.

Jurassic Park

When I first saw Jurassic Park in 1993, it was a cool film about dinosaurs.

Viewed again thirty years later, it seems much more about corporate overconfidence, systems failure, and what happens when technical achievement is mistaken for readiness.

John Hammond, played by Richard Attenborough, has brought dinosaurs back to life, built an island around them, and assembled a group of experts to admire the result. The scale is breathtaking. The ambition is bonkers. The branding is superb.

The problem is that Hammond treats the existence of the product as proof that the system surrounding it must also work. Security, governance, staffing, incentives, maintenance, and contingency planning are all secondary to the fact that the dinosaurs are there. The island also appears to have just one IT guy, and a security system that can be overridden by a child within minutes — not an especially reassuring operating model for a theme park full of genetically engineered predators.

Ian Malcolm (Jeff Goldblum) sees the problem immediately. The park’s creators have acquired extraordinary power without developing the discipline or responsibility required to use it. They have taken the work of others, sped toward the most spectacular possible outcome, and moved almost immediately from discovery to ownership, packaging, and sale.

The dinosaurs work. The park does not.

Same Plot, Different Cast

The Developer Marketing Version of Jurassic Park:

Technical achievement is not the same as operational readiness.

Technology companies sometimes launch products in much the same way Hammond opens the gates to Jurassic Park: the core capability exists, the demo works, the launch date is fixed, leadership is excited, and marketing is already preparing the story.

From the inside, that can feel like readiness. From the user’s perspective, it may only be the beginning.

Can they understand what the product is for? Can they try it without speaking to sales?

Can they find the right documentation? Does onboarding reflect their actual journey? Are pricing, permissions, authentication, and support designed for the audience being asked to adopt it? Does anyone own the experience once the campaign has done its job?

A product can be technically impressive and still be practically unusable.

This is particularly common in developer marketing, where the distance between interest and adoption contains dozens of small points of failure. A developer clicks through from a campaign and cannot find the relevant docs. The sample code is out of date. The quickstart is not particularly quick. Access requires an approval process nobody has explained. The product works in the sandbox but falls apart when it meets a real stack, a real security team, or a real procurement process.

None of those problems necessarily belong to marketing. That does not mean marketing can ignore them.

When the surrounding experience is weak, the temptation is to keep working on the visible layer: refine the message, boost the reach, produce more content, and drive more people toward the product.

But more traffic only sends more people into the same broken experience.

The launch itself can make this harder to see. Internally, it creates a moment of completion. The announcement goes live, the event happens, the campaign ships, and everyone moves on to the next priority.

Externally, the audience has only just encountered the product.

The organization experiences the launch as an ending; the user experiences it as the start of an evaluation.

That gap is where a great deal of adoption is lost.

The lesson from Jurassic Park is not that ambitious products should be held back until every possible problem has been solved. If we followed that logic, nothing would ever launch.

Instead, the lesson here is that the spectacle of the launch can conceal how much of the real work remains unfinished.

The product does not exist independently of the system around it. Documentation, onboarding, support, governance, pricing, reliability, and the handoffs between teams are all part of the experience.

Launching the product does not, by itself, mean it is ready for real users.

Changing the Ending

The answer is not endless delay in pursuit of perfect readiness. It is to treat launch as the beginning of an operating system, not the end of a build.

Before creating demand, map what happens when demand arrives. Follow the path from awareness to evaluation, trial, integration, and sustained use. Identify where ownership changes, where users are likely to stall, and which parts of the experience are relying on assumptions rather than evidence.

Marketing should not be expected to fix every product or operational problem. But it should be close enough to the full journey to recognize when the barrier is no longer the message.

The strongest launches connect the promise to an experience capable of delivering it.

Opening the gates is not the same as being ready for visitors.

Snakes on a Plane

I’ll confess that I haven’t actually seen Snakes on a Plane. But that is kind of the point of this one.

We know Samuel L. Jackson is on a plane. We know the plane is full of snakes. We know his infamous line of dialogue, even if it is not repeatable on the Catchy blog. In other words, we feel we know the movie without having actually seen it.

That was the strange achievement of Snakes on a Plane. Before it became a film that a few people had watched, it became a film people felt they already knew.

The title was gloriously literal, the premise was instantly legible, and the internet did the rest. It spawned memes, parody trailers, songs, fan art, and imagined dialogue. The attention became so loud that the studio actually went back and changed the film to better resemble the version the internet had already invented.

The engagement was real. But ultimately, the moviegoing audience was far smaller than the hype had suggested.

Everyone knew the movie. Far fewer people felt the need to go and see it.

Same Plot, Different Cast

The Developer Marketing Version of Snakes on a Plane:

Engagement is not adoption

Technology marketers are understandably drawn to signs of engagement: people sharing the campaign, social posts generating replies, developers joining the happy hour. The product has escaped the company’s channels and entered the wider conversation.

This is all good. It is certainly better than being ignored.

Engagement tells us that people found something interesting enough to respond to. But it doesn’t tell us that they found the product useful enough to adopt.

That distinction becomes especially important when the marketing is more immediately compelling than the thing being marketed. A sharp campaign, a provocative launch line, or a highly legible product story can generate substantial attention while leaving the audience with no clear reason to take the next step in the adoption journey.

We see this with tech launches that produce strong reach, enthusiastic event participation, and impressive social numbers, but subsequently little corresponding movement in trial, integration, or sustained use. The campaign has succeeded on its own terms; the problem is that those terms were never properly connected to the outcome the business needed.

Part of this issue is measurement: engagement is visible almost immediately, whereas adoption is slower, less tidy, and often distributed across several systems.

Views, shares, registrations, and attendance are easy to report. But actual adoption may require someone to explore the documentation, create an account, secure internal approval, complete an integration, and continue using the product weeks later.

Few teams can see that entire journey. Campaign data sits in one system, product usage in another, and commercial outcomes somewhere else. The visible metric therefore begins to stand in for the meaningful one.

The internet’s response to Snakes on a Plane was not fake. People genuinely enjoyed the idea and participated in the phenomenon. The mistake was assuming that enthusiasm for the conversation would convert automatically into enthusiasm for the product.

Developer marketing contains plenty of similar gaps. A developer may enjoy a technical stunt without wanting the tool behind it; attend a webinar because the subject is interesting, but have no authority to introduce the product; or share a report without ever entering the buying journey.

None of that makes the engagement worthless. It simply means we need to understand what it is worth.

The question is not whether people responded. It is what that response made more likely to happen next.

Changing the Ending

The answer is not to make marketing less engaging. It is to design a credible route from attention to action.

That starts by defining the next meaningful behavior: exploring the documentation, beginning a trial, completing a first integration, or introducing the product internally.

The promise, the call to action, and the product experience need to belong to the same story. We also need to measure the handoff: who took the next step, where they stalled, and whether the campaign reached an audience capable of adopting the product.

Engagement matters, but it is still only part of the journey.

With Snakes on a Plane, everybody knew the movie. Not enough people bought a ticket.

The Prestige

The Prestige is a film about rival magicians, obsession, and the difference between seeing an effect and understanding how it was achieved.

Every magic trick has three acts. First comes the pledge, where the magician shows you something ordinary. Then the turn, where that ordinary thing does something extraordinary. Finally comes the prestige, where it is brought back, transformed, and the audience applauds.

What the audience sees is the effect. What it does not see is the engineering, sacrifice, repetition, and, in the case of The Prestige, a fairly alarming amount of collateral damage required to make it convincing.

That hidden machinery is really what the film is about. The trick matters, but the conditions that produce it matter more. Because the audience only ever sees the polished result, it is easy to assume that reproducing the visible effect means understanding how it was done.

You can try to copy the trick. But without the machinery underneath it, all you have is a man in a cape waving his hands around.

Same Plot, Different Cast

The Developer Marketing Version of The Prestige:

Companies often copy the visible features of successful developer programs without understanding the conditions that made them work.

Technology companies are very good at noticing what other technology companies do well: elegant documentation, a thriving Discord, a pithy tone of voice, an eye-catching conference booth, an upbeat DevRel team, a cool ad, or an in-platform copilot that appears to make everything effortless.

Then they try to reproduce it.

This is understandable. The visible program is right there. You can examine the website, join the community, study the content cadence, attend the events, and count the advocates on LinkedIn.

What you cannot see quite so easily is everything going on behind the scenes.

The product may have been designed for self-service from the beginning. The documentation may be treated as part of the product rather than a marketing asset. The company may have spent years earning trust with a particular audience. Its developer advocates may have had genuine influence over the roadmap, and its community may exist because users already have a long history of learning from one another.

The visible effect is only the final act.

Underneath it sits product quality, market timing, audience fit, internal authority, technical credibility, sustained investment, and a great deal of accumulated history.

Copying the surface without those conditions tends to produce something that looks familiar but behaves very differently. A company launches a community because another company has one, adopts the same tone, sponsors the same events, builds an in-platform copilot, or creates the same kind of ambassador program.

The pieces are all present, but the result still does not work.

Successful programs are systems, not collections of recognizable parts. The community depends on the product; the content depends on the audience; the tone depends on credibility; and the DevRel team depends on having enough authority to do more than distribute approved messages.

Remove those conditions, and the trick stops being convincing.

Worse, the imitation can create new problems: a developer voice the company has not earned the right to use, a community it cannot maintain, or a polished program with no clear role inside the organization.

Developers usually notice. They are particularly good at distinguishing between something built for them and something arranged to look as though it was.

There is plenty to learn from successful examples. The mistake is treating the visible output as a transferable formula.

The useful question is not, “How do we build our version of their program?”

It is, “What conditions made their program work, and which of those conditions exist here?”

Changing the Ending

The answer is not to stop learning from successful developer programs. It is to look beyond the visible effect.

What conditions made the program work? What role did the product play? What had the company already earned with the audience? Which capabilities were built over time, and which depended on real authority, investment, and trust?

Then borrow selectively. Take the principle, not the costume. Adapt the operating model, not merely the appearance.

There is nothing wrong with learning the trick.

But unless you have also built the machinery, you are still just a man in a cape waving his hands around.

We've Seen That Movie

The problem with the appearance of progress is that it is often convincing enough to delay the harder questions.

In Jurassic Park, the dinosaurs exist, the gates are open, and the merchandise is ready before anyone has properly worked out whether the park can operate. In Snakes on a Plane, the film’s pre-release noise became so loud that it was easily mistaken for an actual audience. In The Prestige, the visible effect is so compelling that everyone forgets to ask what machinery and sacrifice made it all possible.

Developer marketing has its own versions of all three.

The product has launched, so everyone assumes it is ready. The campaign is generating attention, so everyone assumes it is working. The program resembles the admired example, so everyone assumes the same results will follow.

The answer is not to distrust launches, engagement, or inspiration from companies doing excellent work. It is to be more precise about what each one actually proves.

A launch proves that something can be released. Engagement proves that something attracted attention. A polished program proves that the visible parts have been assembled.

None of them, by themselves, proves readiness, adoption, or capability.

Part Two has been about looking beyond the effect to the machinery underneath it.

Next time, we turn to money and numbers: budgets that have to be spent, metrics that make everything look reassuring, and production systems that keep moving because nobody wants to be the person who switches them off.

As always, if any of these plots sound familiar, we’re always up for a chat.