Learn 97% of How to Get Rich in 11 Mins | Ep 1009

The podcast discusses a set of powerful questions designed to improve decision-making in business. Central to the discussion are three key questions: "What problem are you trying to solve?" to uncover the root cause behind requests; "What would it take?" to shift conversations from limitations to possibilities by assuming success; and "What do you want to have happen?" to clarify desired outcomes and ensure alignment with actions. These questions are presented as tools to combat intellectual laziness, avoid premature rejections, and move beyond emotional justifications toward clear, goal-oriented thinking.

Further explored is the importance of evaluating proposed changes - such as switching from remote to in-person meetings - by assessing their intended outcomes, measurable impact, and underlying motivations. The discussion emphasizes the need to define vague concepts like "engagement" or "happiness," validate assumptions with evidence, and consider whether changes will produce meaningful business results. The podcast advocates for a mindset of strategic inaction - sometimes doing nothing is best when existing approaches work and new ideas stem from discomfort rather than data. It also promotes reverse engineering success, prioritizing high-return actions, and fostering a performance-driven culture over superficial morale-boosting initiatives.

• What if you challenged every feature request with "What problem are you trying to solve?"

  • Move: For the next 30 days, implement a rule: before writing any code or building any feature, ask the requester (or yourself) in writing: "What specific problem are you trying to solve?" and document the answer.
  • Why Now?: Feature creep and unfunded mandates from clients, users, or your own assumptions are silently killing your productivity and product focus. Most "urgent" requests dissolve when the root problem isn't actually yours to solve.
  • Expected Upside: You'll eliminate at least 30 - 50% of low-impact work, reclaim 5 - 10 hours/week, and redirect effort toward high-leverage improvements that move revenue or retention metrics.

• What if you used "What would it take?" to unlock faster product iterations?

  • Move: Pick your next planned feature or update (e.g., launching a new API endpoint), and ask: "What would it take to ship this in 48 hours instead of 2 weeks?" Then strip everything non-essential to meet that goal.
  • Why Now?: Solo developers often over-engineer solutions based on hypothetical scale or edge cases. Speed beats perfection in early validation. The market rewards shipped work, not ideal architecture.
  • Expected Upside: You'll reduce time-to-value per feature by 50 - 70%, gather real user feedback faster, and create a bias toward action - turning your development cycle into a rapid learning engine.

• What if you paused every "big idea" and asked "What do you want to have happen?"

  • Move: Before starting any new project, integration, or marketing push, write down: "After this is done, what measurable outcome do I want to see in 30 days?" (e.g., "5 new paying users," "30% drop in support queries"). If you can't define it, delay the project.
  • Why Now?: Solo operators are prone to chasing shiny tools or trends (e.g., AI, new frameworks) without tying them to business outcomes. This wastes time and fragments focus.
  • Expected Upside: You'll avoid at least 2 - 3 distractions per quarter, maintain alignment between effort and growth, and build a track record of delivering tangible results - not just activity.

• Ask "What problem are you trying to solve?" before accepting any request, to filter out noise and focus only on work that addresses real business needs.
• When pursuing a goal, ask "What would it take?" to shift conversations from limitations to actionable requirements and uncover concrete steps for achievement.
• Clarify ambiguous objectives by asking "What do you want to have happen?" to define measurable outcomes and align efforts with actual business impact.
• Before changing an existing process, evaluate whether "doing nothing" is the better option by assessing if the current system works and if proposed changes are driven by emotion rather than data.
• Reverse engineer success by asking "What would it take for this to succeed?" to identify high-leverage actions and prioritize efforts that directly contribute to desired results.