Asking "What's wrong with this idea?" forces teams to find flaws early rather than seeking approval. It invites challenge, signals psychological safety, and surfaces problems before they hit production.
Engineering teams naturally gravitate toward agreement and positivity, especially when power dynamics are in play. Add in the fact that less-experienced engineers often won't think to challenge an idea unless explicitly invited, and you end up shipping products with obvious flaws that nobody voiced. The question "What's wrong with this idea?" cuts through this by signaling that you care more about getting the right answer than being right.
The approach works because it makes vulnerability safe. When you ask this about your own ideas - not others' - you're modeling that challenge is welcome. You're saying the team should find problems now, during planning, rather than learning about them from customers or competitors when the product is failing in production. It's the difference between a prosecutor who says "open-and-shut case" and one who asks "how am I going to lose this case?" - the second team systematically attacks their own weak points before the opposition does.
The mental model of inverted thinking applies directly here. Walk through the full implementation and ask: "We built this and it failed. What happened?" Maybe you missed a use case, didn't know what the customer wanted, failed to deliver what they wanted, took too long, or the customer churned. These are concrete failure modes you can address in design rather than discover in production. Looking both ways when crossing a one-way street isn't paranoia - programmers know that cars do go the wrong way, and people get hit.
Check out the full stdlib collection for more frameworks, templates, and guides to accelerate your technical leadership journey.