The Figureouter Economy: What Clay's First GTM Engineer Learned About Building Revenue Systems

Yash Tekriwal — Focal Podcast — YouTube, CdeMa9mZTLI

In the summer of 2023, Clay had a problem. The company had product-led growth momentum, self-serve revenue, and a $3 billion future ahead of it. What it did not have was a single salesperson, RevOps hire, or enterprise playbook. So Varun Anand, one of the co-founders, turned to Yash Tekriwal — then an early hire with a background in low-code tools — and told him to go sell. Not just sell. Figure out what the enterprise offering should be, maintain the CRM, score every inbound lead, track deal stages, and somehow still find time for discovery calls. The role that emerged from that impossible brief is what we now call GTM engineering.

Two years later, the term is polarizing. Some call it a fad. Others call it the next evolution of RevOps. Tekriwal, now Head of Education at Clay, does not care much about the semantic debate. What he cares about is the underlying shift: the skills required to grow revenue have changed, and the people who thrive are no longer pure sellers or pure operators. They are figureouters — generalists who can vibe-code a prototype, wire a CRM, run outbound experiments, and explain why a campaign failed in the same afternoon.

From Maintenance Function to Growth Laboratory

The easiest mistake is to define GTM engineering as "RevOps with extra steps." Tekriwal draws a sharper line. RevOps, he argues, is fundamentally about keeping the ship running. You hire it when you already have revenue to operate on — when territory planning, forecasting, and account mapping become necessary burdens. It is a maintenance function.

GTM engineering adds an experimentation layer on top of that maintenance. The same person who cleans CRM data also asks: what if we tested this outbound campaign? What if we rebuilt the lead score with a new dimension? What if we routed different signals to sales reps based on intent instead of firmographics?

RevOps is now being added into an experimentation laboratory. That expanded capability turns RevOps from a maintenance function inside of an organization to a true growth lever.

At Clay, this meant Tekriwal was simultaneously the first AE, the first BDR, the first RevOps analyst, and the first systems architect. He used Clay itself to automate inbound scoring, CRM hygiene, and call prep so he could still hop on discovery calls with the research already done. The term "GTM engineer" was coined partly out of necessity — one human could not physically do all of that without tooling — and partly because the tooling had finally caught up to the ambition.

Treating GTM Like a Product Function

One of Tekriwal's core theses is that go-to-market needs to become a team sport instead of an individual one. Historically, sales rewarded secrecy. Top reps safeguarded their outreach tricks, their lead sources, and their playbook tweaks because compensation incentivized individual performance over shared learning. Product development does not work that way. Engineers cannot ship features without coordinating across teams.

The analogy Tekriwal uses is persuasive: salespeople should function like PMs for the GTM engineering team. They bring feedback from the front lines — customer complaints, deal patterns, competitive losses — and the GTM engineers translate that feedback into frameworks, automations, and workflows. The loop closes when those workflows are deployed, measured, and iterated.

This only works if the organization builds space for experiments. Most GTM teams skip measurement because they are too busy chasing revenue. But in a world where a Clay workflow can be built in a day instead of weeks, the cost of experimentation drops to the point where ignoring it becomes negligent.

The Experiments That Actually Move the Needle

Tekriwal offers three concrete experiment categories that Clay has run or observed across its customer base:

Inbound scoring is never finished. Any company with meaningful inbound volume should treat its lead score as a living system. At Clay, they constantly re-evaluate what gets disqualified. When DQ'd leads that were passed to support or sales-assist still closed at repeatable values, that was a signal the scoring model was wrong. The fix was not more rules. It was more dimensions — including social mentions, website behavior, and firmographic nuance — fed into the model until the false negatives shrank.

Outbound has a half-life. Every campaign thesis has an expiration date. Personalized copy based on one signal might work for two quarters, then the market moves. Tekriwal recommends running monthly campaign theses against narrow ICP slices: event-driven outreach (fundraising, hiring, job changes), social-listening triggers (Reddit mentions, LinkedIn posts), or flattery-driven personalization. When a campaign tires, it does not mean the idea is dead forever — in-person events went through exactly that cycle during the pandemic — but it does mean you need the next one ready.

Founder-led signal extraction beats automation early on. In the zero-to-one phase, Tekriwal routed every product signup into a Slack channel and manually reviewed them. If an interesting domain appeared, he emailed the user within seconds. That was not scalable, but it was how he learned the shape of the ICP. Automation should replace manual labor only after the manual labor has taught you what matters.

Hiring the Unicorn: The Figureouter Archetype

