---
title: "How we built Extend's GTM system"
description: "Every GTM question at Extend used to mean 15 minutes in Slack, Orb, PostHog, and HubSpot. Here's how we built Uatu to put that context in one place."
author: "Bo Lau, Scott Graumlich"
category: "Blog Post"
published: 2026-10-05
canonical: https://www.extend.ai/resources/how-we-built-extends-gtm-system
---

# How we built Extend's GTM system

Every basic GTM question at Extend used to start the same way: 15 minutes of toggling between Slack, Orb, PostHog, HubSpot, a meeting recorder, and email, just to get enough context to answer:

- Are they a paying customer?
- How much are they paying us?
- Are they actually using the product?

![](https://www.extend.ai/images/blog/how-we-built-extends-gtm-system/gtm1.png)

[Scott Graumlich](https://www.linkedin.com/in/scottgraumlich/), Extend's Growth Lead, got fed up with that loop. He's not an engineer, but he had spent two years shaping how growth works at Extend and knew the problem better than anyone else. So he used AI coding tools to build the solution himself.

He ended up building Uatu (named after the Marvel character who watches over everything), our internal GTM system, to unify all that context in one place for the entire organization. Signals across PLG users, customers, pipeline, and target accounts. Scores weighted the way we weigh intent. A shared UI, so the same answers are available every day without re-asking a chatbot.

Uatu is now the hub that sales, growth, marketing, and customer success build on. Most internal GTM tools end up as science projects. Uatu is on the screen of every GTM person at Extend every day — and sometimes our CTO's.

## Team love

![](https://www.extend.ai/images/blog/how-we-built-extends-gtm-system/teamlove1.png)

![](https://www.extend.ai/images/blog/how-we-built-extends-gtm-system/teamlove2.png)

![](https://www.extend.ai/images/blog/how-we-built-extends-gtm-system/teamlove3.png)

## Success criteria

Scott had three goals for Uatu:

1. Eliminate the tab-switching needed to gather basic context on a prospect or customer account.
2. Surface the right signals in one place for target accounts, and capture custom signals that sales-tech tools don't provide — or don't provide well enough.
3. Give the entire organization a shared foundation for building tools around their own workflows, rather than changing their processes to fit paid software.

Outbound research and flagging high-signal PLG accounts are systematic enough to automate, but only if the system is owned by us, stays current, and compounds over time with what we learn from GTM — instead of dumping a text wall into Slack once a day.

## Non-negotiables

**A live dashboard.** The team needed the same account and customer signals every day. We needed them available in one place, not a fresh prompt for another point-in-time answer.

**Account context in one place.** Paying status, usage, ownership, and deal health shouldn't require Orb, PostHog, the CRM, and Slack opened in parallel.

**Usable every day.** A GTM brain that's too slow or impossible to use is wasted tokens. Uatu had to be fast enough and obvious enough that people would open it without thinking, and they do. It's on every GTM person's screen every day.

![](https://www.extend.ai/images/blog/how-we-built-extends-gtm-system/gtm2.png)

## What "good" looks like

Target accounts, PLG, customers, and sales deals each have different signals worth tracking. The weights should reflect what people doing the work have learned, not a vendor's generic assumption. Once the data lives in one place, other teams like customer success and marketing should be able to ship on top of it.

## What we built

Uatu does two jobs: capture and score GTM signals the way Extend actually works, and act as a hub so teams can stay on the same page without pinging Slack and waiting on a reply.

![](https://www.extend.ai/images/blog/how-we-built-extends-gtm-system/gtm3.png)

### The initial iteration: GTM Bot

GTM Bot was the first version Scott tried to build. It was a Slack Q&A bot running on his laptop via Claude Code. Sessions could take ~45 minutes. If the laptop was closed, the bot didn't work. Even when it worked, you got a point-in-time dump, and the burden to act on that information was still on you. Same problem as the unread AI slop digests in half of our channels.

GTM Bot showed that the inputs from our vendors were available. It also showed a chatbot was the wrong interface for an internal GTM tool. So he built a UI for the signals you need every day.

### The snowball effect

Uatu is now the infrastructure for GTM engineering at Extend. It brings the team's data and integrations into one place, so new tools can build on that foundation instead of starting from scratch.

Sales, growth, marketing, and CS/support have all shipped something on top of Uatu. Some teams solved one use case and moved on. Others iterate daily, like Chaner Peng's (Extend's Support Lead) request feature system.

## How Scott built it

1. Record a roughly 90-minute explanation of the problem, the data available, and the outcome you want. (He did it while on a Peloton.)
2. Bring in GTM-engineering blog posts or talk recordings when they offer a relevant architecture idea.
3. Use Claude or other AI tools to break the work into stages, so the foundation comes before the data integrations and UI.
4. Give it to Claude Code, then work through the phases over a week or two rather than trying to build everything at once.

## Lessons learned from building the GTM brain

AI can build the bridge, but you have to define what it connects. The inputs are where the data lives, such as PostHog, Orb, and HubSpot. The outputs are what GTM needs to act on, such as scored leads, account ownership, and signals worth following up. Without clear inputs and outputs, you risk building a tool no one ends up using — and you're back to square one.

![](https://www.extend.ai/images/blog/how-we-built-extends-gtm-system/gtm4.png)

## Learnings

- **Define the inputs and outputs before writing code.** Know where the data comes from and what your team needs to do with it. AI can help build the middle, but it cannot supply the judgment that comes from doing the job.
- **Build a place to see signals, not a bot that summarizes tabs.** GTM Bot produced point-in-time answers and still left someone to decide what to do next. Uatu made the signals people need every day available in one place.
- **Design the process first, then the tool.** Your workflow should determine what you build, rather than bending your workflow around a vendor's product.
- **Build in phases.** Get the foundation right, then bring in the data and build the UI. Trying to create the whole system at once invites rework.
- **Be ruthless about build versus buy.** AI makes it easier to build, not easier to justify building. Build what is specific to your process: integrations, custom signals, and scoring. Buy workflows that require constant user customization — outbound sequencing and multi-step editors are better served by tools like Nooks or Instantly.
- **Keep improving signal quality.** The dashboard is only as useful as the signals it surfaces. The next opportunity is to capture more relevant activity and connect it to the right accounts.

![](https://www.extend.ai/images/blog/how-we-built-extends-gtm-system/gtm5.png)