Quantum programs fail commercially when they treat all use cases as equally plausible. A serious platform needs a portfolio process that separates research bets, learning projects, benchmark candidates, customer pilots, and productizable services.
The right product question is not “can quantum help?” It is:
What decision, simulation, optimization, or scientific result becomes more valuable if quantum evidence improves it, and what evidence would prove that improvement?
25.1 The portfolio funnel
View diagram source
flowchart TB
Ideas[Use-case ideas] --> Triage[Triage]
Triage --> Baseline[Classical baseline]
Baseline --> QuantumFit[Quantum fit assessment]
QuantumFit --> Resource[Resource estimate]
Resource --> Pilot[Pilot]
Pilot --> Evidence[Evidence review]
Evidence --> Product{Productize?}
Product -- yes --> Service[Quantum-enabled service]
Product -- no --> Archive[Archive or research track]Every stage should be allowed to kill the idea. A portfolio that never kills ideas is not a portfolio; it is a backlog of wishful thinking.
25.2 Use-case classes
| Class | Near-term posture | Evidence required |
|---|---|---|
| chemistry and materials | credible long-term value; near-term experiments selective | validated energy/observable estimates against classical baselines |
| optimization | highly problem-specific; many classical competitors | quality, feasibility, runtime, and cost versus strong heuristics |
| simulation of quantum systems | strongest conceptual fit | observable accuracy beyond reachable classical approximation |
| cryptanalysis | planning and defense, not near-term offensive capability | resource estimates and quantum-safe migration analysis |
| machine learning | mostly exploratory | clear advantage over classical ML, not just novelty |
| random sampling / benchmarks | useful for hardware evaluation | benchmark meaning and limitations stated clearly |
View diagram source
mindmap
root((Quantum use-case portfolio))
Chemistry
electronic structure
reaction pathways
materials
Optimization
routing
scheduling
portfolio
Simulation
many-body systems
lattice models
Security
resource estimates
migration planning
Benchmarks
hardware quality
compiler regressions25.3 Classical baseline discipline
A quantum pilot without a serious classical baseline is not an experiment. It is a demo.
View diagram source
flowchart LR
Problem[Problem instance] --> Classical[Classical baseline]
Problem --> Quantum[Quantum approach]
Classical --> Compare[Compare]
Quantum --> Compare
Compare --> Decision{Improvement?}
Decision -- yes --> Scale[Scale pilot]
Decision -- no --> Learn[Record limits]Baseline requirements:
| Requirement | Why it matters |
|---|---|
| strong classical heuristic | avoids beating a straw man |
| same data and constraints | prevents false comparison |
| same success metric | avoids metric shopping |
| cost and runtime included | captures product reality |
| uncertainty reported | prevents overclaiming |
25.4 Resource estimation as product filter
Resource estimation turns a vague future claim into an engineering forecast. Microsoft’s resource estimator is an example of tooling that estimates physical qubits, logical qubits, runtime, and related architecture assumptions for fault-tolerant programs [R28, R49].
View diagram source
flowchart TB
Algorithm[Candidate algorithm] --> Logical[Logical resource estimate]
Logical --> Physical[Physical resource estimate]
Physical --> Assumptions[Assumption review]
Assumptions --> Economics[Cost and time model]
Economics --> Decision{Continue?}Use estimates to answer:
- how many logical qubits are required,
- how many physical qubits are implied under assumptions,
- how much runtime is implied,
- what error-correction scheme is assumed,
- which assumptions dominate the estimate,
- what hardware improvement would change feasibility.
A resource estimate is not a promise. It is a structured way to expose assumptions.
25.5 Pilot design
A pilot should be designed around a decision, not a press release.
quantum_pilot:
business_question: string
technical_question: string
classical_baseline: string
quantum_method: string
target_metric:
name: string
threshold_for_success: string
dataset_or_instance_set:
source: string
representativeness: string
execution_plan:
simulator_runs: int
qpu_runs: int
providers: []
evidence_package:
trust_report_required: true
reproducibility_required: true
exit_decision:
continue_if: string
stop_if: stringView diagram source
flowchart TB
Pilot[Pilot] --> Decision[Decision to inform]
Pilot --> Baseline[Baseline]
Pilot --> Metric[Metric]
Pilot --> Evidence[Evidence package]
Pilot --> Exit[Exit criteria]If the exit criteria are not written before execution, the pilot is vulnerable to narrative drift.
25.6 Productization readiness
View diagram source
flowchart LR
Demo[Demo] --> Repeatable[Repeatable experiment]
Repeatable --> Governed[Governed pilot]
Governed --> Service[Service API]
Service --> Product[Productized capability]Productization checklist:
| Area | Product-ready question |
|---|---|
| value | does the quantum component improve a decision users pay for? |
| reliability | can the system report uncertainty and failure honestly? |
| reproducibility | can results be regenerated or audited? |
| cost | is the unit economics model acceptable? |
| latency | does the workflow fit user expectations? |
| compliance | can data, access, and export constraints be managed? |
| support | can incidents be triaged without research staff every time? |
Most quantum work should not be productized yet. That is not pessimism. It is discipline.
25.7 Pricing models
View diagram source
flowchart TB
Pricing[Pricing strategy] --> Access[Access-based]
Pricing --> Job[Job-based]
Pricing --> Result[Result-based]
Pricing --> Advisory[Advisory / research]
Pricing --> Hybrid[Hybrid service]Pricing options:
| Model | Risk |
|---|---|
| access-based | rewards utilization, not useful evidence |
| job-based | encourages many low-value executions |
| result-based | hard when uncertainty is fundamental |
| advisory | may not scale beyond experts |
| hybrid service | best fit when quantum is one component of a broader workflow |
For most near-term offerings, sell a hybrid service or expert workflow, not raw QPU usage.
25.8 Portfolio dashboard
View diagram source
quadrantChart
title Quantum portfolio view
x-axis Low evidence --> High evidence
y-axis Low business value --> High business value
quadrant-1 Scale or productize
quadrant-2 Build evidence
quadrant-3 Stop
quadrant-4 Opportunistic research
Chemistry pilot: [0.62, 0.82]
Routing optimization: [0.45, 0.65]
ML demo: [0.25, 0.40]
Benchmark suite: [0.78, 0.35]
Security planning: [0.70, 0.75]Dashboard fields:
| Field | Purpose |
|---|---|
| value hypothesis | why anyone cares |
| quantum hypothesis | why quantum may help |
| baseline strength | how hard the comparison is |
| evidence level | what has been demonstrated |
| resource estimate | future feasibility |
| cost to next evidence | budget discipline |
| decision owner | prevents orphaned pilots |
25.9 Chapter rule
A quantum use case is not real because it is theoretically elegant. It becomes real when it survives baselines, resource estimates, operating constraints, and a user decision that improves because of the evidence.