Method
How I approach a question
AI interprets. Data grounds. Models expose trade-offs. Humans decide.
This is not a rule against language models. It is a rule about where judgment comes from: use models for interpretation and unstructured information, without allowing generated language to replace arithmetic, evidence, or accountable strategic judgment.
Step 01
Frame the decision
Start with the decision, not the technology: what choice is being made, what alternatives exist, and what would cause one option to beat another?
Strategic questions usually arrive too broad to analyze directly. Convert them into a decision with explicit objectives, alternatives, constraints, and failure conditions before choosing tools or data.
Step 02
Structure the ambiguity
Use AI where interpretation is genuinely required, then expose the structured assumptions it produced so they can be corrected rather than trusted implicitly.
Examples include translating a business description into target-customer assumptions or extracting strategic priorities from management language. The output of this step should remain inspectable and editable wherever practical.
Step 03
Ground it in evidence
Connect the structured question to data, documented assumptions, or explicit economic rules rather than allowing generated language to become evidence.
Evidence may include Census observations, SEC filings, XBRL facts, financial statements, benchmark outputs, or deliberately fictional scenario parameters. The source and data mode must remain visible.
Step 04
Make the trade-offs inspectable
Put weights, formulas, thresholds, missing information, and alternatives where the reader can see what is driving the answer.
A useful strategic model should make disagreement more precise. If changing one weight flips the recommendation, that is part of the finding rather than an inconvenience to hide.
Step 05
Stress-test the answer
Try to break the conclusion by moving the assumptions, reversing the perspective, or searching for the conditions under which the recommendation fails.
Across the portfolio this appears in different forms: Monte Carlo sensitivity, role reversal, challenger tests, narrative-versus-financial evidence, and Break My Thesis. A conclusion that survives an explicit attempt to invalidate it is more useful than one that was only optimized to look persuasive.
What the labels mean
Every project carries two labels, and they are separate claims. One describes the software; the other describes the evidence. A project can have a working demo and no measured results, or specified evidence and no software at all. A successful build is never a reason to move either label.
| Label | What it means |
|---|---|
| Concept | Designed and specified. No runnable demo and no measured results yet. |
| Prototype | A working demo runs. Results are reported by the evidence label. |
| Published | An authored case with reviewed evidence. |
| Label | What it means |
|---|---|
| Illustrative | Hand-authored or specified content used to show structure. No performance claim of any kind. |
| Measured, partial | Real output from a recorded run, archived with its run metadata. Covers part of the question, not all of it. |
| Reviewed | Measured evidence that a person has actually reviewed against a stated rubric. |
All five projects are currently Prototype: the software runs and each one is deployed where you can reach it. Market Entry War Room, Narrative vs. Numbers, and The Moat Test carry Measured, partial evidence; Disrupt This Business and Priced In remain Illustrative. No case publishes a universal recommendation, because software that runs is not a finding.