My background is all over the place. I like to say with some self-sarcasm that I've had a professional identity crisis my whole life. I studied business administration in Greece, then did operations research and quantitative analysis in the UK, worked in the Netherlands doing operations management in pharmaceuticals, and then switched to civil engineering at Stanford, which ended up being my longest stay in any one domain. I've been in tech for over ten years now, in roles ranging from implementation and customer success all the way to product, and I've been through every product level from product owner up to vice president of product development, managing teams globally and launching B2B enterprise SaaS from zero to one and then scaling it.

These days I'm mainly in management consulting. I advise large organizations on digital transformation and how to leverage technology, automation, and operational excellence. With the rest of my time I coach, both through GrowthMentor and as a personal trainer, and I do a bit of photography on the side. I'm also building something new on my own that's still very early.

If you ask me what the common thread is through all of it, it's bringing order to chaos. Whenever I see a problem that's super messy, I'm inherently drawn to making it better: structuring things, cleaning things out, designing solutions. That's what pulled me from business-oriented domains toward engineering in the first place. I wanted to solve practical problems with tangible impact, the kind of thing you can point at years later and say I was involved in that outcome.

The mentees who approach me are usually well organized and have thought through what they want out of the meeting, so I'm lucky that way. The common thread is something I struggled with myself when I was starting out in product management: they're trying to distill the tools, methods, and frameworks that actually work. There's a ton of information online, and the quality is questionable. Anyone can find theoretical frameworks. The art is in implementing a framework and fitting it to your specific context and needs.

When I was starting off I had the same tendency. I'd find a framework and instinctively want to apply it end to end, exactly by the book. What I've learned is that you don't need to over-operationalize. You need an experience filter to figure out which bits and pieces you actually need from framework A or approach B, and then amalgamate them into something that works for your case.

A lot of it comes down to fighting the FOMO. People come in worried, am I doing something wrong, should I be doing something else? I try to give them the confidence that they don't need to spend time on certain things. I think in terms of marginal added value: yes, you can do this, but the value you'll get is not going to be huge, so prioritize and put it down. I push people to avoid looking for a silver bullet. Some come in framing it as agile versus waterfall, this approach versus that one, and honestly it doesn't matter. Just understand what you need and what the outcome should be, then borrow pieces and build your own thing.

A lot of founders, especially early on, feel they know everything. They know their product best, they know how it should be built, they know what it should do. That's not entirely baseless, but there's a very high risk of bias precisely because you're so close to it. The product is your baby, you see it as an extension of your own arm, and it becomes extremely hard psychologically to take a step back and admit you don't necessarily know everything that needs to happen.

So it comes down to divide and conquer. Partner with someone who actually knows product. I had to fight to inject product management DNA into my own company, because at first we assumed we didn't need it. We figured customer success and sales were in the trenches picking up insights, so they'd tell us what to build. That was wrong. With startups I advise, this is something I invite founders to at least flirt with: bringing in someone who knows product early, even part-time. It pays dividends down the line.

The other thing I emphasize is research discipline. When you're early, follow the design thinking mindset, scrappy, fail fast, learn faster. For market validation you don't need a statistically huge sample. Six to ten interviews and you start seeing the patterns already, which is enough to take the next step. Start qualitative, then as you get traction and real usage, layer in quantitative metrics to validate what you're hearing. I keep a quarterly qualitative research cadence so you never lose touch with customers, because when you're heads down on priorities it's the first thing to slip.

And above all, the top variable early on is people. Whether you're raising money or shipping, people make it or break it. When you're a three-person team, investors know you don't have a product yet, so the initial investment is really in the people.

Because the mental game matters more than people admit, and a structured conversation can change someone's whole trajectory. I tend to view things holistically, not just professionally. It's not only here's a playbook, go do this. Being at a startup over the years takes a real toll, so I try to tap into the mental support side of it, because that affects performance and life and everything else.

The best part for me is the same thing that makes the work worthwhile: helping someone cut through the noise and feel confident about what to leave behind. So much of mentoring is reassuring people that they don't need to chase every shiny thing, that the marginal value of some effort just isn't there, and that they can focus on what genuinely moves them forward. When someone walks away clearer and calmer about their priorities, that's the whole point.

It also keeps me sharp. I get to think about different challenges I wouldn't run into in my own day-to-day, and I get to meet people who are genuinely excited to build something. That energy is contagious, and it's a big reason I keep showing up.