Ask what breaks if we ship nothing

Someone tells you a thing is urgent. A stakeholder wants the dashboard to have a date-range filter, they want it this sprint, and there is a Slack thread with fourteen messages in it and two people from Sales.

The normal developer response is to estimate it. The product-minded response is to ask one question first:

What happens if we don’t build this at all?

Not as a challenge. As an actual question, asked with genuine curiosity, because the answer is the most useful thing anyone will tell you all week.

You will get one of four answers, and each one tells you exactly what to do next.

“Nothing, really.” You have just saved a sprint. This happens more than anyone likes to admit. A request gets made, it acquires momentum through repetition, and nobody ever re-checks whether the original need still exists. Somebody asked for the filter in March. It is now August. The report they needed it for was a one-off.

“Sales can’t close the Henderson deal.” Now you know the real deadline and the real stakeholder, and you can ask the far more useful follow-up: what does Henderson actually need to see? Nine times out of ten it is narrower than the general-purpose thing you were about to build. They need last quarter versus this quarter. That is two buttons, not a date picker.

“We’d keep doing it by hand, like now.” Excellent. There is a current workaround, which means there is a working spec sitting in someone’s Downloads folder. Go look at it. It will tell you more in five minutes than the ticket did in fourteen messages.

“I don’t know.” This is the most valuable answer and the one people are most embarrassed to give. It means nobody has thought about it, which means you are about to spend two weeks of your life on something nobody has thought about. Say “let’s find out” and go find out.

Why this works when “why?” doesn’t

You have probably tried asking “why do we need this?” and had it land badly. It reads as resistance. It puts the other person in the position of defending a decision, and people defend decisions by getting more attached to them, not less.

“What breaks if we don’t?” is a different question wearing similar clothes. It is about consequences in the world, not about the merit of their idea. It invites them to think alongside you rather than argue with you. And it has a natural, unforced answer, because everyone knows what would go wrong in their own job.

It also does something quietly useful. It converts a feature request into an outcome statement. “We need a date filter” becomes “Sales can’t segment by quarter and it’s costing us deals.” The second version is something you can solve five different ways, three of which are cheaper than the one you were handed.

What it looks like

Before. The ticket as written:

Title: Add date range filter to reports dashboard
Priority: High
Description: Users need to be able to filter the reports
dashboard by a custom date range. Add a date picker with
start and end dates.

Everything about this is a solution. There is no problem in it anywhere.

After. The same ticket, following one question asked once in a two-minute conversation:

Title: Sales can't compare quarter-over-quarter in reports
Priority: High. Blocks Henderson renewal, decision by 12 Sep

Problem: Sales pulls the reports dashboard into renewal calls.
They need to show a customer "here's this quarter vs last
quarter." Today they screenshot the dashboard twice a week
and paste both into a slide.

If we ship nothing: they keep screenshotting. Slow, error
prone, and it looks unprofessional on a renewal call. Three
reps do this, about 20 min each per week.

Smallest thing that would work: a "vs previous period"
toggle. Not a general date picker.

Open question: does anyone need arbitrary ranges, or is
"this period vs last" enough? Ask Dana.

That second version took one question. It is a smaller build, it has a real deadline attached to a real reason, it names the person who can settle the remaining unknown, and if you shipped only the toggle you would solve the actual problem in about a day.

Notice what else happened. You are now the person who found the Henderson deadline. Nobody had written it down.

The objection

“This isn’t my job. The PM should have done this.”

Maybe. They probably should have. But two things are true at once: it is not your job, and it is the highest-value thing you can do in the next two minutes. The gap between “add a date picker” and “Sales loses deals because they can’t compare periods” is where all of your leverage lives. If you wait for someone else to close that gap, you are choosing to be the person who builds date pickers.

And in a world where the date picker itself takes an agent about four minutes, being the person who builds date pickers is not a position you want to hold.

Try this week

Take the next ticket that arrives already containing a solution. You will spot it because the title is a thing to build rather than a thing that is wrong. Before you estimate it, send exactly one message:

Quick one before I scope this. What happens if we don’t build it? Just want to make sure I’m solving the right thing.

Then wait. Do not soften it, do not stack three more questions on top of it, and do not answer it yourself in the same message.

Note what comes back. If it changes the ticket, put the new version in the ticket where everyone can see it. That is the whole move.