Most writing about GTM sounds clean because it hides the operating mess.
That is usually where the value disappears.
I built this journal as the public layer behind my portfolio and private working system. The point is not to publish hot takes. The point is to make the work legible enough that a founder, hiring manager, or operator can inspect the thinking and decide whether it holds up.
What will show up here:
- GTM systems thinking grounded in actual operating constraints
- revenue architecture notes that connect signal, routing, ownership, and outcomes
- AI workflow design with an emphasis on quality control, not novelty theater
- frameworks that make a messy motion easier to explain, teach, and adopt
I care about systems that survive contact with people.
That means:
- signal must be interpreted before it is automated
- routing must be owned before it is measured
- process must be teachable before it can really scale
Some of the writing here will read like operator memos. Some will read like field notes. Some will be closer to frameworks or publishing doctrine.
All of it is meant to answer one question:
If a team asked me to step into the motion, what would I notice first, what would I redesign, and how would I make the change understandable to the people who have to live inside it?
That is the lane.