Marketing DevTools
to AI/ML Engineers.

Why ML engineers buy differently

An ML engineer evaluating a tool runs a different process than a generalist developer evaluating a tool. The shape is similar — docs first, hands-on second, peer reference third — but the artifacts are different in ways that matter. The hands-on step is an eval against existing data, not a quickstart against a sample. The peer reference is the MLOps Community Slack or a researcher's blog, not a Hacker News thread. The pricing question is "what will this cost me at 10x volume" rather than "how many seats do we need."

The audience overlaps with generalist developers at the edges (full-stack engineers who occasionally call an LLM API are closer to generalist developers than to ML engineers; ML research engineers shipping production models are closer to the inverse). The DevTools company entering the segment has to decide which sub-segment it is selling to and write the artifacts accordingly. Trying to serve both with one set of artifacts usually produces copy that reads accurately to neither.

The developer-first PMM playbook's spine still applies. Latent Space is the closest thing the ML tooling field has to a daily-read trade publication, and Eugene Yan and Chip Huyen are the closest thing it has to canonical voices on applied ML systems. Reading either for two weeks is the fastest calibration available to a DevTools team entering the segment.

Generalist DevTools playbook vs ML-engineer-specific playbook

Same playbook spine; different artifacts, prices, and channels. The comparison below names the axes where the ML segment's behavior diverges enough that the same artifact does not work for both audiences.

The shared spine is bottoms-up adoption inside a developer-first audience. The artifact set diverges enough that the team running both motions has to decide deliberately which surface owns which artifact.

Evals are the trust artifact

The ML field has watched enough benchmark inflation, training-data contamination, and overpromised performance numbers to be reflexively skeptical of any vendor claim presented as a single metric. The trust artifact that has emerged is the eval — a reproducible procedure that runs against the buyer's data, produces a measurable result, and discloses its baseline and failure modes.

A good eval-driven trust artifact has five components. A methodology document explaining how the eval is constructed and what it measures. A baseline (usually the buyer's existing tool or a published reference model). A dataset, or a procedure for assembling a comparable one on the buyer's data. The eval results themselves, including failure modes and the conditions under which the tool underperforms. And the code to reproduce, ideally as a runnable Hugging Face Space or a notebook that can be cloned.

The DevTools companies winning the segment all publish artifacts of this shape. The companies that publish a benchmark number without the underlying procedure are read as marketing-first, which is approximately the worst signal an ML engineer can receive about a tooling vendor. Simon Willison's practitioner-grade writing on evaluating LLM tooling is a useful reference for the bar; it is the kind of writing the audience expects from a credible vendor.

Pricing for the ML audience

Per-developer-per-month pricing reads as out-of-date the moment an ML engineer sees it. The audience is operating with cloud-provider mental models — unit economics, cost attribution, FinOps. A pricing structure that hides the unit cost (or expresses it in seats) signals that the vendor has not built the product for this audience.

Token-based pricing. Pay per input and output token, typically with tiered rates for higher-volume customers. The pattern OpenAI established and Anthropic, Together, and most inference-platform vendors have adopted. Clear unit economics, easy to compare, scales with usage. The downside is the buyer needs cost-attribution tooling to allocate spend across teams or features.

Per-run pricing for eval, training, or pipeline tools. The unit is a single eval run, training job, or pipeline execution. Useful when the workload is bursty and the developer audience expects to pay for compute they actually consume.

Hybrid: compute plus orchestration. Some platforms charge for the orchestration layer separately from the compute, which lets the buyer optimize spend at two layers independently. Common in MLOps platforms where compute is bring-your-own and the platform charges for the workflow management.

The non-negotiable feature regardless of structure: cost-attribution by team, environment, or feature, surfaced in the product itself. The FinOps-for-ML conversation is mature enough that buyers will ask about this in the first technical evaluation; tools without it lose the deal regardless of the rest of the product's quality.

Distribution: where ML engineers actually discover tools

The channel mix overlaps with generalist DevTools at the edges but is meaningfully different at the center.

Hugging Face Hub and Spaces. The de facto model hub and the practical center of the open-source ML ecosystem. Distribution through the Hub is, for many ML tools, the primary activation surface — analogous to GitHub for generalist DevTools. A demoable Space that lets an engineer run the eval in the browser is one of the highest-converting top-of-funnel artifacts available.

Latent Space, individual researcher blogs. Swyx and Alessio Fanelli's Latent Space covers the tooling ecosystem with the kind of practitioner depth the audience trusts. Individual writers (Eugene Yan, Chip Huyen, Simon Willison) outrank vendor content for many category queries because the audience trusts their judgment and engineers cross-link to them in internal discussions.

The MLOps Community. The Slack and conferences are where ML engineers compare notes on what works in production. Peer reference happens here in a way it does not happen anywhere else; a positive thread is a meaningful signal.

Conferences. NeurIPS and ICLR for research-adjacent products. MLSys for systems-and-infra products. MLOps World and PyData for operational tooling. A single accepted talk at the right conference compounds for twelve months. The talk has to be a technical talk, not a pitch — the audience identifies pitches in the first three slides and tunes out.

Hacker News. Still works for ML tooling, but the signal is weaker than for generalist DevTools. The audience that activates from HN for an ML tool skews toward the AI-curious software engineer rather than the working ML engineer. Useful for amplification; weaker as the primary discovery surface.

Common mistakes entering the ML segment

1. Treating ML engineers as generalist developers. Same job title, different buying behavior. The artifacts that activate a generalist developer often miss the ML engineer entirely.
2. Shipping a benchmark instead of an eval. Benchmark numbers without reproducible procedures read as marketing. The audience is reflexively skeptical of single-metric vendor claims.
3. Pricing in seats. Per-developer-per-month signals that the company has not built the product for an ML audience. Token, inference, or run-based pricing is the table-stakes alternative.
4. Hiring a DevRel from outside the ML community. The audience identifies an outsider quickly. The credibility hire has to come from inside the field; the GTM operator can come from elsewhere.
5. Skipping Hugging Face distribution. The Hub is where the audience expects to find new tools. A product that is not discoverable there is harder to evaluate, even when it is technically superior.
6. Ignoring cost attribution. The FinOps-for-ML conversation is mature. A pricing structure that hides unit cost or skips cost-attribution features signals that the vendor has not understood the buyer's budget context.

The author

Daria Dovzhikova is a fractional PMM with 12 years inside developer-first companies, including 7 years at JetBrains and senior roles at Lightrun and Odigos. The ML-tooling overlay on the DevTools playbook is the focus of much of the consulting work she has run in the last two years, as observability, debugging, and developer-experience companies have extended into the ML segment. See services or about for the wider engagement formats.

For ongoing calibration on what the ML audience reads as credible vs. as marketing, Latent Space and Eugene Yan are the two highest-leverage subscriptions a DevTools team entering this segment can make.

Related reading

• Developer-first PMM — the playbook spine the ML overlay extends from.
• Developer marketing — the channel mix the ML-specific channels sit alongside.
• Product-led growth — bottoms-up activation, still the precondition.
• How to launch a developer tool — the launch playbook the ML segment adapts.
• Case studies — DevTools-meets-ML GTM work I have run.