Why I Built a Tool to Argue With Myself Every Morning
Every morning I confront my riskiest assumptions before checking email. When spreadsheets failed, I built Assumption Mapper.

I have a habit that most people would find uncomfortable. Every morning, before I check email or open Slack, I look at a list of things I might be completely wrong about.
Not in a journaling, self-help way. In a "these are the beliefs my current venture is built on, and here's how little evidence I have for each one" way.
I started doing this with a spreadsheet. Then a Notion board. Both worked for about a week before I stopped opening them. The spreadsheet had no opinion โ it didn't care whether I looked at it. The Notion board got buried under other pages. Neither one pushed back.
So I built something that does.
The Spreadsheet Graveyard
Let me tell you how this usually goes. You read "The Mom Test" or attend a lean startup workshop. You're fired up. You create a spreadsheet with columns: Assumption, Importance, Status, Evidence. You fill in fifteen rows. You feel rigorous.
Two weeks later, the spreadsheet hasn't been updated. Not because you stopped having assumptions โ because the spreadsheet doesn't care. It sits there, static, while you drift back into building mode. Shipping features feels productive. Updating a spreadsheet feels like homework.
The insight that changed things for me: the problem isn't discipline. It's that the tool doesn't have an opinion. It doesn't surface what matters. It doesn't confront you with what you're avoiding. It just stores data.
What Daily Confrontation Looks Like
Here's my actual morning routine now. I open Assumption Mapper and see five items. Not a wall of thirty assumptions in a spreadsheet. Five. Specifically, the five riskiest untested beliefs in my current venture, ranked by how important they are and how little evidence I've gathered.
Today it might show:
- "Enterprise buyers will self-serve without a sales call" โ importance: 5, evidence: 1 data point
- "Content marketing will be our primary acquisition channel" โ importance: 4, evidence: 0 data points
- "Users will return weekly after onboarding" โ importance: 5, evidence: 2 data points
These aren't tasks. They're not bugs to fix or features to build. They're the load-bearing beliefs my venture stands on. And the tool is telling me, every single morning: "You have almost no evidence for #2. It's been sitting here for 11 days. What are you going to do about it?"
That's the moment where the useful discomfort happens. I can't pretend I'm making progress by shipping features if my core acquisition assumption has zero evidence behind it.
Building the Tool I Needed
I built Assumption Mapper over several weeks, driven by a simple thesis: the right tool should make assumption-driven development the path of least resistance, not an act of discipline.
That meant a few specific design decisions:
Capture has to be instant. If writing down an assumption takes more than five seconds, I won't do it in the middle of a conversation or after reading an article. So it's Cmd+K, type the belief, hit Enter. Done. No categories, no importance ratings, no friction. That comes later.
The Focus View has to be confrontational. Not a dashboard with charts. Not a backlog. Five items, ranked by risk. "Here's what could kill your venture. Deal with it."
Evidence has to be linked. When I log something I learned โ from an interview, a test, a data pull โ it connects to the assumption it informs. Over time, this builds a record. Not just "we validated X" but "here are the six data points that led to that conclusion, and here's the rationale."
Decisions have to be explicit. At some point, you have to call it. Validated, invalidated, or need more. Not "we feel good about this." A deliberate decision, with a written rationale, logged permanently.
What Changed
The biggest shift wasn't finding invalidated assumptions โ though that happened. It was the speed of learning. When your riskiest beliefs are staring at you every morning, you naturally prioritize testing them. You structure your week around evidence gathering instead of feature shipping.
I also noticed I started capturing assumptions I would have previously left implicit. Small ones. "Users will understand what 'triage' means without explanation." "Our onboarding flow works without a tutorial." Writing them down didn't take effort because the capture was frictionless. And some of those small assumptions turned out to be the ones that mattered most.
The decision log became unexpectedly valuable too. Looking back at a month of decisions โ what we validated, what we killed, what we pivoted on โ gave me a clearer picture of progress than any sprint retrospective ever did. Evidence in, decisions out.
The Uncomfortable Part
I'll be honest: some mornings I don't want to look at the Focus View. When your top assumption has been sitting untested for three weeks and you know the reason is that you've been avoiding a difficult conversation with a potential customer โ the tool makes that avoidance visible.
That's the point. The tool doesn't let you hide from what you don't know. It doesn't let you confuse motion with progress. It just asks, quietly and persistently: what's your evidence?
The Bottom Line
I built Assumption Mapper because I couldn't find a tool that made me confront my own beliefs with the same rigor I bring to building products. Spreadsheets store assumptions. This surfaces them. That difference โ between storage and confrontation โ is the entire product.
If you're building something new and want a tool that argues with you every morning, give it a try. It's free.
Want to discuss this further?
I'm always happy to chat about building products and validation.
Get in touch