Good product ideas often do not begin with deep expertise in two complete fields.

They begin when someone recognises a principle in one system that might solve a problem in another.

An engineer does not need to retain every detail of a protocol, platform, or industry to reason about it. They often work with a compressed model:

  • what the system enables;
  • which problem it solves;
  • its main components;
  • its boundaries;
  • which other system it might connect to.

This model makes analogical reasoning possible. Instead of comparing every detail, we compare structures: identity with identity, permission with permission, settlement with settlement, and event log with audit trail.

That is where useful connections can appear that a specialist focused on one field may have no reason to look for.

It is also where convincing mistakes appear.

A compressed model is a tool, not evidence

Abstraction deliberately removes detail. Without it, we could not compare many complex systems or discuss a new idea quickly.

The problem begins when the removed detail controls the outcome.

Call this compression error.

Consider this connection:

Bitcoin enables programmable transfer of value. AI agents can independently use digital tools. Agents could therefore buy API calls and compute resources from one another.

As an initial hypothesis, the connection is reasonable. Two separate systems share a machine-readable and automated workflow.

The actual solution still depends on details compressed by that first statement:

  • who issues the agent’s identity;
  • who defines its budget;
  • how the recipient is authorised;
  • what happens after a duplicate payment attempt;
  • how an undelivered service is handled;
  • who controls the private key;
  • the cost of liquidity and conversion;
  • how the transaction is accounted for;
  • which rules apply to the provider and user.

The larger concept may remain valuable while the initial technical answer is wrong. The right solution might use Lightning. It might use a stablecoin, an internal credit ledger, or an ordinary monthly invoice. Verification, rather than analogy, has to establish that.

Depth and breadth have different jobs

Deep expertise reveals failure modes that a simple model cannot see. Breadth helps recognise that two distant fields have compatible shapes.

A team needs both.

A T-shaped systems builder has depth in a field where they can evaluate architecture, state, APIs, security, operations, and trade-offs. Across other fields, they build models good enough to ask a new question and have a useful conversation with a specialist.

The value of this profile is not a claim to understand every discipline. It lies in knowing how to:

  • extract a transferable principle;
  • recognise where detail is missing;
  • involve the right specialist;
  • turn an idea into a test that can fail.

Breadth creates hypotheses. Depth and evidence determine which ones survive.

Synthesizer and Verifier are not two people

It is useful to separate two modes of work.

Synthesizer

The Synthesizer temporarily lowers resistance to unusual connections. It takes a principle from one field and tries to apply it in another.

The questions in this phase remain open:

  • what becomes possible if these systems are connected;
  • which manual step disappears;
  • who gains a new capability;
  • whether a distant industry already has a solution to this problem.

The goal is not perfect accuracy in every statement. The goal is a small set of sufficiently concrete hypotheses.

Verifier

The Verifier does not try to prove that the idea is good. It looks for one assumption that could make it fail.

The questions become narrower:

  • is there a technical boundary we skipped;
  • does the workflow depend on a permission we do not have;
  • does cost grow faster than value;
  • does the product require a role or licence we did not plan for;
  • will a user actually change the current way of working;
  • can failure be reversed or repaired safely.

The same founder, product manager, or engineer can work in both modes. They need to be separated in time. If the Verifier enters too early, every new idea appears impractical. If it never enters, intuition becomes a roadmap without foundations.

Five questions for every connection

An initial assessment does not require complete expertise in a new field. It needs five written answers.

  1. Which fundamental principle are we borrowing? Not a product name or surface feature, but a capability that can transfer.
  2. Which problem are we connecting it to? The problem should exist independently of the technology we want to use.
  3. Which assumption holds the bridge together? One claim without which the idea no longer makes business or technical sense.
  4. Which detail would show that we are wrong? We want a failure condition, not only evidence that confirms the thesis.
  5. What is the cheapest credible test? The test should touch the critical assumption rather than produce a polished demo.

For an agent-payment workflow, the answers might look like this:

  • principle: software can make a provable payment for a digital resource;
  • problem: microtransactions are too expensive for manual contracting and monthly invoicing;
  • assumption: the supplier can reliably connect payment to delivery of one resource;
  • failure condition: a retry or timeout creates a duplicate charge with no safe refund path;
  • test: one agent, one supplier, a small budget, an idempotency key, and a complete audit log.

This is more useful than a general debate about whether agents will eventually have their own economy.

Confidence must be visible

The same sentence has a different meaning depending on the evidence behind it.

We therefore label ideas at one of four levels.

Intuition

We see an interesting connection. We have not yet reviewed the main constraints.

Working hypothesis

We have reviewed the basic architecture, market, and obvious failure modes. We know the critical assumption.

Evidence-supported

Data, expert review, or a prototype supports a defined part of the hypothesis. We know what remains untested.

Confirmed for a defined scope

The solution met predetermined criteria in an actual workflow and within known boundaries. Confirmation applies to that scope, not every future use.

This labelling prevents two mistakes. It does not discard a useful intuition merely because it is not yet proven, and it does not present an early idea as finished expertise.

Regulated domains require an additional step

When a hypothesis involves money, health, law, security, or personal data, a technical prototype is not sufficient evidence that the product may be offered in the intended form.

In these fields, the Verifier also involves the relevant specialist. The goal is not a general statement that “everything is compliant”. It is to determine precisely:

  • the role the product actually performs;
  • which claims may be made publicly;
  • which data or assets it controls;
  • where software ends and a regulated service begins;
  • which records, permissions, and safeguards apply to the defined scope.

Legally careful language does not weaken the idea. It separates a possibility from a claim that has already been verified.

How we use this pattern

At HILLS Lab, we do not require complete certainty before the first experiment. We require uncertainty to be explicit and the next step to produce new information.

For every new connection, we want to preserve:

  • the source principle;
  • the problem we are trying to solve;
  • the critical assumption;
  • the person or source that can verify the missing detail;
  • the cheapest test;
  • the criterion for continuing, changing direction, or stopping.

This record is small enough not to smother the creative phase and precise enough to prevent an interesting analogy from becoming an expensive project without evidence.

The most valuable idea is not necessarily the one whose author knows the most details in both fields. It is often the idea that connected two useful models early enough and then tested the detail on which that connection depends with sufficient discipline.

If you have a product hypothesis that connects several technical fields, we can help identify its critical assumption and build the first verifiable step. Talk to HILLS Lab.