04 — The Method
We did not start with answers. We started with constraints.
The three projects did not develop in neat chronological sequences. We followed unproductive leads, built things that needed rebuilding and sometimes only understood the problem properly after seeing the result.
We teach the logic that became visible at the end, without pretending the path was obvious at the beginning. The dead ends are still important when they explain a decision or reveal a general failure mode.
1. Define the problem without substituting a slogan
"Make more money" is not the same problem as "create income that is not paid for hour by hour." "Relax" is not the same problem as "recover enough capacity to engage with life beyond immediate demands." "Communicate better" is not the same as "develop a relationship where trust survives difficult conversations."
We begin by identifying the actual constraint and what improvement would mean.
2. Understand the mechanism and its limits
We investigate what drives the problem. What consumes capacity? What reinforces the present arrangement? Which factors can be changed, and which are external constraints or dependent on other people?
This is where relevant disciplines come in: economics and markets, physiology and experimental measurement, or communication and interpersonal learning. A useful analogy may connect domains; it does not prove that their causal mechanisms are the same.
3. Generate alternatives and expose the trade-offs
An intervention can solve one problem by creating another. Automating trading can reduce repetitive labour while increasing technical complexity. A strong bodily stimulus may change state without supporting recovery. A candid disclosure can be accurate but badly timed or disproportionate.
We compare candidate responses against the actual constraint, risk, operating cost and reversibility — not just how attractive they sound.
4. Build something observable
Ideas become useful when they can be examined. That may mean software and data pipelines, a defined experimental protocol, or deliberate practice with a communication scenario.
Where possible we record what was attempted, what happened, and the limits of the observation. A working system, a plausible theory and a demonstrated outcome are different claims.
5. Look for failure and revise
We do not have to defend a model because we spent time developing it. Unexpected outcomes, data problems, confounding factors and a person responding differently than predicted are reasons to revisit the explanation.
Some apparent dead ends become important case studies: they show why a final system has a particular constraint, test or safeguard.
6. Preserve the gain, rather than restarting every day
Our final question is whether an improvement lasts. What ongoing maintenance does the solution demand? What happens under stress or failure? Can the arrangement be sustained without consuming all the surplus it creates?
That question belongs at the end of every investigation, not just at the beginning.
How we turn the work into education
Each educational module is organised around an engineering question, rather than a date in the development diary:
- The original problem and why it mattered.
- The constraints and missing knowledge.
- The alternatives we considered.
- The reasoning, trade-offs and informative failures.
- The system or practice we developed.
- What we observed, what remains uncertain and what changed.
- The principles that might transfer to other problems.
The examples are our own investigations, not instructions for students' personal investment, medical or relationship decisions. We are teaching how we reasoned, built and revised.