Questions Your Problem Interviews Should Answer Before Shipping (TF)

If you cannot answer these questions confidently after your interview round, you are not ready to ship. They are the minimum bar for technical founders. Every "I do not know" below is a reason to do more interviews, not to start building.

Who Specifically Has the Problem

Not "engineers." Not "developers." A specific role, in a specific kind of organization, with a specific recent behavior. If your answer needs more than two sentences, the audience filter is too vague. Tighten it and rerun the question.

What Is the Trigger Event

What specific incident causes the problem to show up? "Whenever something happens" is not a trigger. "A 3am page where the alert points at the wrong service" is a trigger. Without one, you cannot reach the user at the moment they care, which is when they buy.

What Are They Doing About It Today

If the answer is "nothing," the problem is probably not painful enough. If the answer is "they have a bash script" or "a Notion page someone updates Mondays," describe the workaround in three sentences. The workaround is your competition, even when it is not a product.

How Much Are They Currently Spending on the Workaround

Engineering time, dollars, or stress. Quantified. "A lot" is not an answer. "Five engineer-days per quarter" or "$200 a month on a tool we mostly do not like" is an answer. If you cannot quantify, you cannot price.

Have You Heard the Same Story More Than Five Times

If yes, you have signal. If no, you have anecdotes. One enthusiastic interview is not validation. Patterns across five or more is. Be honest about which you have.

What Vocabulary Did the Engineers Use

Write down the three or four phrases that came up across multiple interviews. If you cannot, your notes were not specific enough or you have not synthesized yet. The vocabulary is what your landing page should sound like.

Do You Have Fifteen People Who Would Try It

Not who said "sounds cool." Fifteen engineers who, when you said you would email them when an early version was ready, said yes and gave you their email. If you do not have that, you do not have a launch list, and you will be launching to strangers.

What Did You Get Wrong

You walked into the interviews with assumptions. Which one was disconfirmed? If your answer is "none," either you got very lucky or you were not really listening. Try the question again with fresh eyes on the notes.

What Is the Smallest Useful Version You Can Build

Given everything above, what is the narrowest possible product that solves the trigger event for the audience? Not the full vision. The first useful slice. If you cannot answer in one sentence, the scope is too big. Engineering brains love this question - it is essentially a minimal-viable-spec question.

If You Cannot Answer One of These

Do five more interviews focused on whichever question stumped you. Do not start building yet. The cost of building without these answers is much higher than the cost of five more conversations. The temptation to skip ahead is the most common reason technical founders ship things nobody uses.

When You Can Answer All of Them

Build. Then put the smallest version in front of the same fifteen people who told you they would try it. Next round of learning happens through usage, not conversation. You earned the right to switch modes by getting these answers first.