.avif)
Osman Sheikhnureldin is Clay’s Head of GTM Engineering, which makes him the person leading GTM engineering at the company that turned it into a job title. Internally, we call him the GTM engineer’s engineer. Before Clay, he spent years as a growth operator at startups like Virtru and Shelf. At Rippling, his last stop before he joined us, he used Clay to run experiments on an outbound machine sending 200,000 cold emails every week. In the early days of Clay, he pushed the product so far past its limits that he broke it twice, which is how our co-founder, Varun, invited him aboard.
Some assume GTM engineering means cold outbound, but Osman sees that as a small slice of the job. The real work is figuring out what’s stopping a company from growing as fast as it could, then removing those constraints with automation and better data (instead of headcount). Osman walked us through the GTM plays he ran at Shelf and Rippling, how his team hunts for bottlenecks at Clay, and why they build their own DIY tools before the product catches up.
Top 1% is our series going deep with the operators changing go-to-market. Watch the video version with Osman Sheikhnureldin and register for upcoming livestreams to catch episodes with GTM experts from companies like Brex and Depthfirst.
A GTM engineer in the making
Osman’s career began, fittingly, by sending a cold email. In his junior year of high school, he was regularly reading Hacker News and TechCrunch, fascinated by people building their ideas into enterprises. He wrote to the founder of a two-person conference management startup in his corner of Virginia and joined as a Rails developer.
But almost nobody was using the product. Osman pivoted from software development into SEO and marketing to gain more customers. He quickly got hooked on growth and the fast feedback loop of watching traffic turn into trials, and then into customers. Next, he joined a more mature startup where he moved into conversion rate optimization, influencing different points of the customer journey to increase revenue.
A few years later, he joined Shelf, a Series B knowledge management startup. This is where he first encountered Clay. Shelf’s cold outbound wasn’t producing much, so the company brought in Jordan Crawford, who runs the GTM agency Blueprint. “I think Jordan is one of the smartest people in the Clay ecosystem,” says Osman.
Jordan used Clay to find companies whose reviews complained about customers receiving wrong information, the exact pain Shelf solved. It went a few levels beyond the persona-based ICP targeting Osman was used to, and he immediately loved Clay’s power.
A GTM play at Shelf: Turn bad reviews into a target list
Shelf fixed knowledge management, so its best prospects were companies whose customers kept getting wrong answers. For instance, this could be an airline whose reviews complain that phone agents quote different baggage fees than the website. Jordan used Clay to scan public reviews for complaints about receiving incorrect or inconsistent information, structured those companies into a list, and wrote outbound copy that echoed the reviewers’ own words.
Running experiments on Rippling’s outbound machine
After his first few startup stints, Osman joined Rippling. Their outbound model was sending upwards of 200,000 cold emails every week. Rippling was scientific about outbound in a way few companies are, and their measurement culture stuck with Osman, and it still shapes how he runs things at Clay today.
His mandate back then was self-serve tooling and experimentation for the growth team. But engineering ran two-week sprints, and small, unproven campaign ideas naturally kept losing prioritization battles to infrastructure work. Clay became his workaround. Because the platform hooks into the systems a company already runs, Osman could change one part of Rippling’s machine without asking anyone to rebuild it.
The experiment Osman remembers best was a restaurant gift card campaign for remote workers. Building it with Rippling’s regular stack would have meant asking engineers to write new data pipelines and custom code, then wire up an outside service to find restaurants. That’s a sprint or two of engineering time. In Clay, the whole play came together much quicker in a single table.
A GTM play at Rippling: A DoorDash gift card for remote workers
As offices reopened during the COVID-19 pandemic, the team targeted people who worked from home, far from their company’s main office. The email offered a DoorDash gift card and named a real restaurant near the prospect instead of pushing something generic. Pulling it off required the person’s city, the company’s office locations, confirmation they lived too far to commute, and a local restaurant worth mentioning.
From Clay power user to Head of GTM Engineering
Osman’s route to working at Clay involved breaking it. At the time, tables maxed out at 50,000 rows, and at Rippling’s scale that meant manually clearing rows to keep things running. He found the internal APIs behind the product and used them to delete rows in bulk. About three years ago, when Clay was more nascent, one experiment accidentally brought down the entire product. It sparked the conversation with Varun that ended with him leading our GTM engineering team.
His team tops the usage charts every year in Clayback, our Spotify Wrapped-style recap. They dogfood everything and deliberately run ahead of the core product, with space to fail and build things that won’t scale. Their learnings inform what ships to everyone else.
Their current work falls into two buckets:
- The first is tools for reps, built around Terra, an internal app the team created for Clay’s own sellers. Clay now has an MCP, a connection that lets AI tools pull answers straight from your Clay data. The team is building that into Terra, so reps can ask questions about their accounts and get answers without ever leaving the app.
- The second is closed feedback loops. When AI writes outbound messaging, Osman wants the system to learn from every email, see what correlates with higher reply and meeting booking rates, and feed that back into the workflow’s prompting and context. The same pattern runs through everything they build: trace what happened and the result, then loop it back so the system improves as it runs.
Osman’s framework for prioritizing what to build
Osman joined Clay knowing his team could do a lot and needing a way to decide what to do right now. His answer starts with throughput, meaning how many leads make it through the funnel, not how many enter it. The numbers his team can really move depend on how leads flow through the funnel and where they fall off, like a form that runs too long or a follow-up that goes out too late.
Finding these drop-off points comes down to three habits:
- Map the system. He charted every step from start to finish, both the human ones and the automated ones, so he could see what actually moves work forward.
- Shadow the people inside it. Osman talked with reps and watched them work. Friction shows up in the steps people find hard and in the manual tasks that eat up their time.
- Check the data. He paired what people told him with his own analysis, since the numbers reveal where leads pile up or quietly leak out.
Once the bottlenecks are visible, one filter decides what gets built first: compound problems.
These are issues woven through the system, where a single fix helps several parts of the funnel at once. One example is how we segment and score leads and accounts: segmentation gives everyone in the funnel a shared framework for targeting and messaging, and it also measures which accounts matter most. Before he could score anything, though, Osman needed to know what separates a great account from an average one, and he answered that with a simple exercise in Clay.
A GTM play at Clay: Profile your best customers to find your next ones
Osman pulled up a Clay table of our top customers by ARR and ran a pile of enrichments on them, checking headcount by function and tech stack. The sample of six-figure accounts was too small to be statistically significant, so the team worked off patterns instead. One was unmistakable: ur best customers tended to have 10% or more of their headcount in sales or GTM broadly. Hiring is one of the most deliberate things a company does, so a tenth of headcount in sales signals a company betting on GTM, precisely the bet Clay helps with.
Building workflows and products based on reps
Client-facing teams have traditionally seen RevOps as gatekeepers of data and workflows. Osman’s team works hard not to be. The people talking to customers all day are creative and often know how to build, so the job is to equip them rather than block them.
However, he decides whose feedback to act on with two basic rules:
- Never prioritize based on one person, since a single request isn’t a trend.
- At the same time, some people are outliers whose unusual way of working is extremely effective. Sometimes it’s useful to scale what they’re doing rather than sanding it down.
That thinking is why the team built its rep UI and why Osman is excited about MCP in Clay, which runs on Audiences where Snowflake and Salesforce data come together. Reps can run with that curated data, layer on enrichment or their own AI research, then push out an email.
Building hacky MVPs for the GTM team
Clay’s product team talks to customers constantly, and by the time a feature goes public, it has been stress-tested with beta customers. Internally, Osman’s team is customer zero. But sometimes they don’t wait for the product at all. Building a hacky version first makes sense for a few reasons:
- GTM can’t wait. The team carries ambitious pipeline goals and adds new sellers every quarter, so sitting out a full product launch cycle isn’t an option.
- Hacky is enough. An internal version only needs to support the team’s workflows, not every Clay user, so corners can be cut with little consequence.
- Speed comes from independence. Building outside the core infrastructure means no sprints and no prioritization battles, and scaling can wait until the idea is actually proven.
The best example is account agents, now live in Clay, whose precursor Osman built into the rep UI over a Christmas break. He was chasing a problem every seller recognizes: the context you need to do your job sits scattered across systems.
- Call recordings sit in one tool
- CRM data lives in another
- Conversations pile up in Slack
- Product data sits in Snowflake
- Ad hoc research gets buried in Claude and ChatGPT threads
His answer was a concept called “account state,” a technical project that coalesced all that context into one JSON object covering everything you need to know (whether you’re prospecting or renewing). Agents combed the data to assemble each account’s profile, signals, risks, and key people, and the team used it internally for months.
The product team met with them once or twice a week while building the real feature, to hear lessons about the homegrown version. That collaboration led to one of the best features in account agents.
People enjoyed the internal version but kept asking how they could trust the information was right rather than hallucinated, and Osman’s team passed that concern along. So account agents cite their sources, showing whether a data point came from a call recording or a Salesforce field.
The CLI, and making GTM look like software engineering
Osman is bullish on the CLI and building on Clay with any coding agent. The first reason is speed, since you can build new workflows just by typing and prompting rather than clicking through a UI. The second is what it does for a growing team.
Osman wants the team’s tribal knowledge encoded rather than passed by word of mouth, so they maintain a shared repo of skills and tooling anyone can use. He hopes new hires can skip digging through Slack and instead open the repo to see what’s been built and why decisions were made, with every skill and workflow versioned along the way.
“It’s helping us take one step closer to making GTM look more like software engineering,” says Osman.
.png)
.avif)
.avif)
.avif)
