Why smart people fall for scams and projects fail. The 1 uncomfortable question nobody asks!!!
Why smart people fall for scams? Use the Uncomfortable Question Protocol to safely challenge assumptions that everyone else is ignoring.
Last Tuesday, I opened my email and found this message:
“I am Zainab Zaid, 24 year old… I had always known a life of comfort. Born into one of Gaza’s few affluent families…”
The email went on for twelve paragraphs. A tragic story. Dead family members. A hidden safe with 3.4 million dollars. She needed help investing the money abroad.
And she was willing to give me 30 percent just for helping.
Do the math. That’s over one million dollars.
My finger hovered over the reply button for exactly zero seconds.
Obviously a scam, right?
But here’s what keeps me awake at night. Thousands of people fall for emails exactly like this every single year. Smart people. Educated people. People who manage complex projects for a living.
The FBI reports that advance fee fraud costs Americans over 50 million dollars annually. That’s just the reported cases. Most victims are too embarrassed to come forward.
These aren’t stupid people. They’re people who stopped asking one critical question.
The same question that could have prevented the Boeing 737 MAX disasters. The same question that could have saved Healthcare.gov’s 2 billion dollar failure. The same question that’s probably missing from your next project meeting.
Let me show you the question. And why nobody asks it.
Why Smart People Fall for Obvious Scams
The email from “Zainab” is a masterpiece of psychological manipulation.
It has specific details. The Rimal neighborhood in Gaza. A father named Mahmoud who ran a textile business. A brother named Khaled who wanted to be an architect.
It has emotional weight. War. Death. A young woman alone and scared.
It has urgency. “I haven’t told anyone. I don’t know what could happen next.”
It has legitimacy markers. Offshore assets in Cyprus and Turkey. Steel safes. Property documents.
Your brain processes all this information and thinks “this sounds real.”
One of my course students almost learned this lesson the expensive way. A new client approached his consulting firm offering a 400,000 dollar contract. Double the market rate. Fifty percent upfront payment.
Every red flag was there. But the client had a compelling story. Tight deadline. Exclusive opportunity. Detailed requirements document.
My student’s team was ready to sign. Then, in the final meeting, he asked the uncomfortable question: “Why are you willing to pay us double the market rate and give us fifty percent upfront?”
The client went silent. Then said they’d “need to discuss internally and get back to him.”
They never called back. My student did some research. Turned out to be a suspected money laundering operation. The “project” was fake. They were looking for legitimate businesses to funnel dirty money through.
That one question saved his firm from potential criminal exposure and a 400,000 dollar disaster.
The same thing happens in project meetings.
A confident executive presents a strategy. Specific market data. Emotional conviction. Urgency about competition. Legitimacy through fancy slides and consultant reports.
Your brain processes it and thinks “this sounds solid.”
In both cases, you’re making the same mistake. You’re evaluating whether the story sounds convincing instead of whether the story makes sense.
That’s the difference between a question that protects you and a question that destroys you.
The Question Nobody Asks
Here’s the question that would have immediately revealed the scam:
“Why would this be offered to me?”
Not “does this sound real?” Not “could this be true?” But specifically: “Why me?”
If Zainab really had 3.4 million dollars and needed help investing it, why email a random stranger? Why not contact a legitimate bank? An investment firm? A lawyer?
Why offer 30 percent when any professional would do this for 1 percent?
The answer is obvious once you ask the question. But most people never ask it.
They ask easier questions instead. “Does the story sound convincing?” Yes. “Are the details specific enough?” Yes. “Do I want to believe this could be real?” Absolutely yes.
The uncomfortable question, the one that feels almost rude to ask, is the one that saves you.
I see the exact same pattern destroy projects.
The Boeing Question Nobody Asked
March 10, 2019. Ethiopian Airlines Flight 302 crashed six minutes after takeoff. All 157 people on board died.
Five months earlier, Lion Air Flight 610 had crashed under identical circumstances. 189 people dead.
Both planes were Boeing 737 MAX aircraft. Both crashes were caused by a single sensor failure.
The sensor told the plane’s computer that the nose was too high. The computer automatically pushed the nose down. The pilots fought the system. The plane crashed.
Boeing had designed the system to rely on one sensor. They had a second sensor on the plane, but the software only checked one.
After the crashes, investigators found that Boeing engineers had raised concerns. They had identified the single sensor as a risk. They had documented it.
But nobody asked the uncomfortable question: “What happens if this one sensor fails?”
Not “is the sensor reliable?” Not “what’s the probability of failure?” But specifically: “What if it fails?”
That question would have revealed the obvious answer. If the one sensor fails, the plane nose dives into the ground.
The fix would have been simple. Check both sensors. If they disagree, alert the pilot and disengage the system.
But nobody asked the question because it felt confrontational. It challenged the design that senior people had already approved. It suggested that smart engineers might have made a fundamental mistake.
So the question stayed unasked. And 346 people died.
The total cost to Boeing? Over 20 billion dollars in fines, compensation, lost sales, and grounded aircraft.
All because nobody asked one uncomfortable question.
The Pattern Across Every Disaster
Look at any major project failure and you’ll find the same pattern.
Theranos: A 9 billion dollar company that claimed to revolutionize blood testing. Turned out the technology didn’t work. At all.
The question nobody asked: “Can I see the machine actually run a real test?”
Investors asked other questions. “Do you have famous board members?” Yes. “Are you confident this works?” Absolutely. “Can I see the test results?” Here’s a binder full of data.
The simple, direct question, “Show me the machine working,” was too confrontational. Too distrustful. Too unsophisticated.
So nobody asked. And 9 billion dollars in value vanished when the truth came out.
The same pattern destroyed Target’s Canada expansion (7 billion dollar loss), Healthcare.gov (2 billion dollar failure), and dozens of other “well-managed” projects.
Every single one of these disasters had the same thing in common. Smart people. Comprehensive planning. Risk management processes.
And one question that felt too uncomfortable to ask.
How to Ask the Uncomfortable Question
Here’s what I’ve learned after watching projects fail and helping teams recover.
The questions that save projects are usually the ones that feel awkward to ask out loud.
They feel like you’re questioning someone’s competence. Or admitting you don’t understand something obvious. Or being difficult when everyone else seems aligned.
That discomfort is your signal. If a question feels uncomfortable to ask, it’s probably the most important question in the room.
I use a simple framework now. I call it the Uncomfortable Question Protocol.
THE UNCOMFORTABLE QUESTION PROTOCOL
STEP 1: Identify the Confident Claim
Listen for absolute certainty:
“This will definitely work”
“The data clearly shows”
“We’re confident that”
STEP 2: Find the Unverified Assumption
What has to be true for this to work?
What hasn’t been tested?
What are we assuming vs. knowing?
STEP 3: Ask the Childlike Question
Not sophisticated. Simple:
“Why would they email me?”
“What if the sensor breaks?”
“Can I see it work?”
STEP 4: Ask It Out Loud
Frame as curiosity, not criticism:
“This might be basic, but what happens if [assumption] turns out to be wrong?”
STEP 5: Insist on a Real Answer
Push gently but persistently:
“Can you walk me through how we verified that?”
“What did we test?”
“What evidence do we have?”
Want a high-resolution version of this framework you can print and put on your wall? Download the free graphic at whatisscrum.org – share it with your team, steal it for your presentations, make it yours.
Let me show you what this looks like in practice.
Why This Is So Hard in Most Organizations
Here’s the brutal truth. Most organizations punish people who ask uncomfortable questions.
Not officially. Nobody writes “fired for asking good questions” on a termination notice.
But the social punishment is real. Eye rolls. Sighs. Being labeled as “not a team player” or “always negative” or “slowing things down.”
I once watched a senior VP fire a junior engineer for asking “But what if the database goes down during Black Friday?” in a planning meeting. The VP called him “a negative influence undermining team confidence.”
Six months later, Black Friday arrived. The database crashed. The site was down for four hours. They lost 14 million dollars in sales.
The VP got promoted three months after that. He spun it as “managing through adversity.” The engineer who asked the question? He was a single dad with two kids. He was gone before the disaster even happened.
The VP just bought a vacation home in Aspen.
I’ve seen this pattern dozens of times. Engineers staying quiet about technical impossibilities because questioning the timeline felt career limiting.
Project managers avoiding budget realism questions because executives had already committed to the numbers publicly.
Entire teams ignoring obvious problems because the person who raised concerns last time got reassigned to a less prestigious project.
This is why the scam email works. And why projects fail.
The organizational pressure to go along, to not rock the boat, to trust the experts, is immense.
It takes actual courage to ask the uncomfortable question. Especially when everyone else seems comfortable.
The Dirty Secret Traditional Project Managers Don’t Want You to Know
Most people think Scrum is about standups and story points. Burndown charts and velocity metrics.
That’s not what Scrum is.
Scrum is the best risk detection system ever invented. And traditional project managers hate it because it exposes the comfortable lies they’ve been living with for decades.
Here’s what I mean.
Sprint Reviews aren’t about showing progress. They’re about forcing the Theranos question.
You can’t just claim the feature works. You have to demonstrate it. To real stakeholders. Every two weeks.
“Show me the machine working” isn’t optional. It’s mandatory every sprint.
Traditional project management lets you report “90% complete” for six months. Scrum makes you prove “working software” every fourteen days.
Retrospectives aren’t about team building. They’re about forcing the Boeing question.
Every sprint ends with the team asking “what went wrong and what almost went wrong?”
“What if this fails?” gets asked while you can still fix it. Not after 346 people are dead.
Traditional project management has “lessons learned” sessions after the disaster. Scrum has them before the disaster, when the lessons can actually save you.
Definition of Done isn’t about quality standards. It’s about forcing the Target question.
Teams have to define what “done” actually means before they start. Not argue about it during final acceptance testing.
“Should we test with real data first?” is baked into the definition of done.
Traditional project management lets you debate what “finished” means during the crisis. Scrum forces you to agree on it during planning.
Daily standups aren’t status meetings. They’re about forcing the Healthcare.gov question.
When you say out loud what you’re working on every single day, the gaps become obvious immediately.
“Who’s integrating all these pieces?” can’t hide for months.
Traditional project management discovers integration problems during system testing at the end. Scrum discovers them in week two.
But here’s the critical part that makes or breaks everything.
If people are scared to say “this isn’t working” in a retrospective, you’re just going through motions.
If teams are punished for demonstrating incomplete features in sprint reviews, they’ll start faking demos.
The ceremonies create the opportunities for uncomfortable questions. Leadership has to create the safety to actually ask them.
The Uncomfortable Questions Hall of Fame
Before I wrap this up, I want to show you what happens when people actually use this protocol. Here are three real uncomfortable questions that saved projects:
The question that saved a $1.2M software launch:
“What happens if the API rate limit is actually lower than the documentation says?”
Nobody had tested it. They called the vendor. Turned out the docs were wrong. The real limit was 40% of what they’d designed for. They caught it three weeks before launch instead of three hours after.
The question that killed a bad acquisition:
“If your business is growing this fast, why are you selling at this valuation?”
The founder got defensive. Started talking about “lifestyle choices” and “pursuing other opportunities.” Due diligence revealed the growth numbers were inflated. Deal killed. Company went bankrupt six months later.
The question that exposed fraud:
“Can we call three of your reference customers right now? Just pick any three.”
The vendor said they’d “need to coordinate schedules.” Never provided the references. Background check revealed two of the “customers” on their website were stock photos. Contract canceled before any money changed hands.
One uncomfortable question. Minutes to ask. Millions in potential savings.
What This Means for Your Next Project
Think about your current project right now.
What’s the confident claim everyone is operating on? What assumption is treated as fact?
Now ask yourself: Have we actually verified this? Or are we just confident because everyone else seems confident?
That’s your uncomfortable question. The one that feels awkward to raise.
That’s also probably the question that will save your project.
Or reveal that you need to change direction now before the disaster hits.
I didn’t reply to Zainab’s email because I asked the uncomfortable question. “Why would this be offered to me?”
The answer made no sense. So I deleted it.
Boeing didn’t ask theirs. 346 people died and the company lost 20 billion dollars.
Target didn’t ask theirs. 7 billion dollars and a complete market exit.
Theranos didn’t ask theirs. Criminal fraud charges and complete company collapse.
Your project probably has an uncomfortable question too. The one everyone is avoiding.
The question is: Will you ask it before the disaster? Or after?
Here’s your challenge: Reply in the comments or email me directly with your project’s #1 untested confident claim. I’ll reply to every single one publicly with the uncomfortable question you’re avoiding.
The best ones become anonymized case studies in my next post (with your permission, of course). This creates accountability, builds community, and helps everyone learn from real situations.
The first twenty people who share get priority responses. Because the difference between asking the question in sprint three versus discovering the disaster in month fifteen could save your project.
Don’t wait until you’re explaining the disaster to executives. Ask the uncomfortable question today.
The System That Makes Hard Questions Safe
I’ve spent fifteen years teaching teams how to ask uncomfortable questions without getting fired for it.
The secret isn’t courage. It’s system design.
When you build the uncomfortable questions into your process, they stop being uncomfortable. They become normal. Expected. Safe.
Sprint reviews ask “does this actually work?” every two weeks. It’s not confrontational. It’s Tuesday.
Retrospectives ask “what’s broken?” every sprint. It’s not negative. It’s continuous improvement.
Definition of Done asks “are we really finished?” before you start. It’s not distrust. It’s clarity.
The ceremonies create permission. The rhythm creates safety. The evidence creates truth.
That’s how Scrum teams catch the risks that destroy traditional projects. Not because they’re smarter. Because the system forces the uncomfortable questions before they become disasters.
I teach teams how to use these ceremonies as risk detection mechanisms. How to create psychological safety for truth telling. How to ask the questions that feel dangerous without becoming the person who “always finds problems.”
Because the reality is simple. Every project has uncomfortable questions. The winning teams ask them in sprint three. The losing teams avoid them until month fifteen.
When the scam email landed in my inbox, I asked the uncomfortable question immediately. It took five seconds. It saved me from losing money and dignity.
When your risky assumption is sitting in your planning documents, you have the same choice. Ask the uncomfortable question now. Or explain the disaster later.
Which will it be?
Want to build a team culture where uncomfortable questions are welcomed, not punished? In my Risk Management in Scrum course, you’ll learn exactly how to use sprint ceremonies to surface dangerous assumptions before they destroy your project. I’ll show you how to facilitate retrospectives that reveal hidden risks, run sprint reviews that expose integration problems, and create Definition of Done standards that catch quality issues early. The difference between asking uncomfortable questions in sprint three versus discovering disasters in month fifteen isn’t courage. It’s system design. Boeing, Target, Theranos, Healthcare.gov – they all had smart people who saw the problems but couldn’t voice them safely. Learn how to build the system that makes truth-telling safe.
P.S. If you received a similar email from “Zainab” or anyone else promising millions for minimal effort, don’t reply. Report it to the FBI’s Internet Crime Complaint Center at ic3.gov. And remember: If it sounds too good to be true, that’s because someone is betting you won’t ask the uncomfortable question. Don’t prove them right.
