How do I validate the problem with real security buyers before writing a line of code?

You are trying to find out whether a problem is real by asking people who will not describe their weaknesses to a stranger. Security buyers are friendly. They are also careful, because the questions that would validate your idea, which tools they run, where their coverage ends, what broke last quarter, are the same questions an attacker asks first. Every discovery method assumes the person across the table can describe their situation to you. In security, the honest ones will not, and you have to ask differently.

Ask about the obligation, not the gap.

You will not get a security buyer to describe their gaps, so ask about something they can discuss. Do not ask where they are weak. Ask what they are measured on this year: the named program, the audit, the regulation, the insurance condition. Then ask how it is handled today, who wrote the workaround, and who owns the deadline. An obligation can be discussed with a stranger because its outline is already public. A gap is a confession.

Hold one question for the end of the call. The audit finding names a control the organization failed, and asking a stranger for it is the attacker's question dressed in compliance language. Ask for it last, where it can be refused, and treat the refusal as an answer. For a public company, read the public record first. A US public company must disclose a material cyber incident within four business days of determining that it is material, and describes its risk management in its annual filing, and both are searchable before you ever call.

Budget goes to obligations.

You are not selling an improvement, because buyers have no budget for improvement. They have budget for named programs with an owner, a deadline, and an audit behind them. We have watched the same product go from unsellable to fundable without a line of code changing, only by being described as the thing the buyer was already being measured on.

Creating a category and creating a budget line are different problems, and only the second one is fatal. A new approach charged to an old budget beats a new category with no budget.

Obligations come in three kinds, and only one funds work now. A mandate with a binder and a deadline funds work now. A voluntary framework gives the board and the auditor a shared vocabulary and funds nothing by itself. A rule that is still proposed funds nothing yet, however loudly people discuss it. Know which kind your buyer carries before you count their agreement.

Find who signs before who suffers.

You may be validating with the wrong person. The person who feels the problem, an engineer, a SOC lead, an identity owner, and the person who owns the budget are usually different people, and the CISO is often neither. For many security-adjacent products the CISO is a stakeholder, and IT, engineering, risk, or legal signs. Treating the CISO as the buyer costs quarters.

So discovery has two subjects, and it is not finished until you have interviewed both. The person who feels the problem tells you whether it is real. The person who owns the budget tells you whether it is funded and who else has to agree after you leave the room. A yes from only one of them is a free yes, the kind a team gives because agreeing costs nothing. Nobody publishes which function holds the budget for your category. You learn it in the room, and it often unblocks your pricing later.

Treat agreement as noise.

You will hear some version of "this would be very useful" in most rooms, and it means nothing here that it does not mean everywhere. Count only what cost the buyer something.

Count a named obligation with an owner and a deadline. Count an audit finding, an examiner's comment, or an insurer's condition that names the control. Count an incident inside their own organization that produced a remediation plan rather than a meeting. Count a workaround they already pay for: a script somebody maintains, a spreadsheet somebody reconciles, a consultant's statement of work, a clause in the managed-service contract. Money already leaving the building is the strongest signal you will get. And count a person whose next performance review depends on the outcome.

Log everything else separately and never count it: agreement, a yes to a pilot, an analyst's map, praise on a practitioner forum, a press cycle. One more response sounds like a loss and is not. A buyer who says they cannot measure the problem cannot fund the fix yet, and hearing that tells you what your first deliverable has to be.

Fear is not a budget line.

You are in a market where demand is manufactured by regulators, by analysts, and by the last big incident, and a manufactured problem produces agreement that sounds identical to a real one. Founders plan around the next breach as if it were a sales channel. An incident changes how a committee sees the odds, so it can reprice deals already in the funnel and close them in hours. It creates no budget line, because a budget line needs an owner, a fiscal cycle, and something it replaces. Attention fades in weeks and budgets move in quarters. A plan that depends on the next incident is not a plan.

Three tests separate a real problem from a manufactured one. Does the buyer describe it in their own words, or in yours, or in an analyst's? Is there a workaround already funded, or only a meeting? Did the last headline incident produce an obligation inside their company, or only a conversation? And read an analyst's name on your category as a warning, not as validation. Once a category is named, every competitor's discovery calls return the same yes, and the evidence stops telling you anything.

Reframe once, then stop.

The product is often unsellable as described and fundable under a different name, the obligation the buyer already carries. Better detection becomes the control your examiner will ask about in March. That is discovery, and you do it once, before you write the code.

Repositioning over and over is a different act, and it is the most reliable sign we know that a market is not pulling. A rename is fast and visible, and a board accepts it as progress, while admitting that the demand is not there produces nothing at all. So renaming fills the space where selling would be, and you will be doing it before you notice. Three marks tell them apart. The reframe comes before you build, and the rename comes after each miss. The reframe changes which obligation you discharge, and the rename changes the adjective. The first reframe onto a funded line is discovery. The third rename is the market giving you its answer.

Read the control before you ask about it.

You are not the first founder to ask a security leader what keeps them up at night, and they dislike the question. Read the regulation and the framework their auditor uses before you ask how they meet it. A founder who has read the control walks in as a peer. A founder who asks the buyer to explain it walks in as a vendor.

The practitioner forums where people complain about your incumbent are a live record of wins and losses. Read them for the workaround and the complaint, and never post there as a vendor.

Stop when the pattern repeats.

You are done when four things repeat across buyers who do not know each other: the obligation, the function that owns the budget, the workaround, and the change your product would force in their systems. Founders skip the fourth. Ask what would have to change for your product to run, an agent installed, a permission granted, data leaving the building, and who owns that change. Deployability is the objection that arrives last in every sale, and it decides your architecture now, while changing it is still cheap.

If nobody said no, nobody was asked for anything. Security buyers rarely decline. They go quiet, because a no costs them a relationship and requires a justification they have no reason to write. So end every call with a request that can be refused, a date, a name, a document, an introduction to the person who signs, and keep the refusals as your record. Nobody can tell you how many conversations this takes. Anyone who gives you a number made it up. Stop when the pattern repeats, not when you reach a count.