Product-User Fit vs. Product-Buyer Fit: Snyk's $300M Lesson

Thousands of users. Zero revenue. Guy Podjarny had product-user fit at Snyk—but not product-buyer fit. Once he understood that distinction, ARR grew from $100K to $4.5M in 12 months. Now he's applying every lesson to Tessl, his $125M-backed AI development platform.

Key Facts

• ARR at 2 years, 2 months: $100K ARR after burning $4M (Guy Podjarny)
• ARR 4 months after fixing buyer fit: $650K ARR (Guy Podjarny)
• ARR 12 months after the fix: $4.5M ARR (Guy Podjarny)
• Snyk ARR today: Over $300M ARR (Pablo Srugo)
• Tessl total funding: $125M ($25M seed + $100M Series A) (Guy Podjarny)

The Product-User Fit Trap: When Love Doesn't Pay the Bills

Having users who love your product means nothing if they don't control the budget. Guy Podjarny learned this after two years and $4M spent at Snyk—developers were enthusiastic adopters, but security teams held the checkbooks and had been completely ignored in the product roadmap.

Guy Podjarny founded Snyk in 2015 on a clear thesis: bring DevOps thinking to application security. The product would be built for developers first—easy to install, fast to deliver value, and frictionless to adopt. By mid-2016, the GitHub app integration was live, tens of thousands of developers were using it, and the product was genuinely loved.

Then came the hard truth. When Snyk opened up paid tiers, nobody converted. The product was free, easy, and useful—but at just $20 a month, developers still wouldn't pay. Guy realized the issue wasn't product quality. It was a structural mismatch between who used the product and who held budget authority.

The core insight Guy now shares with founders is the distinction between product-user fit and product-buyer fit. Snyk had the first but was missing the second entirely. Security teams—the actual buyers—had been left out of the product vision. They needed governance, breadth of stack coverage, reporting, and organizational controls. None of that had been built.

"Two years and two months in, we were at $100,000 ARR. Not awesome. And we burned $4 million by that time." — Guy Podjarny

"What we missed was that, yes—developer, developer, developer—that's the user, but that's not the buyer." — Guy Podjarny

Why PLG Fails When Buyer and User Are Far Apart

PLG works best when the user is also the buyer—or at least their direct manager. The further apart the user and buyer are in an organization, the harder monetization becomes. For Snyk, developers and security teams were organizationally and motivationally distant, which broke the natural PLG conversion loop.

Product-led growth is often described as a free distribution engine—users discover, adopt, and eventually pay. But this flywheel only spins smoothly when the person experiencing value is the same person (or very close to the person) who approves spend. Slack, Notion, and Dropbox all fit this model perfectly.

Snyk didn't. A JavaScript developer using Snyk to scan open source vulnerabilities cared about clean code and avoiding rework. A security team leader needed to know: Does this tool cover all our stacks? Can I report on coverage across the whole organization? Can I enforce policies centrally? These are completely different product needs.

Guy frames this as a distance problem. The further a buyer is from the user, the more the product must serve both audiences to convert. He describes it as a 'pincer movement'—continuing to win developers bottom-up while simultaneously building enterprise-grade features that give security leaders a reason to sign contracts.

"PLG works best when the distance between the user and the buyer is small. The best-case scenario is when the user is the buyer." — Guy Podjarny

"We neglected the needs of the security person. We didn't think about governance. We didn't think about the fact that security teams need breadth of coverage." — Guy Podjarny

