Hey folks - Firas here.
This week’s PMF Playbook comes from my episode with Monzy Merza, Founder and CEO of Crogl.
Monzy is one of those founders who didn’t discover a problem from the outside. He lived it. He spent more than 25 years in cybersecurity, including time at Splunk, Databricks, and inside the cybersecurity team at HSBC, before starting Crogl.
What made the conversation valuable wasn’t just the product. It was the way Monzy thinks about founder-market fit, customer listening, and the difference between hearing a problem and truly understanding the physics of that problem.
Let me walk you through what stood out.
Founder-market fit: living the problem before building the solution
A lot of founders today build products in industries they’ve never worked in.
Sometimes that works. But in complex markets like cybersecurity, surface-level understanding is dangerous. The easy assumptions are usually wrong.
Monzy’s journey to Crogl started with a pattern he kept hearing from customers at Splunk and Databricks: security teams were never going to put all their data in one place.
That sounds simple. But it challenged years of conventional wisdom.
The standard pitch in data and security was: centralize your data, put it in one lake, and then analytics will solve the problem. But customers were saying something different. Their data was already spread across S3, Databricks, Splunk, log analytics platforms, endpoint tools, cloud services, and countless other systems.
And they were not going to move it all.
The PMF lesson is this: sometimes the market tells you the answer repeatedly, but you only hear it once you stop trying to force it into your existing worldview.
Listening to customers is not the same as hearing customers
One of the strongest parts of the conversation was Monzy’s definition of listening.
Most people say “listen to the customer.” But what does that actually mean?
Monzy described it as understanding the physics of the customer’s work. Not just the words they use. Not just the complaint. The actual day-to-day motion of the job.
If a customer says, “We want more value from our data,” the lazy interpretation is: great, here’s a better data platform.
The deeper interpretation is: what does value mean? Why are you not getting it today? What outcome would prove that value has been created? What work has to happen for that outcome to exist?
That is where the real problem lives.
In cybersecurity, the obvious phrase everyone uses is alert fatigue. Too many alerts, not enough analysts, too much noise.
But when Monzy dug deeper, he found the real problems underneath:
Analysts had domain knowledge gaps. They had tool competency gaps. And teams had collaboration gaps, where one analyst’s work did not easily compound into another analyst’s work.
That is a very different problem than “too many alerts.”
And that distinction matters.
If you solve the tagline, you build another feature. If you solve the physics, you build a company.
The aha moment: “we are never putting all our data in one place”
The moment that led to Crogl happened during a Databricks customer call.
The customer said they were never going to put all their data in one place.
Monzy had heard versions of that before, but this time it landed differently. It triggered a realization: if security data is permanently distributed, then the old model of centralizing everything before investigation is fundamentally broken.
That insight did not immediately become a pitch deck.
Instead, Monzy spent weeks challenging himself. Has this already been solved? Why had federated search not fixed it? Why had decades of tooling still left security analysts overwhelmed? What would a person on the keyboard actually need to do the job properly?
That discipline matters.
Aha moments are rarely enough. The founder still has to interrogate the insight until it either breaks or becomes stronger.
Why Monzy went back inside the problem
Before founding Crogl, Monzy did something most founders would never do.
He went back into the operator seat.
He joined the cybersecurity team at HSBC because he wanted to experience the problem directly in one of the most complex environments possible.
That decision says a lot about how he thinks.
HSBC had the resources. It had the talent. It had the tools. If even an organization like that still struggled with alert investigation, data sprawl, and analyst constraints, then the problem was not simply budget or hiring.
It was structural.
This is an important founder lesson: when you remove the obvious excuses and the problem still exists, you may have found something worth building.
Crogl: what the company actually does
Crogl works on alerts.
That was Monzy’s simplest definition.
In a security operations center, analysts can receive hundreds or thousands of alerts. Most are not meaningful. But one missed alert can become the root of a breach, a regulatory issue, a financial loss, or a CISO losing their job.
The conventional answer has been to filter alerts down.
Monzy calls that the diminishing view of the world: the idea that everything should somehow get smaller. Fewer alerts, less noise, fewer things to inspect.
Crogl takes the opposite view.
The world gets bigger. Data grows. Computing grows. Attack surfaces grow. Alerts grow.
So instead of assuming fewer alerts, Crogl investigates every alert with depth. It connects across the tools and data an organization already has, helps analysts understand whether there is evidence of threat, and documents the work automatically.
The analyst does not have to remember every schema, every query language, every tool convention, or every organizational nuance.
Crogl brings that context forward.
The PMF lesson here is clear: a great product does not always remove work. Sometimes it removes the wrong work so humans can focus on the judgment they were hired for.
The real customer: the practitioner who carries the pain
Crogl sells to security leaders, but it is built for practitioners.
That distinction matters.
The buyer might be a VP of security engineering, a security leader, or in some cases the CISO. But the user is the analyst, the threat hunter, the incident responder - the person actually doing the work.
Monzy’s pride in Crogl is tied directly to that community.
In ten years, he wants Crogl to have made analysts look like the heroes they already are. He wants their work to be captured, reused, improved, and recognized. He wants the domain knowledge gap, tool competency gap, and collaboration gap to be materially smaller.
That is a powerful founder-market fit signal.
The company is not just serving a budget line. It is serving a community.
The PMF lesson: boring problems can be the most valuable
One of Monzy’s strongest points was that many of the easy problems have already been solved.
What remains are often the boring ones.
The messy ones. The operational ones. The problems buried inside workflows that outsiders underestimate because they look unglamorous from a distance.
But those are often the highest-value problems.
In security operations, the work is not sexy. It is repetitive, detailed, high-stakes, and unforgiving. But if you can solve it, or even materially improve it, the value is enormous.
This is where a lot of founders get founder-market fit wrong.
It is not just “I know the space.” It is not just “I worked in this industry.” It is the willingness to get dirty, respect the complexity, and serve the people doing the work.
AI in security: not replacing people, but multiplying them
Monzy was clear on one thing: broad claims about replacing humans usually reveal shallow understanding.
In security, the work is too nuanced to reduce to a slogan.
Crogl is not valuable because it says, “you no longer need security analysts.” It is valuable because it helps analysts operate at a much higher level.
It investigates alerts. It documents work. It learns from analyst input. It helps analysts avoid being blocked by tool knowledge or data sprawl.
That is a much more realistic AI wedge.
Not replacement.
Amplification.
And in enterprise markets, amplification often wins because it respects how work actually happens.
The deeper takeaway: PMF starts with service
The theme I kept coming back to in this episode was service.
Monzy did not describe Crogl as a clever AI product. He described it as a way to serve a community he understands deeply.
That changes how you build.
You ask better questions. You avoid arrogant assumptions. You do not dismiss complexity. You do not build a magic wand and then go looking for a market.
You start with the people doing the work.
Then you build around their reality.
Closing thought
If I compress the entire episode into one sentence, it’s this:
PMF starts when a founder understands the physics of a customer’s work deeply enough to solve the problem beneath the obvious problem.
Crogl is not just solving alert fatigue.
It is solving the knowledge, tooling, and collaboration gaps that make security operations so difficult in the first place.
That is the kind of insight that only comes from listening properly, living the problem, and caring enough about the practitioner to build something that actually helps.
Until next time,
Firas Sozan
Your Cloud, Data & AI Search & Venture Partner
Find me on Linkedin: https://www.linkedin.com/in/firassozan/
Personal website: https://firassozan.com/
Company website: https://www.harrisonclarke.com/
Venture capital fund: https://harrisonclarkeventures.com/
‘Inside the Silicon Mind’ podcast: https://insidethesiliconmind.com/