Assumptions doing too much work
What needs to be true for the project to succeed — and how much of it has actually been proven?
I haven't spent the past six months building it, defending it, or learning to live with its compromises. That distance is exactly what allows me to see it clearly.
I won't tell you what you want to hear.
I'll tell you what still needs to be proven.
Projects rarely fail because nobody cared. They fail because smart people were busy making them work.
One assumption becomes a fact. One workaround becomes infrastructure. One optimistic forecast becomes payroll. One temporary dependency quietly becomes permanent.*
By the time everyone agrees there is a problem, the project has already spent a lot of money proving it.
I look for the first link in that chain.
I've spent more than 20 years building and running digital products — from early launches to platforms serving 20 million users a month.
The business model, product, research, technology, operations, and distribution are not separate when any one of them can break the others.
What needs to be true for the project to succeed — and how much of it has actually been proven?
Where does the money come from? What happens when the optimistic numbers become normal numbers?
Which decisions are supported by research, data, or observable behaviour — and which are supported by confidence?
Architecture, integrations, data flows, team capabilities, external dependencies, and single points of failure.
Acquisition, retention, platform dependency, content supply, monetisation, and the dangerous belief that a good product will somehow distribute itself.
Every project has them. Usually for a reason. Rarely a good one.
Every audit ends with a written, prioritised assessment of the risks, assumptions, missing evidence, and dependencies that matter most. Depending on the scope, I may also include an assumption map, supporting research, and a review session with your team.
I don't make the decisions for you.
I make it harder to make them blindly.
If the conclusion is already fixed, there is no reason to involve me.
No questionnaire. No essay about your mission. Just send a deck that explains the project well enough for me to understand what you are building and why.
make sure the link opens without an access request, or attach a PDF under 10 MB. consider this the first technical test.
I review the deck and reply within two business days. If I think I can be useful, I'll get in touch with the next steps. If I'm not the right fit, I'll say so. We've both saved ourselves a call.
Before you share confidential research, financials, architecture, data, or internal documents, we sign a mutual NDA electronically.
After reviewing the necessary materials, I propose the scope, timing, and fee. You approve the scope, pay through a secure link, and receive access to my calendar.
calls happen after context, scope, and payment — not before.
I examine the assumptions, evidence, dependencies, business logic, and vulnerable parts of the system. Where necessary, I look for additional research or independent confirmation of critical assumptions. When context matters, I may ask to speak with the person who made an assumption. I want to understand the reasoning behind it, not just the number it eventually became. Then we review the findings together.
assumptions become surprisingly confident once they enter a spreadsheet.
The audit is a complete engagement on its own. If the project still has a pulse, the work is useful, and we both want to continue, we can discuss ongoing involvement.
I've spent more than 20 years launching and running digital products.
More than 50 projects across media, research, analytics, adtech, and AI. Some reached 20 million users a month. One was a national video platform competing with global players. Across that work, I've been responsible for more than $100 million in budgets.
The numbers are useful context. The mistakes were more educational.
I've seen smart teams make bad decisions for perfectly reasonable reasons. I've seen assumptions turn into code, infrastructure, contracts, and payroll before anyone checked whether they were true.
If your project is solid, it will survive the questions. If it isn't, you'll want to know now.
if you need the titles, dates, and respectable version of my career, linkedin has it.
no confidential information at this stage.
if i want to go deeper, we sign an NDA first.