The cheapest feature is the one you never had to build

A familiar line in a customer meeting: “If you integrated with our system, we would buy.” Sales passes the request to product. Engineering estimates six weeks. A task enters the plan before anyone has established what is actually blocking the deal.

Integration may indeed be essential. The same words can also hide reluctance to transfer data manually, a missing budget, inability to approve a vendor or a polite way to end the conversation. Six weeks of development will not distinguish these beforehand.

Name the assumption before choosing the solution

RAT — Riskiest Assumption Test is an approach to testing risky assumptions. In Next Move Theory, you first state the conditions an initiative depends on, then choose a test based on the cost of being wrong, uncertainty and the cost of obtaining evidence.

Replace “customers need integration” with a specific claim: “Finance leads at chains approving purchases weekly will pay ₽40,000 for a pilot if they can transfer current requests without re-entering them.” Now there is a buyer, a situation, a price and an observable action.

Now you can test more than demand. Is the necessary data accessible? Who authorises it? Can the result return to the existing workflow? Does implementation cost leave room for profit? There will be several conditions for success, each needing its own evidence.

Match the test to the unknown

Consider a hypothetical procurement service. The team thinks automatic request import is the integration’s main value. It offers one suitable client a limited pilot: the client exports a file, the team manually converts it, and the user receives a result in the product.

Disclose the manual part in advance. The client should know what already works, who handles the data and under what conditions. The pilot tests usefulness and willingness to engage, not the reliability of an integration that does not exist yet.

If the main risk is technical — missing API fields or infrequent updates — discussing value will not remove it. Run a short technical check on an authorised dataset. A cheap experiment is useful only if it answers the right question.

Do not confuse the strength of different signals

“Sounds interesting” means the offer was not rejected in conversation. Assigning someone to a pilot is a stronger commitment. An agreed payment tells you more about budget and purchasing. Repeated use helps investigate whether the value lasts.

These signals are not interchangeable. One paid pilot does not establish market size. A free pilot does not test the chosen price. Success with the founder’s guidance does not show that the next customer can succeed independently.

A useful test record has five fields:

• Assumption: what must be true for us to continue.
• Participants: who we are testing and why they fit.
• Observation: which action or outcome we can record.
• Decision threshold: which outcomes mean continue, change the approach or stop.
• Limit of inference: which question the experiment does not answer.

Set the threshold before testing, based on economics and the cost of the next step. Otherwise the team can almost always find a way to call the observed number good.

A rejection needs an explanation too

Suppose the customer accepts the price but refuses to send a file because export needs IT involvement and IT has no time. The team has not learned that “nobody needs the product”. It has found a specific dependency in getting started.

Options remain: another data-transfer method, a client with an export ready, or a revised scenario. If the barrier affects the whole segment and is too costly to overcome, defer the direction. If it affects only one implementation type, abandoning the entire idea is premature.

Record the conclusion: which assumption changed and what can now be treated as known. Without it, a failed test will return to the backlog a month later under a new name.

What to do with a six-week request

Before estimating a full integration, bring product, sales and an engineer together for a short review. State the decision, list the unknowns and choose the first evidence capable of changing the plan.

The integration may still go into development, but with a specific scenario, validated constraints and clear acceptance criteria. Or another export or ready report may be enough. Either way, engineering time is spent on a clearer basis.