• Best case: user and buyer are the same person (Slack, Notion, Dropbox).
• Workable: buyer is the user's direct manager—bottom-up referral still converts.
• Hard: buyer is a separate team with different needs (Snyk's developer vs. security team gap).
• Fix: build features that serve both users and buyers, then run a two-sided GTM.

How Snyk Fixed Buyer Fit and Scaled from $100K to $4.5M ARR

After identifying the buyer fit gap, Guy spent roughly a year building governance features, reporting, enterprise organization coverage, and multi-stack support. Combined with the tailwind from the Equifax breach highlighting open source vulnerabilities, Snyk jumped from $100K ARR to $650K in four months—and $4.5M a year later.

The fix wasn't a pivot. Snyk kept its developer-first ethos and PLG motion. What changed was the addition of a second product layer built specifically for security teams. Governance dashboards, cross-organization reporting, and support for more programming language stacks made Snyk a product security leaders could actually buy and justify to their organization.

Timing also mattered. The Equifax breach in 2017—caused by an unpatched Java Struts vulnerability—put open source security risk on every CISO's radar. According to Guy, the CEO of Equifax ended up testifying before Congress over the incident. Snyk was directly addressing that exact class of vulnerability, giving the company a massive tailwind at the right moment.

On the GTM side, Guy's team ran a pincer movement: developers continued to adopt the product organically, while sales started reaching out to AppSec leaders with data. The pitch was simple and compelling—'Did you know seven developers in your organization are already using and loving Snyk? Do you want to talk?' That combination of existing usage proof plus enterprise-grade features closed the loop on monetization.

"Four months later, we're at $650K. A year later, we're at $4.5 million. A year later, we're at $19 million." — Guy Podjarny

"We started getting inbound after inbound—from the tailwind we'd built in the developer community, security teams started reaching out too. Suddenly, every conversation was an inbound one." — Guy Podjarny

Guy's Framework: How to Motivate Users and Drive Adoption

Guy uses a two-axis framework to think about user motivation: how much someone cares about a problem, and how hard it is for them to act. The goal is either to increase how much they care or reduce the friction to act. For developers, the second lever is far more powerful.

One of Guy's core product frameworks is deceptively simple. Every user sits on two axes: how much they care about the problem, and how hard it is to do something about it. Adoption only happens when caring exceeds difficulty. Your job as a product builder is to move those levers.

For security tools aimed at developers, the traditional approach was to increase how much developers cared—through mandates, audits, and fear. That approach failed for decades. Snyk's insight was to reduce friction instead. The GitHub integration required no code changes. The pull request notifications required no new workflow. The fix PRs were handed to developers automatically. Caring stayed the same; difficulty dropped to nearly zero.

Guy also uses a 'power statement' framework drawn from sales methodology—a three-part structure that defines user motivations, product function, and differentiation. He used it not just for messaging but as a product definition exercise. Understanding that developers came to Snyk out of dependency anxiety and quality pride—while security teams came because they couldn't get developer adoption—shaped every product decision.

"Nobody cares about your product—they care about the problem you're solving for them." — Guy Podjarny

"There are two axes: how much you care and how hard it is. You'll only do something if you care more than it's hard." — Guy Podjarny

Tessl and the Next Frontier: Spec-Driven AI Development

Guy's new company, Tessl, is built on the belief that AI will shift software from being code-centric to spec-centric. Instead of writing and maintaining code, developers will maintain living specification documents—and AI agents will generate and regenerate code from those specs on demand.

After five years of handing Snyk's CEO role to Peter McKay and focusing on broader strategy, Guy took a sabbatical in late 2022. When he returned to work on Snyk's AI strategy in 2023, he found himself building a thesis about the future of software development itself—and realized that was the company he wanted to build next. Tessl was formally incorporated in early 2024.

The core thesis is that today's software is defined by code, but code is a poor long-term artifact. Requirements get written, code gets shipped, and the original intent is lost. Over time, codebases become brittle. In an AI-native world, Guy argues, the spec—a structured document of what the software should do and why—becomes the primary asset. Code becomes disposable, regenerated as needed by AI agents working from those specs.

Tessl's near-term entry point is the agent workflow problem: AI coding agents are fast but forgetful. Each session starts from scratch. Specs give agents institutional memory, policy guardrails, and a consistent understanding of intent. Guy describes this as a path from 'spec-assisted' to 'spec-driven' to 'spec-centric' development—a journey that starts today and builds toward a future where a single high-level instruction can update an entire codebase.

"In an AI world, software will move from being code-centric to being spec-centric." — Guy Podjarny

"The agent you open tomorrow has no idea what yesterday's agent did. So agents need specs." — Guy Podjarny

The Founder Mindset: Anchor in the Future, Avoid the Grey Zone

Guy's core advice to founders: build toward a future that will matter more in five years, not less. The worst outcome isn't failure—it's building a company that survives at $2-3M ARR growing 30% annually, never quite successful enough to exit but too alive to walk away from.

After more than a hundred angel investments and two company-building journeys, Guy distills founder advice into a single priority: ruthlessly protect your time by anchoring in the right future. If your product only fills a gap that exists today, you risk building something that becomes less relevant over time—burning years on a trajectory that leads nowhere compelling.

He's equally direct about what failure actually looks like in the venture world. It's not the company that shuts down in year two. It's the company that grinds forward at modest growth, generating just enough revenue to justify continuing, while the founder remains trapped—unable to move on, unable to break through. That grey zone, in Guy's view, is the real danger.

These lessons apply directly to Tessl's positioning. Rather than building for today's AI coding assistant market, Tessl is explicitly anchored in a future where software development is fundamentally restructured around specs. The $125M raise is designed to buy the time and autonomy to reach that future without being forced to optimize prematurely for short-term metrics.

"The worst outcome isn't failure—it's getting stuck. You build a company doing $2–3 million ARR, growing 30% year over year. It's enough to survive, but not what you signed up for." — Guy Podjarny

"You want to anchor in the future—build something that in five years will be more important, more needed, not less." — Guy Podjarny

Product-User Fit vs. Product-Buyer Fit