About
I diagnose. I don't implement.
Most people who get called into a broken business are there to build something. That's the problem — the last three things you built are why you're calling.
The short version
I'm Jon Martin, a revenue operations solutions architect. I spent 12 years building and running RevOps functions, and I founded two firms, scaled both, and sold both. Today I work in systems integration and subscription management, mostly for SaaS and professional services companies, and I treat the job as variety management, not tooling. What I write here are diagnoses of why systems and org structures keep breaking in founder-led professional services firms, and why the fixes didn't hold.
What I actually do
I work in revenue operations — systems integration and subscription management, mostly for SaaS and professional services companies. The job looks like tooling from the outside. It isn't. It's variety management: deciding what complexity a business should absorb, what it should refuse, and whether the answer is new tooling or a redrawn boundary.
That distinction is the whole reason this site exists. A company that can't quote consistently doesn't have a CPQ problem. A company whose reports nobody trusts doesn't have a dashboard problem. Those are symptoms of a structure that produces them reliably, and replacing the tool leaves the structure intact — which is why the new tool breaks in the same place the old one did.
Why a second opinion, and not a project
The highest-leverage move in operations is usually to move a team boundary, and that's almost never available to the person brought in to fix the process. I do a lot of my work as an external designer — hired to fix the system, not to redraw the org.
So the deliverable is a written diagnosis: here's what's actually breaking, here's the constraint you can't remove, here's what it costs you a year, and here's the best system available inside it. Naming a constraint you can't remove isn't failure. Pretending you can automate around it is.
Where the framework comes from
Four systems laws do most of the work: Ashby's Law of Requisite Variety, Conway's Law, Brooks's Law, and the Reverse Conway Maneuver — with Beer's Viable System Model behind them. I've written the whole thing up as a standing reference rather than re-explaining it per engagement, and separately as a plain-language series for anyone who'd rather start there.
Four Laws of Complex System Design → · Start the writing series →
Portal Audit
Portal Audit is the packaged version of what I look for in a HubSpot portal. It's a free health check with a scored report and a 90-day plan. AI is the lens. The standard is mine: the best practices and the problems I've seen over 11 years across B2B SaaS, B2B services, custom manufacturing, and the companies that work inside and on top of HubSpot. It never changes anything in your portal unless you turn fixes on. Run my free audit →
Getting in touch
Everything else is still a conversation. If you want to talk through a consulting engagement, an advisory conversation, or a second opinion on something specific, send a note below. I read and reply to these myself.