I turn growth problems into decisions you can defend.

1. 01

   Problem

   Find the problem worth paying for

   What's broken, and who pays for it staying broken?

   Read the data, the funnel and the org side by side. Talk to the people living with it. Name the gap everyone has stopped seeing.

   GateThe problem is named, sized, and costs someone real money or time.
2. 02

   Proof

   Prove demand before you build

   Will anyone actually pay to fix it?

   Real conversations, a priced offer, a pre-sale or a pilot. Opinions don't count. Commitments do.

   GateSomeone asks for the price, signs up or pays.
3. 03

   Product

   Ship the smallest thing that works

   What's the least we can build that solves it?

   The fix, not the deck: a feature, an offer or a process. Cut scope until it hurts, then measure.

   GateIt's live, people use it, and the core number moves.
4. 04

   Pipeline

   Make customers arrive on purpose

   Where does the next customer come from?

   Channels, funnel and conversion, mapped step by step. Fix the leakiest step first, then the next one.

   GateYou know the cost and conversion at every step, and it repeats.
5. 05

   Profit

   Make the revenue hold

   Does each sale make money, and does it keep coming?

   Pricing, unit economics, retention, and systems that run without me in the room. What you learn feeds the next Problem.

   GateMargin is positive, revenue repeats, and the team runs it.

Start at whichever stage is broken. Most teams think they're stuck at Pipeline. Usually they skipped Proof.

Underneath the job titles, I'm someone who's always been more interested in why something is broken than in whose job it was to fix it.

I grew up curious about systems — not just how they're built, but why they quietly fail the people relying on them. That curiosity turned into a career: two decades moving between marketing, analytics, product and technology, usually landing wherever a problem didn't fit neatly into one department's job description.

What I care about hasn't changed much in twenty years. I want to understand how something actually works, find the part that's costing more than anyone realizes, and fix it in a way that holds up after I've moved on. I'm drawn to ambiguity for the same reason some people are drawn to a puzzle — not because I enjoy the mess, but because I enjoy what's on the other side of it.

I work best where strategy and execution meet: in a strategy conversation in the morning and a technical one in the afternoon, useful in both. I've spent most of my career building that range, one uncomfortable, cross-functional problem at a time.

Today I lead teams and problems worth leading, build small products and free resources that make someone else's job easier, and write, because business was never the only place I found people interesting. The thread through all of it: I'd rather leave something better than I found it.