Quantum platform teams need a way to distinguish productive exploration from uncontrolled sprawl. A value stream maps how a scientific or product idea becomes an executed workload, a reviewed result, and eventually a decision. OKRs and technical-debt ledgers keep that stream honest.
View diagram source
flowchart LR
Idea[Idea] --> Intake[Intake]
Intake --> Feasibility[Feasibility review]
Feasibility --> Experiment[Managed experiment]
Experiment --> Evidence[Evidence package]
Evidence --> Decision[Decision]
Decision --> Product[Product, publication, or retirement]Quantum value streams
| Stream | Primary value | Typical output |
|---|---|---|
| hardware learning | improve physical performance | calibration or architecture decision |
| algorithm discovery | test workload feasibility | benchmarked method or kill decision |
| platform service | provide reusable capability | API, broker, evidence, or routing feature |
| security and governance | reduce institutional risk | control, policy, audit package |
| customer enablement | translate capability into adoption | reference workflow or service contract |
View diagram source
mindmap
root((Quantum value streams))
Hardware learning
Algorithm discovery
Platform service
Security and governance
Customer enablementOKR design
Quantum OKRs should avoid vanity metrics. Qubit count, paper count, and demo count are weak proxies unless tied to validated capability.
View diagram source
flowchart TB
Objective[Objective] --> KR1[Validated capability]
Objective --> KR2[Operational reliability]
Objective --> KR3[Evidence quality]
Objective --> KR4[Cost or throughput]
Objective --> KR5[User adoption]Better objective:
Establish a reliable internal quantum workload service for chemistry exploration.
Better key results:
- 90% of accepted chemistry workloads include complete evidence manifests.
- Median experiment reproduction time decreases by 40%.
- Cost per accepted result decreases by 25%.
- Two independent reviewers can reproduce benchmark conclusions.
Technical debt categories
View diagram source
flowchart LR
Debt[Technical debt] --> Code[Code debt]
Debt --> Calibration[Calibration debt]
Debt --> Evidence[Evidence debt]
Debt --> Policy[Policy debt]
Debt --> Knowledge[Knowledge debt]
Debt --> Vendor[Vendor debt]| Debt type | Symptom |
|---|---|
| code debt | brittle scripts, unversioned notebooks, manual pipelines |
| calibration debt | undocumented validity windows, uncontrolled parameter changes |
| evidence debt | missing provenance, weak manifests, non-replayable results |
| policy debt | exceptions without expiry, access rules not enforced by code |
| knowledge debt | tacit procedures, single-owner expertise |
| vendor debt | untested portability, unclear exit criteria |
Debt ledger
View diagram source
sequenceDiagram
participant Team as Delivery team
participant Ledger as Debt ledger
participant Board as Review board
participant Owner as Debt owner
Team->>Ledger: register debt item
Ledger->>Board: prioritize by risk and drag
Board->>Owner: assign resolution or acceptance
Owner-->>Ledger: update status and evidenceEach debt item should have a drag estimate: how much it slows execution, raises risk, or weakens evidence.
Portfolio heat map
View diagram source
quadrantChart
title Quantum Portfolio Heat Map
x-axis Low operational maturity --> High operational maturity
y-axis Low strategic value --> High strategic value
quadrant-1 Scale carefully
quadrant-2 Productize
quadrant-3 Retire
quadrant-4 Harden before scaling
Workload A: [0.72, 0.82]
Workload B: [0.32, 0.76]
Workload C: [0.20, 0.24]
Workload D: [0.78, 0.35]Use the heat map to decide where to invest, where to pause, and where to retire.
Chapter close
A quantum platform needs disciplined portfolio management. The useful question is not “Are we doing quantum?” It is “Which quantum value streams are producing validated learning, reusable capability, and bounded risk?”