🧭 Readme

I originally wrote this for new teammates and stakeholders. I share it publicly because clear expectations create higher-trust, higher-output teams. If we work together, this is how I tend to think and operate. For my background and current work, start with About.

Last updated: October 2026

Who I am

I care about individual product decisions and the systems that help a team make good ones repeatedly. The product and the way people build it both need attention.

Core philosophy

Systems that ship, teams that thrive

The throughline in my work is simple:

Build systems that make it easier to ship good work, without burning people out.

I think of process as guardrails on a mountain road: they should give talented people the freedom to drive fast while staying safe. When process becomes theater, I’m usually the one asking, “Is this still serving us?”

Context over control

I lead by:

You won’t see me micromanaging tickets. You will see me asking questions, unblocking, and pushing us back to the outcomes we’ve agreed on.

Execution and strategy together

I don’t believe product leaders (or PMs) should choose between “strategic” and “execution” work.

The real craft is:

I’m comfortable moving from a leadership conversation about product bets and team capacity into a working session with a squad to design the next useful slice.

Small teams, clear direction

I’ve seen small teams make progress that larger groups struggled to make when:

I want the team size, skills and investment to fit the work. Clear direction and useful feedback matter alongside headcount.

How I approach product

Taste & tools

I gravitate toward tools with a point of view. These are examples of design that have shaped how I think:

My earlier AI exploration included Cursor, n8n, ChatGPT and Claude. Today, I design and build agentic systems in Claude Code. The work has moved from trying tools to deciding how context, tools, agents and human review fit together.

Offline, I shoot with a Fuji X-T50. The tactile controls and constraints force intentionality. I bring that same bias for intentional systems into product work.

AI: user flows and agent flows

I believe product leaders need to make things to understand the choices AI opens up. At Float, I authored an early AI strategy and worked with Move37, an AI consultancy, on a proof of concept. We drew agent flows alongside user flows to question what the system should do in the background before a larger product commitment.

That remains a useful distinction. A user flow shows what a person does. An agent flow shows the work a system takes on, the information it needs and the points where a person reviews or decides.

In my current work, I design agent responsibilities, context and tool access, build reusable skills and compare outputs with sources. I investigate where a workflow loses important information and work with engineering partners on defects and shared adaptations. People using the workflow need a part in those checks too.

The questions have become more concrete:

I wrote about the human decisions around AI in The 70/30 rule behind every stalled AI ROI story. A workflow can produce more output without changing what a team can use. I want us to understand that difference when we choose what to build.

Collaboration & remote work

Great products come from great collaborations, but collaboration ≠ meetings.

Leading distributed teams across time zones, I’ve found that async-first workflows can give more people room to think and contribute:

At Float, I designed a mix of asynchronous updates and focused live collaboration, and led the company-wide migration from Asana to Linear. Automated roadmap updates kept context close to the work. Demos and conversations gave people a way to question it.

We still meet — but the meeting is usually the end of the thinking, not the beginning.

How I work day-to-day

Strategy & transformation work

When I’m brought in to develop a product direction or change how a team works, you’ll see me:

I prefer:

Small, well-framed experiments → honest feedback → iterate or roll back.

With squads and teams

Working with squads, you can expect me to:

I’m happy to get into the details when it’s useful — but I try not to disempower teams by taking the work out of their hands.

Communication & time

Async vs sync

Practically, that means:

1:1s

In 1:1s, you’ll often hear me start with:

“What’s on your mind?”

I’m not looking for status reports (we have tools for that). I want to hear:

Time management

I treat my calendar as a focus tool, not just a meeting grid:

I also protect some time for being a present parent and human. I’m transparent about those boundaries and expect teammates to have (and defend) theirs too.

Feedback & decision-making

How I give feedback

You can expect feedback from me to be:

I’ll give feedback both in the moment (if appropriate) and in more reflective 1:1 settings.

How I like to receive feedback

I’d rather hear the hard thing early.

Useful feedback for me usually:

Written or live are both fine — whatever feels safest and clearest for you.

Decisions

My decision-making blends:

I’m biased toward:

When a decision is made, I like to write it down: the decision, why we made it, what we’ll watch, and when we’ll revisit.

The “Operating System” metaphor

One way I describe the organizational side of product leadership is this:

I’m there to help you install and evolve the operating system for your product organization.

That includes working with the team to:

Beyond work

I wrote about the move in A new chapter in Athens.

Why I share this

I’ll keep evolving how I work as I learn from new teams, technologies, and contexts. But if you’ve read this far, you should have a clear sense of what it’s like to collaborate with me.

If you’d like to compare notes about product, AI or working together, connect with me on LinkedIn.