Product-User Fit vs Product-Buyer Fit: How Snyk Spent $4M to Learn the Difference

Two years in, Guy Podjarny had burned through $4 million and built Snyk to just $100,000 ARR. Thousands of developers were using the product. They loved it. They recommended it to colleagues. They integrated it into their workflows. They just had one problem: they wouldn't pay for it.

Not even $20 a month.

Guy had spent a decade in security before founding his first company. He'd sold that company to Akamai, spent three and a half years as CTO of their $350 million web performance division, and brought deep expertise in both AppSec and DevOps. He knew the problem inside and out. He'd built a developer tool with exceptional UX. He'd achieved impressive adoption for a security product—thousands of active users, tens of thousands of scans, continuous engagement.

He had everything except revenue.

Then in one brutal December, reality hit from both sides. His father-in-law passed away. And simultaneously, a parade of interested VCs—who'd seen the external usage metrics and assumed revenue existed—all took meetings, peeked behind the curtain, saw the $100K ARR, and said the same thing: "Classic dev tool. Come back when you have more traction."

Four months later, Snyk hit $650K ARR. A year after that, $4.5 million. Then $19 million. Today it's over $300 million ARR with thousands of enterprise customers.

What changed wasn't the product developers loved. What changed was Guy's understanding of a fundamental distinction that kills most PLG companies: product-user fit is not the same as product-buyer fit. And when the distance between your user and your buyer is large, loving users mean nothing without paying buyers.

This is the story of how Guy learned that lesson the hard way, rebuilt Snyk around it, and created a framework that now guides his $125 million raise for his next company, Tessl.

Key Takeaways

• Product-user fit and product-buyer fit are separate challenges requiring different strategies. You can have thousands of engaged users who love your product but won't pay if you haven't solved the buyer's problem. According to research from OpenView Partners, PLG works best when the distance between user and buyer is small—ideally when they're the same person. When developers use a security tool but security teams buy it, you must build for both audiences simultaneously or risk having users without revenue.
• The minimum unit of value determines your go-to-market strategy. Developer tools can go bottoms-up because the minimum unit of value exists at the individual developer level—one person can derive value immediately. Security products require governance at the business unit level because their value is organizational. Snyk's breakthrough came from recognizing they needed developer love for adoption AND security team features for monetization. Research from SaaStr shows that hybrid PLG models—combining bottoms-up adoption with enterprise features—grow 2-3x faster than pure PLG once past $10M ARR.
• PLG in enterprise markets means building a "pincer movement" not just bottoms-up adoption. Snyk succeeded by pairing developer-driven adoption with outbound sales to security leaders, saying "Seven developers in your org already use and love Snyk—want to talk?" This approach converts organic usage into enterprise contracts. According to Tomasz Tunguz's research, successful bottoms-up enterprise strategies require 3-5x more go-to-market investment than pure product-led models because you're essentially running two parallel sales motions simultaneously.

Table of Contents

1. From Akamai CTO to Founder Again
2. The DevOps to Security Thesis
3. Building for Developers: The PLG Strategy
4. Thousands of Users, Zero Revenue
5. The Brutal December
6. Product-User Fit vs Product-Buyer Fit
7. Rebuilding for Security Buyers
8. The Inflection Point: $100K to $19M
9. Building Tessl: Anchoring in the Future
10. Frequently Asked Questions

From Akamai CTO to Founder Again

Guy Podjarny's path to founding Snyk started in 2010 when he co-founded Blaze, a web performance company focused on making websites faster through intelligent optimization. "Blaze was like a web page compiler," Guy explains. "It sat before the web page and made it faster by tweaking the CSS, the JavaScript, and the images."

The technical innovation was impressive—a lightweight component in the critical path with asynchronous computation happening behind the scenes. But Blaze's real strategic insight was understanding that the right home for this technology was someone already in the line of fire: CDNs and application delivery controllers.

In 2012, Akamai acquired Blaze. The acquisition was modest compared to Guy's eventual Snyk exit, but it gave him financial independence and something more valuable: a global role learning how enterprise software scales. He moved to London, became CTO of Akamai's web performance division—about half of the company's $700 million annual business—and spent three and a half years learning, growing, and getting well paid.

"I was learning a lot, growing a lot, well paid, and felt like I was making an impact," Guy recalls. "But to have a bigger impact at Akamai and work on what really mattered to me, I would have needed to move to Cambridge, Massachusetts—and that wasn't something I wanted to do."

There was also a cultural mismatch. "Akamai was a brilliant company with brilliant people, but it was very risk-averse, and I'm very risk-forward."

Guy resigned in March 2015, with a last day of July 1st. His plan was to take a year off. On July 9th—eight days later—he incorporated Snyk.

"As I wound down my time at Akamai, my mind started racing—thinking about what I wanted to build and exploring many different ideas."