The hardest part of GTM engineering is finding the people. Tekriwal is explicit: a computer science degree is neither necessary nor sufficient. He has watched software engineers grasp Clay instantly and watched others with the same credentials flail. The differentiator is not coding skill. It is translatable systems thinking — the ability to recognize that an if-statement, a SQL join, and a Clay formula are the same logic wearing different clothes.

The profiles he actually hires from:

What unites them is not a credential. It is what Tekriwal calls the figureouter mindset: someone who, when handed a tool they have never seen, will research, ask, prototype, and iterate until it works. His interview filter is deliberately adversarial: give candidates a problem in a tool they do not know, tell them they do not know it, and watch how they navigate ambiguity.

Stage-Appropriate GTM Engineering

Tekriwal breaks the journey into three phases, and his advice changes dramatically across them.

Zero to $1M: Be thrifty and manual. You can survive on Google Sheets, Slack, and a lightweight CRM. If you use Clay, buy a cheaper tier and pause the subscription when you are not actively enriching. The goal is not elegant systems. It is proximity to the customer. Automate the boring parts, but do not automate away the signal.

$1M to $10M: Hire or become the figureouter. This is the inflection point where duct tape stops working. The signals that you need headcount are universal: more meetings than the team can handle, deal velocity accelerating, and balls getting dropped not because of incompetence but because of physics. At this stage, the ideal hire is a generalist who can flex across outbound, inbound, and systems until you know which channel deserves specialization.

$10M-plus: Specialize ruthlessly. At scale, the generalist who could do everything must become a specialist or manage specialists. The loop tightens: sales feedback informs product, product launches require retrained teams, and customer success identifies expansion opportunities that feed back into engineering. Clay's own decision to build a native sequencer, for example, came from this loop. Customers wanted easier email drafting inside Clay; the product team recognized that building a sequencer solved the copywriting pain and reduced integration friction at the same time.

The Google Maps Satellite Trick and Other Creative Weapons

One of the most compelling proofs that GTM engineering is a creative discipline, not a technical one, comes from the campaigns Tekriwal has seen built in Clay. A warehouse staffing company needed to estimate frontline worker capacity for every warehouse in its target list. That data does not exist on the internet. So the team scraped Google Maps satellite images of each warehouse during operating hours and used an AI vision model to count the trucks in the parking lot. That count became the best available proxy for headcount, which became the personalization hook in outbound: "It looks like you could still hire 20 percent more people."

Another example: a healthcare vendor used public insurance provider data — published every 90 days — to identify which medical practices were about to be hit by billing code changes. Instead of asking if the practice had a problem, the outreach arrived with the solution already in hand: an analysis of the impact and a draft letter to the insurer.

These are not automations of existing processes. They are inventions of new signals. That is the difference between a RevOps person who keeps the CRM clean and a GTM engineer who builds a moat.

Why This Matters for Diffie

For Diffie — an AI browser testing tool — the GTM engineering playbook is almost too directly applicable. Diffie's ICP is frontend engineers and product teams at startups who ship fast and break things. Those same teams are currently figuring out how to use AI agents for their own workflows. They are exactly the audience that Clay targeted in its early PLG days: technically fluent, skeptical of bloated enterprise sales, and willing to adopt tools that remove toil.

The immediate tactical takeaway is about signal ownership. Just as Clay's customers build unique outreach triggers — trucks in parking lots, insurance code changes — Diffie should help its users build unique quality signals. A GTM engineer at a startup does not just want to know that a test failed. They want to know whether that failure correlates with a deploy, a third-party script update, or a Chrome release. Diffie should be the system that turns visual regressions into actionable, contextual intelligence faster than a human could triage them.

The deeper lesson is organizational. Tekriwal's journey shows that the fastest-growing companies do not separate "selling" from "building the revenue system." The same person does both until the signal is proven, then specializes. For Diffie's early GTM motion, this means the first revenue hire should not be a traditional AE who waits for MQLs. It should be a figureouter — someone who can run outbound experiments, set up intent signals, vibe-code a landing page variant, and still close the first ten deals. That is the profile that turns a product with PLG potential into a company with a repeatable engine.

Most importantly, Clay's entire origin story validates the value of founder and early-team signal extraction. Tekriwal manually reviewed every signup in a Slack channel before automating anything. For Diffie, the equivalent is manually reviewing every test run, every support ticket, and every churn reason until the patterns are obvious enough to systematize. The temptation at an AI-native company is to automate too early. The lesson from Clay is to resist that temptation until you have earned the right to scale.