Podcast

What AI Go-to-Market Engineering Looks Like in Practice

AI go-to-market engineering becomes useful when it stops being a collection of prompts and starts becoming a product built around how revenue teams actually work. Ethan Lippman leads revenue operations and AI GTM engineering at Alchemy, where his approach combines product thinkin

AI go-to-market engineering becomes useful when it stops being a collection of prompts and starts becoming a product built around how revenue teams actually work. Ethan Lippman leads revenue operations and AI GTM engineering at Alchemy, where his approach combines product thinking, contextual data, internal development, and a clear definition of the outcome the field needs.

His career prepared him unusually well for the role. He has worked in support, training, solution engineering, sales, product management, competitive intelligence, and RevOps. Each function taught him a different part of the same problem: how to put useful information and capability into the flow of work.

Product knowledge creates cross-functional leverage

Early in his career, Ethan studied a large product manual deeply enough to return from an internship with unusual command of the platform. That knowledge helped him move through customer support, training, demos, account management, and partnerships.

Knowing the product was not valuable only because he could answer questions. It let him see patterns across the customer lifecycle and propose new capabilities.

For RevOps teams, the lesson is that technical fluency should connect to the commercial motion. The operator who understands the product, buyer, data, and workflow can design something more useful than a generic automation.

Internal tools should meet people where they work

At Workfront, Ethan built Pete, a competitive-intelligence Slack bot that delivered battle cards, positioning, and product recommendations inside the tool sellers already used.

The design principle still applies: the best front door to information is often the place where the work is already happening. Requiring a seller to remember another destination creates adoption friction before the answer can help.

AI makes this more powerful because the interface can respond to a specific question. But the core requirement remains good product design: understand the user, the moment of need, and the minimum action required.

Build-versus-buy begins with core competency

At Alchemy, Ethan and his CRO made an intentional decision to build. They recognized that doing so required a real core competency, not a pile of disconnected point solutions, and hired an AI engineer with a specific profile.

The result became Elixir, an internal AI GTM platform. One use case is call coaching that can combine a transcript with deal context from Salesforce, emails, and internal sources.

This is the advantage of a bespoke internal product: it can be designed around the company's data and workflows without solving every edge case in the market. The tradeoff is ownership. The company must maintain the engineering, security, data quality, and product direction.

Context is the difference between a demo and a system

A language model can summarize a call. A useful GTM system needs to understand the deal, customer, product, prior communication, and objective.

That context comes from connected data and deliberate design. If the underlying records are incomplete or definitions conflict, AI can accelerate confusion. RevOps architecture still matters.

Teams should therefore begin with a narrow decision or workflow, identify the required context, and define how a person will evaluate the output. A dazzling prototype is not the same as a reliable operating capability.

Leadership intent gives builders room to solve

Ethan describes leadership through clear intent. A leader defines the mission and expected outcome, then gives capable people room to determine how to achieve it.

This model is especially useful in emerging work where a detailed playbook does not exist. It creates autonomy without ambiguity.

For AI GTM engineering, the intent might be to equip sellers with accurate, contextual coaching inside their workflow. That is a more productive direction than prescribing a tool before the team understands the user problem.

The practical lesson for RevOps teams

AI GTM engineering works best when teams:

  • Start with a real workflow and user need.
  • Deliver information where people already work.
  • Connect relevant business context, not only raw text.
  • Decide explicitly whether building is a core competency.
  • Treat data quality, security, and maintenance as product requirements.
  • Give builders clear intent and room to experiment.
  • Measure adoption and decision quality, not novelty.

The opportunity is larger than prompting. Revenue teams can build internal products that make their own operating knowledge easier to use.

About the guest

Ethan Lippman leads revenue operations and AI go-to-market engineering at Alchemy. His career spans customer support, training, sales, product management, competitive intelligence, RevOps, and internal AI product development.