Question Base Assumptions

"Question base assumptions on everything. Sometimes we get into traps where we are as professionals, hyper focused on what we're building that day, that week, that month. And we don't stop to think should we even build this at all? Or what's the purpose of building this? Could we build something completely different that would matter more to our core reason for being?" - Dhanji R. Prasanna

What It Is

Question Base Assumptions is the practice of stepping back from immediate execution to challenge whether the underlying premise is correct. Before optimizing, automating, or building, ask: "Should we even be doing this at all?"

Dhanji describes this as somewhat clichéd advice that needs to be applied "over and over and over again" because professionals get trapped in tactical execution. This framework is particularly relevant when teams are debating solutions—often the right answer is that neither solution is needed.

How It Works

The trap:

Teams get focused on immediate work:

• "We need to buy this vendor tool because our current tool isn't doing X, Y, Z"
• "We can use Goose to build an app that does the same thing in half the time"
• Everyone debates which approach is better

The question that changes everything:

"As a human, you're sitting there thinking, 'Is any of this necessary? If we just change the process, do we even need to think about building tools?'"

Where this applies:

Dhanji gives an InfoSec example:

• Security teams twist themselves into knots trying to secure something
• The better question: "Just ask the team that's building it to do it differently, or to not build that at all if it doesn't matter"
• Don't increase your security surface area if you can eliminate the thing being secured

Why it's hard to do:

1. Professionals are action-oriented - We're paid to build and solve, not to question
2. Sunk cost - We've already invested in the current approach
3. Competence bias - "I know how to solve this" vs. "Should this be solved?"
4. Organizational momentum - Projects have stakeholders who want them to continue

How to Apply It

1. Schedule regular "why" reviews:

   • Before starting any major effort, explicitly ask: "Should we do this at all?"
   • Before optimizing a process, ask: "Should this process exist?"

2. Use the tool debate as a signal:

   • When teams debate tool A vs. tool B, pause
   • Ask: "What if we did neither?"
   • Often the real answer is process change, not tool change

3. Apply the InfoSec test:

   • What are we protecting/building/optimizing?
   • Could we eliminate the thing itself?
   • Is the underlying activity even necessary?

4. Connect back to core purpose:

   • At Block: "Economic empowerment"
   • Does this directly serve that purpose?
   • Or are we optimizing something peripheral?

5. Create space for challenges:

   • Make it safe to ask "why are we doing this?"
   • Reward people who save effort by eliminating work
   • Don't let momentum override judgment

Common Situations to Apply

• Build vs. buy debates - Should we build this, buy this, or do neither?
• Security review - Can we eliminate what we're trying to secure?
• Process optimization - Can we eliminate the process instead?
• Feature prioritization - Does this feature matter at all?
• Technical debt - Is the system this debt lives in even necessary?

The Elon Connection

Dhanji references Elon Musk's similar philosophy:

"Elon has this whole process for optimize stuff and one of the steps is like, 'Do we even need this thing before we start optimizing and automating it?'"

Source

• Guest: Dhanji R. Prasanna
• Episode: "How Block is becoming the most AI-native enterprise in the world"
• Key Discussion: (01:12:21) - Question base assumptions as core lesson
• YouTube: Watch on YouTube

Related Frameworks

• Problem-First Approach - Start with the problem, not the solution
• Business vs. Customer Problems - Distinguish what matters from internal concerns
• Tools Solve Problems - Tools exist to solve problems, not the reverse