Most software problems are ownership problems wearing a technical costume.
I am a technical product manager in cyber security. I have built and launched five products in the space, and I write about the decisions that determine whether any of them survive contact with an organization.
The gap this site is about
What the document says
What turns out to be true
The tool is deployed.
Nobody owns it in eighteen months.
The spec is approved.
The context that prices it was never in the spec.
The control passed the audit.
What I write about
-
Build vs. Buy
Why the buy decision keeps getting made badly, and what it actually costs after the contract is signed.
-
AI and the PM Role
What moving the bottleneck from execution to judgment changes about the job, and what it leaves untouched.
-
Shipping in Regulated Environments
Building product where compliance review, data sensitivity, and audit trails are part of the critical path.
Working vocabulary
All frameworksTerms I use often enough that they needed definitions. Each one links to the essay that earned it.
- The Ownership Gap
- The distance between a tool existing and someone being accountable for it, which is settled by an org chart rather than by a roadmap and shows up in incident response long before it shows up in a budget.
- Spec-to-Code vs. Spec-to-Context
- Two different gaps between a written spec and a shipped feature. AI is closing the first one, which is turning intent into working code. It cannot close the second, which is the undocumented architectural and organizational reality that determines what the intent actually costs.