A one-on-one conversation recorded at Humans of GTM 2026, released alongside UserGems' new Build vs. buy guide, unpacks why "just build it in Claude" is the wrong question for most GTM teams.

San Francisco, CA - UserGems, the AI command center for outbound and ABM, today released a video conversation between Christian Kletzl, CEO and Co-Founder of UserGems, and Mark Kosoglow, CRO at Docebo, recorded at Humans of GTM 2026. The conversation is a companion piece to UserGems' recently published guide, "Build vs. Buy: A guide for AI-powered GTM teams," and goes deeper on a question Kosoglow says he gets constantly: as a technical CRO, why doesn't he just build his own GTM stack?

The full video is available now.

"Build versus buy is not this binary answer. Even if you're building, you're building on top of a foundation of something. It's similar to building an e-commerce store: I can build my own cart and Stripe connection, or I can go to Shopify. You always build on a foundation. The question is what's the right foundation for this." - Christian Kletzl, CEO & Co-Founder, UserGems

‍

The product manager's rule: learn to say no

The conversation opens with Kosoglow recounting a question he gets constantly from technical peers: he's clearly technical enough to build his own GTM stack, so why is he paying a vendor for it? Kletzl's answer traces back to his own background as a product manager, where the number one skill isn't building, it's saying no. There's only so much time to create anything, and saying yes to every possible build means spreading a team too thin to finish what matters.

That skill matters more now, not less. Now that anyone can be a builder with an AI assistant, knowing what not to build is the harder and more valuable discipline.

What foundation are you actually building on?

Kletzl pushes back on the idea that build versus buy is a clean either-or choice at all. Even a team that says it's "building" is still building on top of something it bought or is otherwise reliant on, whether that's Claude itself, an MCP server, or a data warehouse like Snowflake that already holds the company's data. He compares it to launching an e-commerce store: a team can build its own cart and payment flow from scratch, or connect Stripe and go to Shopify. Either way, something underneath is bought. The real question isn't build or buy, it's which foundation is the right one to build on.

That framing lines up directly with the guide's own three-layer model: data, intelligence, and action. The foundation Kletzl is describing, the signals, the records, the infrastructure, is the data layer the guide argues almost every team should buy. What a team builds on top of it, the campaigns and workflows, is the intelligence and action layers where differentiation actually happens.

What Kletzl builds for himself, and what UserGems builds for customers

Kletzl draws a clear line between personal, one-off builds and company infrastructure. He walks through a tool he built and runs every morning: it scans every open task in his task manager, checks it against his own notes and past thinking, and surfaces two ideas he might not have considered. That's a build he owns, uses daily, and is fully responsible for maintaining.

UserGems' own product exists on the other side of that line. Once a team is sitting on a foundation of data and signals, there is a lot worth building on top of it: campaigns, workflows, plays. But building the database and data infrastructure layer underneath it wastes the time that should go toward the campaigns themselves. The first campaign is easy and even fun to build. What catches teams off guard is the second one, and the moment those campaigns need to combine or scale together, work nobody budgeted for. Kletzl's shorthand for it: the first 80% of a build takes 20% of the time, and the last 20% takes the other 80%. RevOps needs to remember it's rev and ops. Time spent building infrastructure is time not spent on the rev part.

The two-step way to actually use Claude

Kosoglow shares a pattern he's seen work well at Humans of GTM: using Claude first to figure out what you actually need, not to build the final solution. Prototype something quickly, show it internally, get feedback from the team that would use it, and only once the real need is clear, go find a solution that already covers most of it and build the remaining edge on top.

Kletzl agrees it's the first time he's heard the idea framed quite that way, but it matches what he expects to play out over the next year: a wave of dead internal projects once the person who built them moves to a new job or role. It's the same lesson engineering already learned the hard way, an engineer builds something, moves on, and no one is left who understands it well enough to fix it when it breaks.

"When it breaks, do I want to sit there for two weeks while the guy that built it left two months ago and now everybody's trying to figure out how to fix it? No. I want Christian and Stephan to do that stuff. That way I can worry about the pipeline." - Mark Kosoglow, CRO, Docebo

That's close to a live version of one of the four questions in the guide's decision framework: can the team actually maintain what it builds forever, not just ship it once? Kosoglow's answer, for himself, is no, and that's exactly why he buys.

Why this pairs with the guide

The build vs. buy guide lays out the layer-by-layer framework: buy the infrastructure, build only where the logic and maintenance are genuinely yours to own. This conversation puts a face and a real example on that framework, from a CEO who applies it to his own daily workflow and a CRO who has felt the maintenance tax firsthand.

It also previews where the guide's argument is heading next. As more platforms expose their data and intelligence layers through interfaces like MCP, the choice stops being build instead of buy and becomes buy the foundation, build whatever campaigns, agents, and workflows are genuinely yours on top of it.

Readers who want the full framework, including the four-question decision test and the layer-by-layer breakdown referenced in this conversation, can find it in "Build vs. buy: A guide for AI-powered GTM teams."

About UserGems

UserGems is the AI Command Center for B2B revenue teams, the brain that sits between your CRM and execution tools. We unify signals, prioritize buyers using transparent AI scoring, and deploy AI agents (Gem-E) to automate outbound and ABM execution. Customers include Mimecast, Workday, Salesloft, Sendoso. Learn more at www.usergems.com.

‍

‍