The surprising power of negative questions

Moving from "I don't see why not" to "why not?"

Come to the dark side—we make better product decisions. In my experience, most businesses really struggle with groupthink fallacies. If disagreement is healthy, it’s also dangerous to the ego. Sharp questioning is a blade that respects no title. Teams tend to settle into a more comfortable rhythm that requires fewer hard questions, more deference to authority (or the loudest person in the room) and less examination of the reasons why not to build.

When was the last time you saw a product one pager template with an intentional question challenging the PM to think about why a product idea shouldn’t be built? When was the last time you sat in a conversation with leadership where your leader asked for more disagreement? If we want to avoid feature factories in product, it seems to me that we need to stop biasing toward the assumption that the next feature will offer proof positive of whatever business thesis we’re working on at the moment.

It might not. In fact, it probably won’t. I have been the PM building large features that took months that were designed expressly at the request of large key customers. After launch, those same customers immediately ignored the new fancy new feature. Product is hard. It’s hard even when all the signs say build it.

So in an environment where it’s hard to get anything done, where teamwork can be challenging, where leadership can often give conflicting feedback, why bias toward a question that slows the team down? If you know me from Tiktok or even these few pieces on Substack, you’ll have gathered I generally value bias for action. I think velocity optimizes the probability that a given company will escape the death spiral of missing product market fit. Velocity will enable you to keep up with scale if you’re growing fast. Velocity enables you to beat disruptors if you’re at scale already.

So why ask any question at all in that context that might slow things down? Why ask why not and mean it? The short answer is that even smart gamblers in the casino think about which chip to push to the center of the green baize table. Call or raise. How much. If we think of product as a casino, asking why not enables PM’s to avoid the trap of over-focusing on the current thing as the only thing. It forces us to think of this particular project as just another bet. Maybe a good one. Maybe not. And the only way to know if it’s the right bet to build right now is to invite the negative question in early, before green lighting the build.

After all, isn’t that easier than the unpleasant “Why didn’t you think of X” conversations so many of us have sat in on? Product retros and learning sessions are valuable. They let you think in a focused way about what you learned from the bet you put on the table. And it’s hard to think about what you learned if you are wondering if you should have thought a bit harder about pushing that chip into the center of the blackjack table in the first place.

So part of the power of asking hard questions up front is regret avoidance. The other piece of value, in my experience, is learning to train your gut as a product builder. By asking yourself to genuinely argue against your product, and by setting high standards for what counts as a negative rationale, you drive your brain to think more deliberately and less irrationally about your choices. Gradually, as you see what plays out, your gut starts to get smarter.

And here’s where most PM’s miss out: on the rare occasion they ask themselves the question, they give themselves an easy pass out of product thinking jail by invoking opportunity cost and moving on. We have to build this because [insert external thing here] will happen if we don’t. It’s more unusual to see a product manager engage thoughtfully with a negative question and build a coherent, internal rationale that takes the option not to build seriously on its face and focuses on building a solid rationale that holds up without invoking the business equivalent of clickbait.

This might all seem like chopping straws to you, so let me give you an example from the Cold War: during those days the joke around the Pentagon went (and this is such an old joke it’s lost its provenance) that in any given crisis you gave the President exactly three options: your preferred option, total capitulation to the Soviets, or all out nuclear war. Amazingly, most Presidents took DOD’s preferred option given that choice set, and of course that was the point. This is not a Cold War newsletter, so we will leave further reflection on this topic for when we meet over a whiskey by the fire on a snowy night.

Here’s what I’m getting at: we often do the same thing as the Department of Defense in product. Too often we present false alternatives and straw men when asked to question our own rationale. We are so focused on getting the thing built we don’t ask if we would be better off saying no.

So how can you make this actionable? If you want to get more rigor in you thinking, what can you do? I want to invite you to ask this question: What’s the best reason not to build this? It can go in your one pagers if you have room. If you are not in a position to change a one pager template, it can go in your own notebook. But either way, take it seriously. Build the best answer you can, and then look back at your answer when you do a retro after launch. See what you see. Learn patterns. Train your gut.

Good luck,

Nate

PS. Here are a few reflections on how asking yourself tough questions actually increases both product velocity and quality long-term.