The DevOps to Security Thesis

The idea Guy settled on was conceptually elegant: bring DevOps to security.

He'd spent a decade in application security before founding Blaze, working at Sanctum and then Watchfire (acquired by IBM Rational). "We always wanted to reach developers but always failed," Guy admits. "The acquisition succeeded financially by selling to auditors, but it didn't succeed in breaking through to developers."

Now, with DevOps transforming how IT teams operated, Guy saw an opportunity. "I felt that with DevOps, the need was stronger than ever and that there was finally a playbook to make it work."

The thesis was both technical and cultural. Security had always been infrastructure-oriented—firewalls, server patching, network security. Application security was "the overlooked child in that world."

"Seventy-five percent of attacks and breaches happened at the application layer, yet only about twenty-five percent of the investment went there," Guy explains. "The problem was that application security wasn't really under the control of security teams."

Security teams were centralized, process-driven, thorough—aligned with IT. But application security lived in the world of software development, which moved fast. Security teams didn't have the mandate to say "you can't ship this because there's a vulnerability."

Then DevOps happened. "IT teams became modern and dev-oriented and fast. Suddenly you saw the world of IT ops go from being a call center to being like a business enabler to being sometimes something that is celebrated."

Companies like Netflix and Amazon had great DevOps teams, and because of that they shipped software faster and were more successful. "Can we do to security what has been done to ops? Can we create DevSecOps?"

The core thesis of Snyk was radical for security: "If you want developers to use a security product, you have to build a developer tooling company, not a security company."

"A big reason developers weren't using these products was because they were really auditor products that had been shoved into a developer workflow," Guy explains. "They didn't care about developers, didn't understand them, and didn't align with their motivations."

Snyk was intentionally a developer tooling company that happened to tackle security. That mindset was core to everything—the color scheme of the website, the guard dog logo, who they hired, how they built community.

Building for Developers: The PLG Strategy

Guy chose to focus initially on open source library vulnerabilities. It was the right problem at the right time for several reasons.

First, it wasn't well-served. "When we came out, there wasn't really an established category—probably BlackDuck was the closest thing, if you'd even heard of it. It was a very enterprise-y, kind of ancient tool, very unpleasant."

Second, it was straightforward technically. "Vulnerabilities in your dependencies are straightforward—if a dependency exists, it's a database lookup, it's a match. Static analysis is much harder."

Third, developer motivation existed. "Dependencies in general were just like a scary domain, so developers were looking for something. It was easy for them to believe that a dependency can fail them."

The go-to-market strategy was bottoms-up—what would later be called product-led growth, though the acronym didn't exist yet. "That kind of bottoms-up motion was highly unusual in security."

Guy went all-in on developer adoption. Conferences, content, integrations. "We went to meetups, to any meetup that would take me. I'd have seven people in the audience, fifteen people in the audience."

He flew around constantly. "I literally flew to give a presentation where only three people showed up."

The effort paid off in usage. They launched a CLI tool in October 2015—free, easy to use, no login required initially. "You could download it, run it on your app, and it would tell you if it was vulnerable."

By June 2016, they launched their breakthrough product: a GitHub app integration. It would scan your repos automatically, tell you about vulnerable libraries, and open fix pull requests when new vulnerabilities were disclosed.

"It became this sort of 'why wouldn't you?'" Guy recalls. They even added badges repos could display to show "zero vulnerabilities."

The adoption was impressive—for a security product. "From the early days, we had some of the best developer adoption numbers for a security product." Users grew to thousands, then tens of thousands.

They were continuous users. Active users. Engaged users.

They just weren't paying users.

Thousands of Users, Zero Revenue

When Guy launched the GitHub app and opened general availability, he fully expected revenue to follow. "We said, let the floodgates open, come pay us. We were very generous about it: for a month it's free, then you can sign up."

The price was modest: just $20 per month.

"It took us a moment to realize—they're not going to pay. They're just not going to pay."

This was about a year into the company, maybe a year and two months. Guy had raised a $3 million seed and probably spent about half of it. "Two years and two months in, we were at $100,000 ARR. Not awesome. We had burned $4 million by that point."

The usage metrics looked great. The engagement looked great. But revenue wasn't materializing.

"I started talking a lot more with security people and made peace with the fact that the buyer was going to be a security person, not just a developer."

The Brutal December

By November 2016, external investors started noticing Snyk. They saw the usage metrics, knew it was a security company, and assumed there must be revenue behind the scenes.

"Everyone was interested, everyone was willing," Guy recalls. "By early December, I bit. I kind of kicked off a preemptive round."

He told investors there was lots of interest, term sheets coming. Everyone engaged. He even got invited to a partner meeting at Andreessen Horowitz, stayed over the weekend to present.

