jing
All posts

AI-First GTM

Adoption is the whole game

The most capable AI tool my team build got exactly zero users. Here's the super real and uncomfortable tradeoff, and the one rule that changed how I ship AI tooling.

A dense machine stops at a wall while a simple chat bubble passes through.

Table of Contents

  1. An example: my team built something breathtaking (and nobody used it)

  2. My Product Hunt launch proved the same thing on a different surface

  3. Frontier models accelerate the builder and exasperate the users

  4. Build to the adoption threshold, not the ceiling

  5. Does anyone have a test for this?

I hate this but I’ve watched a lot of AI tooling die. Not because it didn’t work. But nobody touched it.

The weird thing about building AI tools is that for the first time in software history, the marginal cost of adding capability to an AI system is nearly zero.

Another skill is one .md file. Another agent is one more prompt. Another tool integration is one more hour.

There is no natural guardrail pushing back on “let’s also have it do X.” Normal tooling has natural brakes. Engineering cost, infrastructure cost, maintenance burden. AI tooling doesn’t have any of those (assuming your token usage is on an enterprise plan or some other permissive plan).

The discipline has to come from somewhere else, because the system won’t give it to you. Here’s what I’ve found to optimize for adoption.

Thanks for reading! I build every day and publish every week so subscribe if you want to keep up to date.

An example: my team built something breathtaking (and nobody used it)#

Someone on my team hooked up a ton of data sources to enrich target accounts.

I’m talking third-party data, proprietary data, and real-time contact enrichment…all stitched together to show you exactly who you’re talking to and why in a single website with search.

The output was stunning. Breathtaking even. I’ve never seen anything like it and it looked like a dream.

You’d pull up a target account and see this rich, contextualized picture that would let you write hyper-personalized outreach in 60 seconds.

Then we showed it to the target audience, sales reps. Who basically thought it was an interesting experiment. They never used it.

You know what they did use and love?

A freaking saved prompt in Gemini. And a Claude project they could open and ask in natural language: “write an outreach email to prospect ABC.” Strictly less capability. Strictly less elegant. But the people that matter, the sales reps, started saying “this makes my life so much easier for outbound.”

The original AI tool wasn’t a mistake and the rollout didn’t go wrong. This is a story about the tradeoff between functionality and adoption.

My Product Hunt launch proved the same thing on a different surface#

When I launched the tech-marketing-framework on Product Hunt, the most common piece of feedback was: “does this work without Claude Code?”

I, as a ruminator, ruminated on this. Is it really a feature request? Or is that adoption friction speaking in the grammar of a feature request…

The audience wanted the value. They saw it clearly enough to ask about it. What stopped them wasn’t the framework’s content. It was the CLI surface it was delivered through.

The capability of the *delivery interface*, composable skills, agents, the terminal, was doing the same thing the over-engineered outbound tool did to the reps. It was raising the threshold users had to clear before any value appeared, and the ones who couldn’t clear it bounced.

Even if I believe the CLI surface is the correct delivery method, most the general audience do not agree. Oops.

Frontier models accelerate the builder and exasperate the users#

Just to say this out loud, vibe coding and building AI tooling is SO FUCKING FUN.

The models surprise you. The chains work. You watch the thing execute and there’s a real rush of holy shit, it worked.

Without an explicit brake, capability compounds faster than any real user can absorb it. The builder’s dopamine loop and the user’s acceptability threshold are on completely different clocks.

Build to the adoption threshold, not the ceiling#

Here’s my conclusion:

Capability added before adoption dies with the tool. Capability added after adoption compounds it.

That’s the whole thing. It boils down to:

  1. Build the smallest shape that clears the user’s threshold on day one.

  2. Earn the right to add capability by first earning the adoption.

Reversed, the tool doesn’t survive first touch. In AI specifically, where the default drift is toward more, this isn’t a style preference. It’s the only sequence that doesn’t leave you with a graveyard of powerful, unused systems.

Concretely, for non-technical audiences: lead with chat UI. Gems, Projects, Claude Cowork, whatever the user is already opening every day. Ship the low-threshold version first, let the value get felt by the most number of people.

For the power users and eager learners, don’t deprive them of repos, skills, agents, CLI. Take the time to walk them through the process once to unlock it for them forever. However, remember that while the terminal offers real power the reality is that it is also a wall.

Does anyone have a test for this?#

I don’t have a good acceptability-threshold test. Most of what I do is instinct after watching enough adoption fail.

Does anyone have a cleaner heuristic? Something you apply *before* you build, not after the reps say “neat”?

If you do, reply and share so we can all learn to be responsible builders.

this was first published on aifirstgtm.substack.com.