Understand before designing
A good solution starts with understanding the actual problem, not the requested feature.
ABOUT TEGAR
I started out in engineering and somehow ended up in product. The path in between went through IoT, mobility, education, and now digital commerce. The industries changed, but the part I kept enjoying was surprisingly consistent: figuring out how things work, why they work that way, and what needs to change when they don’t. These days, that usually means working through messy product problems where user needs, business constraints, data, operations, and technical systems all collide. I don’t always have the answer going in. I just like getting the problem clear enough that the next decision becomes easier.

THE SHORT VERSION
Most product problems aren’t purely product problems. A checkout issue can involve UX, payment rules, backend services, operations, analytics, and commercial priorities at the same time. That’s probably why my engineering background still shows up a lot in how I work. I tend to map the moving parts, understand the constraints, and look for where the actual problem sits before jumping into solutions. I care less about having the cleverest answer in the room and more about helping the team arrive at one that actually works.
WORKING PRINCIPLES
A good solution starts with understanding the actual problem, not the requested feature.
Build enough to test the assumption. If it fails, I'd rather find out early.
Keep the objective clear and separate signal from noise. Opinions are inputs, not conclusions. Keep the objective clear and use evidence where we have it.
If a problem feels complicated, map it out. Things get easier to discuss once everyone can see the same thing.
Features rarely live alone. Understand what they depend on, what they affect, and what happens after they ship.
Data doesn't make decisions for us. It helps us ask better questions and challenge our assumptions.
Every choice costs something. Make the constraints, alternatives, and consequences visible before deciding.
Shipping is where assumptions meet reality. Watch what happens, learn from it, and improve from there.
WHAT I BRING
FOCUS AREAS
Product domains that appear most often across my work.
SKILLS & THINKING THEMES
Capabilities and ways of thinking I rely on most often.
TOOLS & TECHNOLOGIES
Technologies that appear across my work, plus other tools I use regularly.
BEYOND WORK
My curiosity doesn’t really stop after work; it just becomes less useful. Sometimes that means messing around with a Raspberry Pi, building a tiny tool nobody asked for, reading about some obscure piece of history, taking photos, or going somewhere simply because I’ve never been there before. I also spend an unreasonable amount of time going down rabbit holes about technology, cities, infrastructure, football, fashions, vespa, coffee, and whatever question happens to bother me that week. Most of it leads nowhere. Occasionally, something comes back and becomes useful at work. That’s probably why I keep doing it.
LET'S TALK
Product, systems, something you're building, or just an idea worth comparing notes on—feel free to reach out.
SAY HELLO
Share as much context as you think is useful. Email works best; WhatsApp is usually faster.