"Nobody converted. Everyone basically peeked behind the curtain, saw there was no revenue, and said, 'Oh, classic dev tool—some usage, not even amazing numbers, but nobody's paying for it. Come back when you have more traction.'"

Around the same time, Guy's father-in-law passed away. "It was a really sad moment—a hard December, personally and professionally."

Ed Sim at Boldstart came through with a seed extension. "He topped us up with a seed extension at the best number we got, though it was a small check. It gave us just enough runway to keep going."

That bridge kept them alive long enough to figure out what they'd missed.

Product-User Fit vs Product-Buyer Fit

The realization that saved Snyk came from separating two concepts that founders often conflate: product-user fit and product-buyer fit.

"The key lesson I'd share is this: what we missed was that, yes—developer, developer, developer—that's the user, but that's not the buyer," Guy explains. "I actually separate product-market fit into two things: product-user fit and product-buyer fit."

Snyk had cracked product-user fit. Developers loved the product. It was critical for PLG. But 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. You use the product, you love it, and at some point you hit a paywall—maybe you upgrade, maybe your team grows, and the monetization feels natural."

That's the Notion, Slack, Dropbox model. Product is everything because user equals buyer.

"The second best scenario is when the buyer is the user's boss. The user falls in love with the product, brings it to their boss, and it can still work. But the further away the buyer is, the harder it becomes."

For Snyk, the distance between developer and security person was substantial. And they'd completely neglected the needs of security people.

"We didn't think about governance. We didn't think about the fact that security teams need breadth of coverage." If you're a JavaScript developer, you don't care if Snyk supports PHP. But if you're a security person managing risk across the organization, you can't have five different stacks each using five different tools.

According to research on enterprise software buying patterns, security purchases involve an average of 7-8 stakeholders and require demonstrable ROI across the entire organization, not just improved developer experience.

"It's also a very hard-to-measure domain," Guy notes. "Does a product actually protect you? If it does, how do you even know it matters? It's like insurance."

Security became a wine-and-dine industry where the CISO holds enormous power and their perspective—influenced over dinner, through trust—matters enormously.

Rebuilding for Security Buyers

Guy and the team spent the following year building what security buyers actually needed.

Governance features. Reporting. Enterprise organization coverage. Stack support beyond just Node.js.

"We started out very Node.js focused, then expanded bit by bit, but we needed to scale fast. It was a grind."

They didn't abandon the developer focus—that remained core to the product philosophy. But they added the layer security teams needed to write checks.

"From a product perspective, we had to build all the capabilities around threats so the product wasn't just enterprise-grade, but also matched the breadth and needs of a security user."

From a go-to-market perspective, they evolved what Guy calls a "pincer movement."

"We kept working bottom-up—getting developers to use it and, in smaller companies, going straight from the user to the buyer. We'd get the developer to refer us internally to the right person."

But for larger companies, they paired that with outbound. "We'd reach out to AppSec leaders and say, 'Hey, did you know that seven developers in your organization are already using and loving Snyk? Do you want to talk?'"

That combination—organic developer adoption plus proactive security sales—became Snyk's sustainable growth engine.

Guy also invested in ecosystem building: launching The Secure Developer podcast, creating DevSecCon, building a DevSecOps community. "We weren't just building a company—we were building a movement."

There was also external validation. In 2017, the Equifax breach hit—300 million records compromised because of an unpatched Java Struts vulnerability. "A massive breach, and that was a straight-up Java Struts issue. The CEO ended up testifying in front of Congress."

Snyk dealt directly with exactly that vulnerability type. "We happened to be dealing directly with that exact vulnerability. So we picked both the right developer-focused approach and a problem domain that was much more about motivating people to take action."

The Inflection Point: $100K to $19M

The transformation was dramatic.

Two years and two months in: $100,000 ARR after burning $4 million.

Four months later: $650,000 ARR.

One year later: $4.5 million ARR.

One year after that: $19 million ARR.

"The numbers really started escalating at that time," Guy recalls.

What changed was having both sides of the equation. Developers loved using Snyk. Security teams could govern it, measure it, and justify the spend.

The pincer movement worked. Smaller companies converted directly from developer to buyer. Larger enterprises responded to the combination of existing internal usage plus proactive outreach.

"For a while—and hopefully still today—Snyk became a kind of modern indicator. If you were using it, it said something about your company's culture and forward thinking."

Today Snyk does over $300 million in annual recurring revenue with thousands of enterprise customers. Guy raised $125 million total for the company and brought in Peter McKay as CEO around year five to complement his skills.

The lesson wasn't to abandon PLG or developer focus. The lesson was understanding that in markets where users aren't buyers, you need product-user fit AND product-buyer fit simultaneously—and they require different capabilities, different features, different conversations.

Building Tessl: Anchoring in the Future

