I'm currently building the GTM and Growth Engineering team (25+ people) at Tractian - Manufacturing AI copilot, Forbes 50 AI company, $200M+ raised from GC and Sapphire. I was a board member / investor of the company before joining full time. It's an unbelievable team and a product that is second to none in the market.

Before this, I was a Partner at N47, a $2B VC early-stage fund investing in GTM tech and vertical AI. I cut my teeth at Tumblr and Merrill Lynch earlier in my career. I went to Berkeley, grew up in Hong Kong, and now live in the SF Bay Area.

My daily fuel is Osmanthus Oolong tea and Nitric Oxide. The canto dinner spot with the best price/performance ratio right now is Porridge and Things in Millbrae.

GTM Eng Handbook

where's the leverage point in your GTM engine right now?

Chapters

1. 01

   Everyone wants GTM multi agent systems

   don't over think it. Start with an all purpose GTM AI Agent

2. 02

   The Frequent Rub on GTM Engineering Folks

   "Aren't you guys just data and systems/process nerds?"

3. 03

   What a F*cking Swing Looks Like: A Golf Business With Zero Staff

   the fundamentals of taking bets, whether it's GTM eng or building a services business

4. 04

   Vibes Based Rollouts + Enablement

   coming soon

Everyone wants GTM multi agent systems

Every company wants their AEs, CSMs, and other non-technical ops users to use AI agents to "increase productivity." There's a common temptation to jump straight to purpose-built agents for every use case - a coaching agent, a BI agent, a forecasting agent, all at once. But if your organization is starting from ground zero, I highly recommend starting with an all-purpose GTM agent focused on a basic principle: information retrieval. How can a rep get the information they need in a single query instead of 10+ clicks across multiple applications?

At this point there's a very real build vs. buy decision. I respect Glean, but they're extremely expensive if you want full org coverage, and it'll take a while to set up. At Tractian, we made the build decision with no regrets.

That's the bet behind Jimmy Neutron, our internal GTM agent. Instead of shipping six specialized bots, we built one general purpose brain in Slack, wired via an MCP tool executor into Gong, CRM, our internal industry knowledge base, and the enablement drive.

We're at 200+ WAUs and growing as of mid 2026, 6 months after beta launch. Getting that first agent widely adopted comes down to three things we hold ourselves to: it has to be fast, fluid, and familiar. Miss any one of those and you don't get strong adoption, and you've wasted all those precious GTM Eng hours. Here's how each of the three F's mapped to our build decisions:

• Fast. Deals evolve constantly, so a RAG setup querying stale embeddings would have meant slow, second-guessed answers. We went tool-based instead. The model calls a live function against Gong or HubSpot in real time rather than searching a static index.
• Fluid. One agent, a dozen different asks: pre call briefs, live deal recaps, closed lost mining, pipeline hygiene, new hire coaching, churn risk flags. Reps shouldn't have to remember which bot handles which question; it should just be the one they always go to.
• Familiar. We put it in Slack, not a new UI. Reps already live there all day. Meet people in the tool they already open by habit.

The part that actually took a lot of discipline wasn't adding capability - it was writing down what Jimmy explicitly won't do yet: no write back to HubSpot, no CSV exports, no cold email copywriting, no lead scraping, no legal redlining, no scheduling. Not because it's technically impossible, but because a general-purpose agent's job is to prove out one thing: fast, fluid, familiar access to context before it's allowed to sprawl.

That restraint is what makes the roadmap work. Phase 1 ships the one general agent to every AE, CSM, and RSD. Only in Phase 2, once usage shows exactly where the leverage actually is, do we branch into purpose-built agents, each inheriting the ever-improving data layer the general agent already validated in the field.

The lesson generalizes past Tractian: ship the fast, fluid, familiar agent first, and let real usage tell you which of its jobs deserves to become its own specialized build.

The Frequent Rub on GTM Engineering Folks

"Aren't you guys just data and systems/process nerds?"

Thanks, bud.

It's a most common assumption made about GTM Engineering teams. And those people are not entirely wrong, because we do live very deep in the data and the systems. But treating that as the whole job is where the stereotype comes from, and it's something I've found myself actively working to disprove with my team.

I see a lot of great content about AI agents and automation in GTM right now. I see a lot less about the core principles that actually make a GTM Engineering team succeed. For me, that means staying focused on ground truth, what's actually happening with customers and on the frontline, instead of leaning on qualitative assumptions or data assumptions alone. Both fail the same way if only done independently: quant without ground truth, and gut without evidence. There's a great quote from Leo Vieira, Tractian's COO: "If the terrain doesn't match the data, trust the terrain."

How I operate and my expectations of the team:

