It’s hard to sell tools to technical users because those users are very picky. 

Partially, this is because technical users can make their own tools in a way that the average B2B software buyer cannot; it’s hard to sell anvils to the blacksmith. Partially, it’s because technical users have an existing workflow and a mile-long backlog of things that were supposed to ship three weeks ago, and adopting a new tool is like making mechanical changes to a train while it’s in motion. The bar is very high.

As a result, a lot of technical products — even useful, well-made ones — languish in the purgatory of half-adopted tools. You’ve probably seen examples. The customer says a lot of nice things. They are ostensibly using the product. They might pay for a proof of concept (POC), or buy a few seats for a small internal team. But the product never really reaches the core use case that you want to win. The POCs drag on, the annual contract values (ACVs) stay small, the usage metrics stay lethargic…

Again, this can happen even when the product is really good. The problem is that customers don’t know that it’s good, and they don’t find that out soon enough or compellingly enough. Avoiding that is what we’re going to explore in this piece.

Magic moments

In the golden age of growth marketing (c 2011–2015), every third blog post was about Facebook’s “7 friends in 10 days” rule. The original Facebook premise was the proposition that “If we can get a new user to add 7 friends within their first 10 days, they’re much less likely to churn.”

Facebook’s success with this “magic moment” rule inspired countless other companies to look for their own early-lifecycle engagement metrics, and to push their users towards them. Sadly, a lot of this work was statistically misguided, and formed another chapter in the “Complete Collection of Ways That Correlation Is Not Causation,” with a lengthy footnote on Goodhart’s Law.

But: There’s a closely related idea that I do think is useful for technical products, and which I don’t think is a statistical illusion. I’ll call that a “magic moment” too, since the idea is so close to the original. 

The idea is not rocket science: Whatever is special about your product, whatever makes it 10x better than existing solutions — a new user needs to experience that as quickly and as frictionlessly as possible. 

This is really about getting “full credit” for what you’ve built; if you’ve built a great product, the user needs to feel that viscerally.

Obviously, the first step is building a great product. There’s no way to deliver a delightful user experience if you don’t have that. But once you have a product that you love, here are some tactics for delivering magic moments.

Put the ‘magic’ up front

If a new user tries your product and likes it, they’ll keep using it. If they don’t, they won’t. This initial trial might last as little as 15 minutes. If whatever makes your product special isn’t discoverable in that 15 minutes, and that initial experience is a slog, most users will never get to the good part.

You might think that this applies more to products that are directly adopted by ICs, rather than products that are sold to teams. But the difference is smaller than one might think. There’s a world of difference between an EM pushing down a product that the ICs want to use, versus one that they don’t.

The upshot is that you need to make the user feel what’s special about your product quickly. 

Make change as painless as possible

Users don’t want to change the way they work. Change is pain. 

Your product will, inevitably, make users change their workflows a little, which is bad enough. The unforced error is to make users change more than you have to. If adopting a new product means learning a DSL, writing a bunch of YAML configs, rewriting a bunch of existing code, etc. then the payoff has to be huge. 

The less the user has to change their existing workflow the more likely they are to give your product a chance.

Don’t put rocks in their shoes

Users will severely miss any productivity features that they currently rely on but that your product doesn’t yet support. 

As a toy example, let’s say that you’re building a better text editor for Vim users. It does a lot of things, but it doesn’t support arguments to the delete command `d`, so you can’t do `dw` to delete a word, `dtc` to delete everything until the next `c` character, etc. 

Your users, having the brainstem-deep muscle memory of Vim lifers, are going to type a lot of `d`-something commands that don’t work, and every failure will feel like a rock in their shoes. It’s hard to succeed with that handicap. 

The best shoe in the world plus a rock becomes the worst shoe.

End with something

Your users are going to use your product to make something, eventually. You should help them make something, immediately. 

And what you help them build should be complete, of value outside your product. If you’re building a data ingestion tool, you want the user to get a complete connector up and running. If you’re building a web app PaaS, you want the user to end with a working application and a public endpoint. 

Whatever the user ships, it should be something whose value they (and thus their peers) recognize as valuable on its own, independent from your product. 

Patrick McKenzie wrote an exhortation a while ago to “end the week with something;” users who try out your product should also feel that the ended with “something”.

A product philosophy

As you build your company, instill these end-users and all their desires and hangups into your product philosophy.

Don’t sell a blacksmith a new type of anvil — give them a welding gun.

Are you an early-stage founder? Check out more insights on pitching, leadership, financials, product, marketing and work from the BCV team in The Head Start.