In a year-end review, the development team's summary shows twelve field pilots, of which eleven carry favourable technical reports and favourable user feedback, while only two lines on the same table have converted into purchase orders. The explanation offered around the table tends to repeat itself: the budget cycle shifted, the decision-maker changed, the timing was unfavourable. Each of those explanations may be individually accurate, yet repeated eleven times in succession they no longer describe a sequence of coincidences but a recurring pattern. The name of that pattern is not pilot failure. It is the divergence between what the pilot measured and what actually governed the purchase decision — a divergence that no amount of additional technical validation will close, because the two questions were never the same question.
The same pattern surfaces from a different face on the capital-intensive side. A module that measurably reduces energy consumption at a facility is endorsed by maintenance engineering, the technical team confirms the benefit, and the arithmetic holds; the plant manager's agenda for that period, however, is not energy cost but unplanned downtime, and the investment budget is being consumed in full by that second heading. On the vendor's side this becomes a sequence of meetings in which the problem is validated but the decision never arrives; on the buyer's side it becomes a file that nobody rejects and nobody owns, sitting on the table for the balance of the year. Neither party has said anything untrue, yet no shared outcome is produced — a configuration that concerns not the fit between solution and problem, but the position of the problem in a sequence.
The pattern has a name — problem–solution misfit, a solution addressed to a genuine problem that nevertheless sits low in the customer's order of priority rather than at the top of it — and its distinguishing feature is that it contains no error in the conventional sense. The problem is real, the solution works, the benefit is calculable; the single missing element is that the benefit does not enter the top three headings of the customer's resource allocation. An organisation's problem inventory is never a flat list but an ordered one, and the criterion governing that order is not the magnitude of the problem but who carries its consequence and in which period. A loss invisible on the annual budget horizon will, whatever its absolute size, rank behind a smaller loss that threatens quarterly performance.
The first producer of misfit is the discovery method itself. When a customer is asked to name a problem, the answer describes not the most expensive problem but the most easily articulable one, and articulability correlates with familiarity rather than with urgency. The frictions that genuinely cost an organisation are typically those that have been normalised, absorbed into process, and consequently no longer named as problems at all — a manual reconciliation running between three separate systems, an approval round repeated monthly whose duration nobody measures, a quality threshold renegotiated at each delivery. These do not surface in a discovery conversation, since nobody in the organisation regards them as anomalies; what surfaces instead is the heading the institution is already working on, which is precisely the heading with the lowest residual demand for an external solution.
The second producer sits inside the vendor and operates in the opposite direction. Once a team has built a particular capability, a tendency emerges to define the problem in terms that the capability happens to fit; the location of technical competence determines the location of the problem being sought. That tendency is functional at the outset, reducing search cost and allowing rapid progress in the domain where the team is already strong — this is what makes an organisation efficient. The difficulty arises when the condition changes, whether because the first customer segment is exhausted or because the buyer's budget priority has shifted, and the definition remains fixed. An institutional layer compounds it: the person validating the problem in the room is frequently not the person whose budget would pay for the line, and to the degree that validation authority and payment authority diverge, favourable feedback ceases to indicate purchase intent.
The corporate consequence of this mismatch does not appear on the revenue line; it appears in the secondary indicators describing how revenue was obtained. The first is the length of the sales cycle: a proposal addressing a top-ranked problem is pulled forward by the buyer's own calendar, whereas a proposal addressing a fourth-ranked problem advances only through vendor follow-up and requires fresh justification at every step. The second is the conversion rate from pilot to deployment; the share of technically successful pilots that become funded rollouts measures not whether the product works but where the problem it solves stands in the queue. The third is the discount depth required to close, since every transaction in which price determines the decision is a numerical statement that the benefit was not large enough, in the buyer's assessment, to render price comparison irrelevant.
A fourth indicator, and the least frequently noticed, is the dependence of revenue on the founder. A problem ranked low in the order of priority is moved upward only while someone in the room is able to reframe it, and that reframing is usually performed by the founder. The result is a conversion rate materially higher in meetings the founder attends and materially lower in those attended by the commercial team alone — a differential routinely misdiagnosed as a competence gap and addressed with a training budget. The difference, however, is not competence but framing authority; the founder is selling not the product but the position of the problem in the sequence, and until that act is converted into a transferable process with its own artefacts, it will not be repeatable by anyone else.
The structural fragility these indicators combine to produce is the cyclicality of the revenue itself. A solution addressing a low-ranked problem renews without friction in periods when budgets are loose, and heads the cancellation list at the first contraction, precisely because cancelling it halts no operational process. Aggregate growth rates conceal this fragility, since during an expansion both categories of revenue grow at comparable rates and the divergence only becomes observable in a contraction. At the diligence table the question posed is therefore not the size of the revenue but the budget line from which it is drawn — an operational necessity line, or a discretionary improvement line. Where the answer is the latter, the multiple compresses, conditions precedent multiply, earn-out structures are tied to revenue continuity, and the representation and warranty package widens to encompass customer renewals.
The mechanisms that neutralise this tendency operate at the level of decision architecture rather than individual awareness, and they separate into four components. The first is the budget line test: before a proposal is permitted to advance, the name of the line the spend will come from, the owner of that line, and what has been deferred to create room within it are recorded in writing; where any of the three is blank, what exists is not a validated problem but an acknowledged observation. The second is the priority record, capturing where the customer ranks the problem on their own list at the moment of proposal rather than at the moment of approval, with the same question repeated at renewal so that movement in the ranking is tracked. The third is the pilot exit threshold, written by both parties before the pilot begins and specifying which measurable outcome must cross which threshold for a purchase to follow, and who holds that decision — a pilot without a threshold being a cost item that produces no decision regardless of its result. The fourth is the counter-argument role: at every material opportunity review, a named individual is tasked with arguing that the problem ranks fourth, with the role rotated between people.
BEIREK's intervention in capital-intensive and financed projects is constructed along exactly this line, since the same mismatch is considerably more expensive at project scale: where a software pilot addresses the wrong problem, a quarter is lost; where a facility or an infrastructure investment addresses the wrong problem, the economic life of the asset is lost. During development we test the priority of the offtaker or end-user side not through stated need but through that party's own budget lines, regulatory obligations and operational constraints; the question put is not whether they need the outcome, but which line this expenditure contracts and who signs off on that contraction. The stakeholder pre-mortem we run ahead of FID explicitly constructs the scenario in which the project works technically and goes unused, and names the shift in priority from which that scenario would arise.
What makes this framework operative is not a single analysis but the continuity of the record and the rhythm. Priority assumptions — whose problem, at which rank, funded from which line — are entered into a decision log with a date and a named owner; at each phase gate those assumptions are reopened, and an assumption that has moved recalibrates scope and contract structure even where it does not halt the project. Once stage transitions are tied to measurable exit thresholds, a favourable technical report ceases to constitute a standalone basis for advancing, and capacity is released only to the extent that the buying side's priority has been confirmed. The visible benefit of this discipline lies less in stopping the wrong projects than in the fact that the right ones arrive at financing and diligence with a defensible chain of reasoning already assembled.
What determines the value of a solution is not the magnitude of the problem it solves but the position that problem occupies in the customer's own ranking, and that ranking is read in the counterparty's budget schedule rather than inside the product. The operative question is accordingly not whether the customer accepts that the problem exists, but what they are prepared to give up today for the problem they have accepted — and wherever that question goes unanswered, what is held is a solution without, as yet, a buyer.