Principles
Compressed thinking. The rules I keep returning to, in the shortest form they still make sense in. The longer versions live in Thinking.
Automation accelerates whatever already exists. If the underlying process is broken, you just produce broken outcomes faster.
Root cause before solution
Diagnose before you prescribe.
Most failing initiatives are competent answers to the wrong question. The first job is not to solve — it is to find out what is actually broken.
- Root cause before solution — Most teams start designing the fix while the problem is still a rumour.
- One question changed the problem — Six months of stalled work, and the honest answer to one question moved all of it.
- You're solving the wrong problem — The obvious problem is usually the one that's easiest to see, not the one that's costing you.
- Expanded: IST → SOLL · outline
- Expanded: Smartmatic — the missing capability · outline
Fix the system, not the symptom
Symptoms move. Systems don't.
If the same failure keeps returning with different people in it, the people were never the variable.
- Fix the cause, not the symptom — Treating the visible part is how you get to solve the same thing twice a year.
- Expanded: Systems thinking for non-engineers · idea
IST → SOLL
Describe what is, before designing what should be.
Half of all strategy work is fiction because nobody wrote down the current state honestly first.
- Expanded: IST → SOLL · outline
Product before pitch
A pitch cannot rescue a proposition.
When sales gets harder every quarter, look at what is being sold before you look at who is selling it.
- Expanded: Why most sales problems aren't sales problems · outline
- Expanded: Product-driven propositions · outline
If people don't understand it, they won't buy it
Comprehension is a commercial feature.
Engineers understood it. Buyers didn't. That gap is where most technical companies lose their revenue.
- The 5-year-old test — If you can't explain the proposition simply, you probably don't understand it yet.
- Expanded: Product-driven propositions · outline
- Expanded: What teaching taught me about selling · idea
- Expanded: “My phone can already do that.” · idea
Don't solve before you understand.
Don't automate chaos
Automation accelerates whatever already exists.
If the underlying process is broken, automation just produces broken outcomes faster — and makes them harder to see.
- Don't automate chaos — Automation follows process understanding. It does not replace it.
- Expanded: Fundamentals before AI · draft
Fundamentals before AI
Intelligence on top of noise is still noise.
Structure the information, define the process, then add the model. In that order, or not at all.
- Show me the workflow — Before software, automation or AI: show me how the work actually moves today.
- Expanded: Fundamentals before AI · draft
Show the problem. Protect the recipe.
Be generous with diagnosis, disciplined with method.
Naming someone's real problem builds more trust than any deck. How you solve it is the part you get paid for.
- Expanded: Copying the output isn't copying the thinking · outline
Commercial problems are often product problems
Sales is where the failure becomes visible, not where it starts.
Pricing, packaging, positioning and product decisions are the same conversation held in different rooms.
- Sales isn't a department — Product, positioning, pricing, service and delivery all show up in the sales number.
- Is this actually a sales problem? — Often it's product, positioning, pricing or process wearing a sales costume.
- Expanded: Why most sales problems aren't sales problems · outline
- Expanded: Why commercial people should understand product · idea
Simplicity is designed, not discovered
Nothing becomes simple by being left alone.
Simple products are the residue of a lot of deliberate removal. Complexity is the default state.
- This should NOT be software — Not every process deserves another SaaS. Some deserve deletion.
Ask one more why.
If it can be repeated, it can probably be productised
Repetition is a product waiting for a decision.
Any answer you have given three times is a candidate for a template, a workflow, a module or a price.
- If it repeats, productise it — The third time you do the same analysis by hand, you are prototyping a product.
- I think there's a product hiding in here — Same manual work, same shape, every month. That's a product with no name yet.
- Expanded: Recurring headaches are products waiting to happen · outline
Complexity needs structure before intelligence
You cannot analyse information that was never modelled.
Data layers, taxonomies and models are unglamorous work that decide whether anything clever is possible later.
- Expanded: Complexity is usually an information problem · idea
Sell the outcome, not the machinery
The customer buys the change, not the software.
Describe the state they end up in. The architecture is proof, not the pitch.
- You don't sell a product. You sell less risk. — In complex B2B, the buyer's real question is what happens if this goes wrong.
- What's actually being bought? — Nobody buys the software. They buy a different Monday morning.
- Expanded: The €30 template and the €300K problem · idea
Build what people use, not what looks impressive
Adoption is the only review that counts.
Impressive scope is easy to fund and hard to use. Usage is the honest metric underneath every roadmap.
- Before you build it… — Behaviour, problem, desired change. Features come fourth.
- Expanded: Prototype ≠ truth · draft
Ask what changed, not what was delivered
Delivery is activity. Change is result.
A finished project that changed nothing is an expensive way of staying the same.
- Expanded: IST → SOLL · outline
- Expanded: Belief versus evidence · idea
Don't confuse activity with progress.
Remove before you optimise
Optimising unnecessary work leaves unnecessary work.
The fastest improvement in most processes is a deletion. Efficiency work should start with the steps that shouldn't exist.
- Remove before you optimise — Optimising unnecessary work leaves you with faster unnecessary work.
Tips & tricks
Small moves that change outcomes more than most strategies do.
- Write the problem in one sentence — If it takes a paragraph, you don't have it yet.
- Interview three users before one workshop — Opinions in a room beat data only when there is no data.
- Price the outcome, not the hours — Hours cap your value at your calendar.
- Remove a step before adding a tool — Most tooling is paid-for process debt.
- Draw it before you discuss it — A diagram ends arguments a deck extends.
- Name the decision owner out loud — Unowned decisions become recurring meetings.
- Ship the ugly version internally — Feedback on something real beats agreement on something imagined.
Guidelines — houdvast
Shorter than principles. Reminders I give myself before I give advice.
Mental models & canvas
The thinking tools I actually draw on a whiteboard.
Write the current state honestly, then design the target state.
Push past the first plausible cause until data agrees.
Trace any commercial symptom back to a product decision.
The shape of almost every engagement.
Bespoke → template → module → product → price.
Plot what you deliver against what buyers understand.
Behaviour comes from structure, not intent.
Things I keep coming back to
Models, questions and people that keep turning up in the work.
Current state, honestly. Then target state.
Five whys, but with evidence.
Buyers have hierarchies too. Safety before status.
People rarely argue about the thing they're arguing about.
Behaviour comes from structure, not intent.
Turn the repeatable part into the thing you sell.
Adoption is a behavioural problem in a technical costume.
Most complexity is unmodelled information.
Where does one decision move the whole number?
The only honest project review question.
Asked once more than is comfortable.
Asked of anything done twice.
Bring me the messy version.
Principles are cheap. Applying them to your specific mess is the work.
Need hands-on training for your team — and results?
No slideware. Bring a real problem from your own business. We take it apart, find the root cause and fix it on the spot — with your team in the room, learning the method while it happens.
- Show me your problem — we work on yours, not a case study
- Half a day to two days, on site or remote
- Your team leaves with the structure, not just the answer