CRISPER. Open-source SIEM, productized from 0 to 1.
Take an open-source security platform with real engineering merit and a difficult brand. Turn it into a white-labeled, client-ready product with a clear roadmap, named pillars, and a launch. I co-led the productization. The product side, not the code.
The brief.
Wazuh is excellent open-source security software. It is also, as a product to take to a non-technical client, a hard sell. The brief was to wrap it into something that could be quoted, demoed, deployed, and supported under a single brand. Internally, we called the destination CRISPER.
How I scoped a 0-to-1 productization.
Five product pillars. Each one had a clear definition, a clear owner on the technical side, and a clear “what does client-ready mean for this” line.
- SIEM core. The Wazuh engine, hardened and configured against a baseline ruleset that matched our target client profile
- XDR. A client-ready detection and response surface, with playbooks and triage flows that our consultants could actually run
- Vulnerability management. v1 scope. Defined what was in, what was out, and what would slip to v1.1
- Alert triage with GPT. An LLM layer over alert noise to surface what mattered. The credibility piece for any modern security buyer
- Brand and packaging. CRISPER as a name, as a deck, as a one-pager, and as a deployment template
The product work I owned.
Roadmap
A 6-month plan with milestones tied to client-ready definitions, not feature counts. Every pillar had a Friday demo cadence that the team could deliver against without theatrics.
Feature prioritization
Hard tradeoffs. The vuln management dashboard was beautiful but expensive. We shipped a leaner v1 that covered the buyer’s top three questions, and pushed the rest to v1.1. The buyer got a product. We got a launch.
Stakeholder alignment
Engineering wanted to keep building. Sales wanted to start quoting. Leadership wanted a story. I held the calendar that made all three groups happy at the same time, mostly by being honest about what was and was not in v1.
Deployment coordination
Turning a launch artifact into a thing that gets installed inside a client environment. Templates, runbooks, the boring infrastructure that makes a 0 to 1 product survive its first three deployments.
What it says about how I work.
- I scope products around buyer questions, not feature wishlists. v1 answers the top three. v1.1 earns the right to answer more
- I co-lead with engineers. They build. I shape the box, the story, and the launch. Both jobs are real
- I treat brand and packaging as part of the product. A great SIEM with a confusing name is a worse product
- I run launches with Friday cadence. A weekly demo says more about velocity than any roadmap doc