When to Build, Partner, Wait, or Avoid
Strategy is choosing the next action, not choosing a mood. This chapter turns quantum enthusiasm and skepticism into six concrete decisions — build, partner, invest, monitor, wait, avoid — each with its own evidence threshold.
The right label for most quantum opportunities is monitor or wait, and treating those labels as failures instead of answers is how portfolios fill up with premature builds.
This chapter gives you the working standard: make the call from baselines, evidence, hardware assumptions, customer urgency, and timing — then write down the proof gates that would move you from one label to another.
Core concepts: company diligence, investment proof gates, application baselines.
Six labels, six thresholds
Application strategy exists to choose the next action. Build, partner, invest, monitor, wait, and avoid are not moods; they are decisions with different evidence thresholds and different costs of being wrong.
Roughly: build when the problem is real, the baseline is known, the wedge is actionable, and your team can produce evidence. Partner when something essential — domain access, hardware access, distribution — is missing but available from a credible counterpart. Invest when the thesis has proof gates, asymmetric upside, and tolerable risk. Monitor when the structure is promising but the evidence is early. Wait when the timing is wrong even if the idea is right. Avoid when there is no baseline, no evidence, or no credible path.
Score the decision, then check the clock
The decision score keeps the components visible:
decision_score = claim_quality + proof_progress - risk - kill_criteria_pressure
It disciplines the memo; it does not replace judgment. Two opportunities with equal scores can deserve different labels because one is reversible and the other is not.
Expected value adds the clock:
EV = probability_of_technical_success * value_if_success - cost_of_waiting - cost_of_capital
Cost of waiting is the term people forget. Waiting is not free — competitors move, windows close — but neither is committing, and capital spent early on the wrong wedge cannot be spent later on the right one.
Worked example: one opportunity, five labels
Consider a quantum chemistry application aimed at pharmaceutical customers. Depending on where you sit, every label can be right at once. Build is justified for a resource-estimation and benchmarking tool — constructible now, evidence-producing, useful regardless of hardware timing. Partner is justified with a chemistry customer who brings real problems, or a hardware provider who brings access. Invest may be premature until proof gates exist. Monitor fits fault-tolerant algorithm progress. Avoid fits the vague version of the same pitch: no named buyer, no baseline, no wedge.
Notice the shape of that answer. The decision is not "is quantum chemistry promising?" It is a portfolio of labeled actions, each tied to evidence you can actually gather next.
How decision memos fail
The first failure is treating monitor or wait as cowardice. When uncertainty is high and commitment is expensive, deferring with a defined revisit trigger is the strong play. The second is using avoid casually: avoid should cite specific failed proof gates, weak baselines, or broken economics — otherwise it is taste, not analysis.
The third is the field-level verdict: "we are building in quantum" or "we are avoiding quantum." Real portfolios mix labels — build tooling, partner on a benchmark, monitor hardware, avoid a specific application claim — simultaneously. A memo that cannot hold four labels at once is too coarse to act on.
The engineering view
This is portfolio management under uncertainty, and engineers already know the pattern. Architecture decision records: write the decision, name the assumptions, define the reversal conditions, revisit when evidence changes. Quantum strategy needs exactly that machinery because the technical assumptions — hardware roadmaps, algorithm results, benchmark outcomes — move under you.
Match the action to its reversibility. Prototypes, benchmarks, and interfaces are cheap and reversible; build those when evidence is scarce. Product commitments and capital are expensive to reverse; demand proof gates first.
What a finished memo contains
The complete decision memo: the label; the buyer, workflow, and classical baseline; the evidence with its level; the scores; three proof gates; two kill criteria; the risks; and the next evidence to seek. Two more lines belong in every memo: what would change the answer, and a reminder that educational analysis is not financial advice.
If that sounds bureaucratic, compare it to the alternative — a decision made on excitement and defended with adjectives. The memo is how a team remembers why it believed something, which is the only way to notice when it should stop.
Exercise
Write the decision memo. Choose one quantum application and produce the full memo.
- Baseline: buyer, workflow, classical baseline, value at stake, and the current failure mode.
- Evidence: evidence level, hardware dependence, integration burden, moat, market timing, and source quality.
- Gates: three proof gates and two kill criteria, written so a skeptic could check them.
- Scores: apply the decision score and the opportunity expected value, and show the arithmetic.
End with the label and the next evidence that would change it. If your memo reaches a decision with no baseline and no kill criteria, it is a horoscope — rewrite it.
Check your understanding
Without notes: write a decision memo skeleton for one application — label, rationale, risks, kill criteria, next evidence.
A passing answer treats all six labels as legitimate, ties avoid and wait to specific findings rather than vibes, holds different labels for different wedges of the same field, and states reversal conditions for whatever it commits to.
Oral defense: defend a wait or monitor label against someone who calls it indecisive.
If you get stuck
If your memo lacks baselines, evidence labels, proof gates, or reversal conditions, return to Chapter 71 (Application Evidence Levels) for the labeling discipline and Chapter 64 (What Makes a Problem Quantum-Suitable?) for the baseline-first structure. Decision quality is downstream of both.