• Stay close to the frontline. Customers, Sales, CS, Gong, product analytics. The frontline shows up in a lot of forms, and we try to touch all of them, not just the ones that live in a dashboard.
• Collaborate + communicate with our team leaders globally. Systems built in isolation from the people running the regions don't get adopted or survive. They have important insights that can usually be incorporated into system builds and rollouts. You don't want to miss out on those.
• Leverage industry best practices. Very rarely are we inventing GTM playbooks from scratch. There is a strong case to understand what is working well at other high growth companies and adapt it to how Tractian actually sells. There are certain extremely strategic and high leverage projects where we spend a lot of time pushing the boundaries on what is possible (I'm not revealing what those are on a public website like this). You don't need that to be the case for every single GTM eng project.

The frontline principle is the one that does the most work against the stereotype, because it's the easiest one to fake with a Slack message and the hardest one to fake in person. In the last few months alone, more than half of my team put on hard hats and steel-toe boots to step onto our customers' factory floors. They do it to translate real-world context into better systems, processes, and experiences for the company.

Spending time with customers does something a query can't. It's a powerful reminder of the mission we're actually on. It's a lot harder to call someone "just a data and systems person" when they were standing on the same factory floor as the customer three weeks ago, watching the exact problem the dashboard is trying to describe.

What a F*cking Swing Looks Like: A Golf Business With Zero Staff

I usually write about GTM engineering, and this one is a bit different. It's about the fundamentals of taking bets, or swings, which apply whether you're running a GTM engineering team, building a startup or operating a business. I'll use a story from Hong Kong to get there.

I recently talked to Tony, who runs an indoor golf business in Hong Kong with no staff. You unlock your booth through an app, and nobody works inside. He has five branches so far. He doesn't play golf, and he had never run a business before this one.

Three things stood out to me, and each one is a question to ask before you take a swing of your own.

1. Find a technology or GTM insight that creates a step function in the unit economics

Most services businesses are labor businesses. A traditional indoor golf venue needs someone at the front desk, someone running the bar, someone to fix problems, and every booth-hour you sell has to pay for them.

Tony took the people out. The app handles booking, payment and the door lock. A new branch needs a lease, a build-out and some simulators, but no hiring and no training. Most companies add an app to a traditional model and end up with a nicer booking flow and the same cost structure. He removed the biggest cost line entirely.

I don't have Tony's actual numbers, so I built a ballpark from public industry benchmarks. Take a 4-booth venue open 14 hours a day, booked 40% of the time, at $50 an hour (roughly what Hong Kong's premium studios charge). That is about $34K of revenue a month either way. Here is what happens to the P&L:

Illustrative, in US dollars. "Everything else" is utilities, insurance, software, maintenance and marketing. "No staff" labor is a part-time cleaner.

Same booths, same customers, same price. Profit more than doubles. And because the build cost is about the same, it changes how quickly a branch pays for itself:

A payback of about a year and a half is what lets a first-time founder open five branches. Each new location earns its money back quickly, so one bad quarter doesn't threaten the business. The no-staff model also has a lower break-even, which matters in year one, when venues are typically only booked about a third of the time.

2. Competition comes from the market, and Hong Kong is unusual

Two things protect Tony, and neither one is the app.

The market is different. Hong Kong is extremely dense in population, and there are very few places to play golf. It is also hot for much of the year, which makes playing outside unpleasant. That makes indoor golf a real substitute for the sport, not a novelty.

Compare that to San Francisco, where the weather is great, you can play year-round and there are plenty of courses nearby. People have good outdoor options, so the indoor market is naturally much smaller. The same business that works in Hong Kong may not make sense in San Francisco, and the reason is the market, not the execution.

Competitors will struggle to copy him. As Tony described it, Hong Kong's golf operators are not strong with technology. A competitor would have to climb a steep tech learning curve to match a fully app-driven, staffless operation. That gives him a long first-mover advantage, because the barrier is capability and not capital. Competitors can see exactly what he's doing and still can't easily do it.

For any GTM Eng or business bet, I'd ask three questions. 1) Is the market or audience you're tackling structurally sound for the objective of the bet? 2) What is the unique element that reshapes the market psychology or the unit economics? 3) How long can the first-mover advantage last?

3. Focus and effort beat experience

Tony doesn't golf, and he had never run a business. Neither fact slowed him down.

Alexandr Wang has talked a lot about this from his time building Scale: you win by out-focusing and out-working everyone else. Tony is a good example. He picked one thing, a tech-enabled indoor golf business, and kept at it until he had five locations.

Domain expertise is easy to overrate. Sometimes it helps, and sometimes it anchors you to how the industry has always done things. Someone with no golf background had no reason to assume a golf venue needs staff, so he never did.

The takeaway

A technology-driven change in unit economics, a market with structural tailwinds and competitors who can't easily follow, and a founder who stays focused on the work. Tony has all three, and that's what a big swing looks like.

The same checks apply to a bet on a new GTM system, a new startup or a new line of business. Does it change the economics, or does it only improve them a little? Warren Buffett's point that competition erodes profits applies here: if you're doing what lots of other people are already doing in the same market, you haven't generated any alpha, and you shouldn't expect great returns. So is anyone else doing it, and can they easily copy you? And will you stay focused long enough to see it through?

canto dinner club

a running list of the best plates at credible spots.