Going to Market with Go-To-Market Engineering
Understanding the human component of AI transformation.
Abnormal AI stops the cyberattacks that legacy tools miss. If your company still treats AI like a pilot program, you’re in the wrong place. AI-powered engineering is our default, and we’re hiring.
In our previous posts, I walked through why we view our Go-to-Market systems as a product engineering problem and shared the puzzle of projects we’re building across sales, customer success, marketing, and operations.
While those posts covered what we build and how we build it, in our experience, those are actually not the hardest questions to answer.
How do you make any of it stick?
A widely cited 2025 MIT study found that roughly 95% of enterprise AI pilots fail to deliver measurable impact.
Most AI initiatives stall not because the technology doesn’t work, but because the people and processes around it never change.
We built this assumption into our plans from the beginning. Our hypothesis was that the order in which you introduce AI into a team’s workflow matters as much as the quality of the AI itself.
For example, auto-updating Salesforce fields after every call or auto-triggering account intervention workflows could have been built from day one. But, if an AI updates a CRM field behind the scenes before anyone trusts it, employees will double-check every entry, managers question the data in pipeline reviews, and people may spend more time verifying the AI’s work than they spent doing it manually.
You haven’t saved anyone anything. You’ve added a new chore.
So, how did we approach this?
Step 1: Earn “the right” to automate
We started with projects that were quick wins: highly visible across many users, tied to their quality of life, and easy to verify correctness.
AE Meeting Briefs. Before every external meeting, an AI agent pulls LinkedIn data, prior conversation transcripts, account history, open support tickets, and recent product usage into a personalized briefing document delivered to the rep’s inbox.
CSM Follow-Up Drafts. After a call, an AI agent identifies unanswered questions from the transcript, sources answers from product documentation and code, and drafts a follow-up email for the CSM to review and send.
None of these automations touch a system of record. They present a deliverable in front of a human who can verify its quality in one minute and feel that it saved them ten.
After a while, reps who initially ignored meeting briefs started asking where their briefing note was when one didn’t arrive. When we surveyed our CS org after a quarter of work, over 80% of the team responded, and 9 out of 10 rated the early automations "somewhat" or "very" useful.
People went from skepticism to enthusiasm and organically shared new ideas. Those expectations are what earned us the right to introduce higher-stakes work.
Step 2: Identify your “AI Champions” and bring them along
As we shipped more projects, a pattern became obvious. Every automation followed the same trigger-agent-action architecture we described in our previous posts, and the only thing that really changed from project to project was the prompt. So we factored out the common infrastructure into an internal tool where a builder picks a trigger, selects the tools, and writes their own agent prompt.
Not only did this reduce the marginal cost of developing a workflow automation, but more importantly, the internal tool expanded who gets to build.
Before it existed, every automation required an AI PM. Even when the work was fast, we were still a hop in the telephone game of idea to solution. Someone in sales or CS would describe what they needed, we would interpret it, build it, ship it, and iterate.
With the internal tool, GTM power users with fluency in writing prompts (or eagerness to learn) could build their own automations. A CS manager who understood their team’s workflow better than any outside builder could translate that knowledge directly into a prompt. An ops lead who spotted a gap in data hygiene could wire up an automation without filing a request.
We called these power users “AI Champions”.
AI Champions launched things faster because they didn’t need to wait for us to write a prompt.
They also got faster buy-in from their teammates since the automations were built by someone who worked beside them every day.
And, they started building automations we had never thought of.
The Meeting Attendee Wrangler is a good example. A CSM built an automation that fires a few days before any scheduled customer business review, checks which customer contacts haven’t RSVPd, and drafts personalized nudge emails to each one.
It was a simple specific solution to a real pain point that no AI PM had thought of yet. Once they mentioned it, we realized that the pattern (calendar trigger → attendee analysis → personalized outreach) generalizes well beyond customer success; every GTM rep wants to make sure that the right people are present for every meeting.
We now mine these emergent automations to figure out what to productionalize next.
To date, over 50 users across 10 GTM teams (spanning sales, customer success, operations, and leadership) have created more than 100 custom automations for use-cases we didn’t have the bandwidth to support yet, or never imagined.
The AI PM’s role evolved accordingly with this increased leverage: less time building individual automations, more time evangelizing the tool, onboarding AI Champions, and curating the best emergent ideas into hardened scalable systems.
Step 3: Reach for the high-stakes work
True success on steps 1 and 2 means that people trust that AI outputs are good enough to act on without second-guessing them.
That trust enables the highest-ROI opportunity: not just helping people do tasks faster, but globally prioritizing (with omniscient context) the highest-leverage tasks to do in the first place, and automating tasks themselves where appropriate.
Consider the end-to-end Customer Success workflow we described in our previous post.
Every week, an AI agent sweeps through all paying customer accounts, pulling from comprehensive data sources, and produces a prioritized list of accounts.
For each critical account, the system drafts a concrete action plan and fans out the specific tasks, like scheduling an executive touchpoint.
Opportunistically, the system also auto-completes tasks, like drafting a brief for an executive in preparation for that touchpoint.
None of that works if people don't trust the AI's judgment. If we had launched account health scoring on day one, reps would have spent more time arguing with the scores than acting on them.
But if they first experienced meeting briefs they could verify in a glance, then saw their colleagues championing AI automations and being included in the development process, the leap to "let the AI tell me which accounts need attention first" feels earned rather than imposed.
To realize this, we’re building a single surface where an employee sees the ranking of AI-suggested tasks ready to act on and already completed tasks.
It's a work in progress, but the foundational work of earning trust through months of lower-stakes automations is what makes the concept viable at all.
The Lesson: Go-to-Market Engineering requires a "go-to-market" strategy
This is what we mean when we say that building the technology is the easy part.
The hard part is designing the rollout so that every phase of building earns the human trust and process change required for the next one.
We’re still early; the highest-ROI automations are just now starting to materialize.
If you read this and want to help us turn this goodwill into meaningful ROI, my team is hiring :) .