My Philosophy

Aug 30, 2026

Β·

Design

Β·

5min read

My Philosophy

Aug 30, 2026

Β·

Design

Β·

5min read

My Philosophy

Aug 30, 2026

Β·

Design

Β·

5min read

My Philosophy

I’ve spent most of my career working on products where the problem was bigger than the interface.

Usually, there are a lot of things happening at once: a business requirement, a technical constraint, a customer need, a GTM strategy, and a product somewhere in the middle trying to satisfy all of them.

That’s the kind of problem I enjoy.

I tend to work closely with founders, product and engineering teams, and GTM. Not because I think a designer needs to own all of those functions, but because you can’t really design the experience without understanding what’s happening around it.

A product might have a usability problem. But sometimes the reason people aren't adopting it is that the value isn't clear. Sometimes customers understand the value but the workflow doesn't fit how they already work. Sometimes the product works well, but the sales story and the actual experience don't line up.

And sometimes the product has simply grown faster than the experience.

These are different problems on the surface. But they can lead to the same outcome:

People don't understand the product β†’ don't trust it enough to use β†’ and don't keep using it.

The interface is only one part of the experience.

This becomes particularly important with technically complex products.

The more difficult something is to build, the more difficult it can be to communicate.

You have to make sense of what the product actually does β†’ make the value obvious β†’ give people enough context to trust what they're seeing β†’ and create workflows that make sense within the way they already work.

That's not just a UI problem.

It's a product problem, a business problem, and sometimes a positioning problem.

This is also why I tend to work across brand, product, websites, and systems. They're often solving different parts of the same underlying problem.

I care about what happens after launch.

A design can look great when it ships and still become a problem six months later.

β†’ The product changes.
β†’ The team grows.
β†’ New features get added.
β†’ The business changes direction.
β†’ Sales starts asking for things engineering wasn't planning to build.

The experience has to survive all of that.

So I care about building things that aren't just good at launch, but strong enough for the business to keep evolving.

That's probably the biggest thing I've learned from working across startups and larger organisations:

Good design isn't just about getting the experience right. It's about understanding what the experience needs to do for the business β†’ and making sure it can keep doing that as things change.

Business β†’ Product β†’ Engineering β†’ GTM β†’ Experience

I don't see these as separate disciplines.

They're different parts of the same problem.

And that's where I tend to do my best work.

Have a complicated problem?
Let's untangle it.

Working πŸ‘©πŸ»β€πŸ’»

Β·

Between IST & EST

Β·

Unreasonably in love with systems design, GTM, and CX.

Have a complicated problem?
Let's untangle it.

Working πŸ‘©πŸ»β€πŸ’»

Between IST & EST

Unreasonably in love with systems design, GTM, and CX.

Have a complicated problem?
Let's untangle it.

Working πŸ‘©πŸ»β€πŸ’»

Β·

Between IST & EST

Β·

Unreasonably in love with systems design, GTM, and CX.