After a decade building Snyk, Guy took a proper sabbatical at the end of 2022. When he returned, he started working on Snyk's AI strategy but caught the bug to build something new.

"The more I dug into that, the more I realized—that's what I wanted to build next," Guy says. "The last step was just admitting to myself that I'm an addict. I love building."

He founded Tessl in early 2024 with a radical thesis: in an AI world, software will move from being code-centric to being spec-centric.

"Today, software is defined by code. You start with some requirements, write the code, then throw those requirements away," Guy explains. "Eventually, the code itself becomes the only definition of what your product is. Nobody really remembers the original functional requirements."

Large language models change that. "You can capture what you want to build—in a document or structured spec—and let the AI write the code."

Tessl is building the infrastructure for that future: what specs look like, how you debug them, how you observe running systems, how you version them.

The company raised $125 million across seed and Series A. "I don't always recommend raising that much early," Guy admits, "but I say proudly: I have zero interest in building something small. We're building big."

His advice to founders reflects the Snyk journey: "Anchor in the future—build something that in five years will be more important, more needed, not less. Your most precious resource as a founder is your time."

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. You can't quite walk away, but you're not where you wanted to be."

That wisdom came from spending two years and $4 million learning the difference between product-user fit and product-buyer fit—and finally figuring out you need both.

Frequently Asked Questions

What is the difference between product-user fit and product-buyer fit?

Product-user fit means your actual users love the product and find it valuable—they use it regularly, recommend it to colleagues, and integrate it into their workflows. Product-buyer fit means the person who controls the budget sees enough value to pay for it. These are often different people in enterprise software. Developers might love a security tool (product-user fit) while security teams who control budgets don't see governance features they need (no product-buyer fit). Success requires solving both problems.

Why does PLG work better when the user is the buyer?

PLG (product-led growth) works best when the distance between user and buyer is small because monetization feels natural—the person experiencing value is the same person making the purchase decision. When a developer loves a tool and that same developer has budget authority or minimal approval requirements, conversion is straightforward. When the developer loves the tool but a distant executive must approve the purchase, you need enterprise sales capabilities, governance features, and ROI justification that the user doesn't care about.

How did Snyk grow from $100K to $19M ARR?

Snyk grew by rebuilding the product to serve both developers (users) and security teams (buyers) simultaneously. After two years stuck at $100K ARR with thousands of engaged developer users, they spent a year adding governance features, reporting, enterprise organization coverage, and multi-stack support that security teams needed to write checks. They combined bottoms-up developer adoption with outbound sales to security leaders, creating a "pincer movement" that converted organic usage into enterprise contracts.

What is the minimum unit of value and why does it matter?

The minimum unit of value is the smallest value proposition that's truly valuable to someone. For developer tools, it's a single developer on their desktop—one person can derive value immediately, enabling bottoms-up adoption. For security products, the minimum unit is organizational governance because security's value is risk management across the entire company. Understanding your minimum unit of value determines whether you can go bottoms-up (small unit) or must go top-down (large unit) in your go-to-market strategy.

How do you build a bottoms-up enterprise sales motion?

Building successful bottoms-up enterprise sales requires running two parallel motions: product-led growth for user adoption and enterprise sales for buyer conversion. Snyk combined developer adoption through conferences, content, and integrations with outbound sales reaching AppSec leaders to say "Seven developers in your org already use this—want to talk?" Research shows this hybrid approach requires 3-5x more go-to-market investment than pure PLG but enables enterprise revenue while maintaining developer-friendly product experience.

What should founders do when users love the product but won't pay?

First, identify whether you have product-user fit (users love it) or product-buyer fit (buyers will pay). If you have the former but not the latter, analyze the distance between user and buyer—are they the same person, or separated by organizational hierarchy? If separated, you must build features and capabilities the buyer needs even if users don't care about them. This often means governance, reporting, security, compliance, and admin controls. Simultaneously, maintain what users love while adding what buyers require to write checks.

Why is "getting stuck" worse than failing for founders?

Getting stuck means building a company that generates $2-3M ARR growing 30% annually—enough to survive and keep paying yourself, but not enough to achieve the outcome you started the company for. You can't walk away because there's real business and people depending on you, but you're not reaching the scale or impact you envisioned. This limbo can last years and waste your most precious resource: time. Failure teaches you and frees you to start something new. Getting stuck traps you in perpetual mediocrity without the learning or freedom.

Want More Founder Stories Like This?

This article is based on an episode from The Product Market Fit Show, where host Pablo Srugo interviews successful founders about their journeys from zero to PMF and beyond.

Listen to the full conversation with Guy Podjarny to hear more about Snyk's technical architecture, how they built developer community through DevSecCon, why "stranger danger" talks drove adoption, and his thesis on spec-centric development at Tessl.

🎧 Listen to the episode here →