I turn unclear product problems into things people actually use.
I've spent 10+ years in product, across B2B SaaS, telecom, and a startup I co-founded. I started out as an engineer, scaled a product to millions of users, and these days I build AI products myself instead of just writing specs for them.
Most product problems aren't technology problems. They're clarity problems.
I'm at my best early on, when the idea is still fuzzy and nobody agrees on what to build first. That's the part I actually like: figuring out the real problem and getting people to commit to what ships next.
I came up as an engineer, so I can talk to developers without hand-waving, and I've felt what it costs to build the wrong thing. I co-founded a company and learned that the expensive way. I've run products end to end: discovery, delivery, and the messy growth phase after launch. Scaled one to millions of users, took another from zero to paying customers. Where I'm most useful is the people part: getting business, engineering, and design to stop talking past each other.
The part I enjoy most is the team itself. I like pulling together small groups of people who are excellent at what they do, then working right next to them on the problem instead of running it from a distance. Six engineers at Perforlabs, and a team of fifteen-plus before that. That closeness is usually where the good calls come from.
Right now I'm going deep on AI product management, and I learn by building. The projects below are live, not slideware.
What I'm good at
Where I've built
Perforlabs
I own the enterprise roadmap for a B2B security platform. Enterprise was where the growth was, so I made the case for it and led a 6-engineer team to build an API service for enterprises and MSSPs. It added 7%+ ARR once the first enterprise customers were onboarded.
When marketing committed features with executive sign-off but no engineering capacity, I pushed back. I heard them out, took the scope trade-off back to the executive, and the request was deferred to the backlog instead of breaking the roadmap.
Datik
I co-founded a pricing-intelligence platform and took it from an idea to paying customers. Talking to users, the real problem turned out to be the speed of decisions, not the data itself, so I rebuilt the product around that and shipped a recommendation service that lifted retailer click-through about 10%.
When engineers and designers clashed over scope, I opened a direct channel between them and got them collaborating early, so we shipped a lighter first version without scope creep and phased the full design across later sprints.
TOSAN · Badr Electric
Ran big Oracle databases for banking systems, and before that built sales and inventory software in Delphi. This is where the engineering side comes from, and it still shapes how I work with dev teams.
Selected problems, up close
Turning a failed enterprise pilot into a paying segment
Our platform was built for MSSPs: data-heavy, and priced for that volume. When we tried to move into enterprise, we ran a one-month pilot, and at the end of it the enterprise customers told us plainly they didn't want to keep using it. The issue was fit, not sales effort.
Instead of pushing the pilot harder, I went back and talked to the enterprise users to find out why. Two things came out. They didn't want all the data: what made the product valuable for an MSSP made it noisy for an enterprise security team. And the pricing, built for MSSP volume, was too expensive for their use case. I took both problems to engineering and leadership. Rather than rebuild the whole platform, we shipped an API that plugged into the customer's own systems, so they worked inside the tools they already used, got real-time notifications, and saw only the filtered data that mattered to them. We paired it with pricing that fit an enterprise. It took two sprints.
The customers who had walked away from the pilot came back and bought the API. They became part of our customer base, and by year-end that enterprise segment had lifted our annual revenue by about 7%.
Following the real pain into a better market
I co-founded Datik as the commercial co-founder. The first product was a consumer price-monitoring service: we tracked the best deals and notified people based on what they were watching for. We launched an MVP and reached about 100 active users, but when I interviewed them the pattern was clear. People tried it once and didn't come back month after month. Retention, not acquisition, was the real problem.
Rather than keep tuning a consumer product that wasn't sticking, I started talking to the other side of the market. Retailers had a sharper and more expensive pain: they wanted to watch competitors' prices in real time and compare their own against them. That was a problem worth paying to solve. So we pivoted from a B2C affiliation model to a B2B price-tracking tool for retailers, and moved the business from affiliation revenue to subscriptions.
The pivot worked where the original hadn't. Engagement improved once we solved a problem retailers would pay for, and the recommendation service we built lifted their click-through by about 10%. Just as important, moving from one-off affiliation to subscriptions gave the business recurring revenue instead of one-time payouts.
Things I've shipped
BeautyFind NL
Live ↗A beauty-product discovery tool for the Dutch market. It ranks products on actual ingredient data instead of marketing claims, so you can compare them on something real.
CleanFind NL
In developmentA B2B platform for EU cleaning-product catalogs. It enriches messy catalog data while keeping regulatory hazard info and manufacturer claims properly separated, which is the part everyone gets wrong.
AI Interview Coach
Live ↗Interview practice for PMs. It runs different recruiter personas (startup, scale-up, big tech) and scores each answer so you can see where you're weak. Built in React on the Anthropic API.
Datik
Founder projectThe pricing platform I founded for Dutch e-commerce, covering price tracking, product comparison, and retailer affiliation. My zero-to-users founder chapter, and where a lot of this thinking started.
Get the problem right
Before anyone writes code, I make sure we actually agree on what we're solving and who for. Most wasted work starts here.
Cut it down
Find the smallest version that really tests the idea, and drop everything else for now.
Build something real
Get a working version out fast, so people can react to a thing instead of a doc.
Put it in front of people
Watch how they actually use it, learn from that, and decide what's next.
Working on something unclear and want a second brain on it?
Reach me directly. I read everything.