Small teams that experiment with quantum computing tend to hit the same snag within the first fortnight. Someone suggests a promising problem, someone else wants to try a particular programming framework, a third person asks whether the work can run on real hardware, and a fourth wants a polished demo for the board. Soon the project description reads like a shopping list, and nobody can say what would count as a successful first experiment. This how-to walks through a short procedure for fixing that: write down the hard requirements of your first quantum prototype, label everything else as a preference, and use the preferences only to break ties.
The steps are deliberately plain. You need an hour, a shared document and the people who will actually do the work.
Step 1: Name the question the prototype must answer
Quantum projects are often exploratory, so the first requirement is to state what you want to learn. Examples include: can this optimisation problem be encoded in a form a quantum routine accepts, does a small instance behave as the theory predicts, or how much does noise change the output on a toy case. Write the question in one sentence. If you need two, you probably have two prototypes.
Step 2: Collect every wish, unfiltered
Give everyone five minutes to list what they would like from the experiment. Do not debate. Expect entries like “runs on real hardware”, “uses the newest framework”, “handles fifty variables”, “has a live visual”, “can be repeated by a colleague”, “finishes in under a day”. Accept them all and number them.
Step 3: Apply the blocker test
For each item, ask: if this were missing, would the prototype fail to answer the question from Step 1? Items that pass the test are hard requirements. Items that do not are preferences. Here is how a typical list sorts out.
- Hard requirement: a problem instance small enough to simulate classically, so the quantum result can be checked against a known answer.
- Hard requirement: another person can rerun the experiment from written steps.
- Hard requirement: the code records which settings produced which output.
- Preference: running on real hardware. Valuable, but a simulator can answer the first question.
- Preference: the newest framework release.
- Preference: a slick visual for presentations.
A caution on over-promoting
The most frequent error is promoting “real hardware” to a requirement because it sounds more serious. Sometimes it is indeed essential, for example when the question is about noise. If your question from Step 1 does not mention noise or device behaviour, treat hardware as a tie-breaker.
Step 4: Cap the list
Keep hard requirements to five or fewer. If you end up with seven, look for pairs that really express the same condition, or ask whether the prototype is trying to be two experiments. A short list is easier to check at the end, and checking at the end is the point.
Step 5: Rank the preferences
Order the remaining items from most to least wanted. Treat the top of the list as your tie-breakers: when two ways of building the prototype both meet every hard requirement, choose the one that satisfies more of the ranked wishes. This stops the debate from resetting each time someone mentions a new idea. For background on why the structure of the problem matters so much to what can be run, a clear account of how quantum routines approach hard optimisation tasks gives useful context for Step 1.
Step 6: Build the thinnest slice first
Before polishing anything, create a minimal version that meets only the hard requirements. A small instance, a simulator, recorded settings, written rerun instructions. Run it, compare the output to the classical check, and note what surprised you. Only then add preferences in rank order. If you want to understand one of the building blocks you might meet along the way, an explainer on the transform that sits inside many quantum algorithms is a sensible side read.
Step 7: Re-check the list at the end of each week
Open the document every Friday and answer two questions. Did any hard requirement turn out to be a preference? Did any preference turn out to be blocking? Adjust, and record why. Without a trail of reasons, the list quietly drifts back into a shopping list.
A worked example with a delivery-routing toy case
Say a logistics analyst wants to see whether a quantum-style optimisation routine can handle a routing puzzle. Step 1 gives the question: does a small routing instance, encoded for the routine, return a route no worse than the one a classical solver finds? Step 2 produces a long wish list, including live traffic data, a map display and cloud hardware access. Step 3 sorts it. The hard requirements are a six-stop instance with a known optimal route, written rerun steps, and a log of encoding choices. Live traffic, the map and the cloud hardware all fail the blocker test, because none of them is needed to answer the question.
The ranked preferences then read: first, a ten-stop instance, because it stretches the routine a little; second, a basic plot of route cost across runs; third, hardware access. When the analyst gets an offer of free hardware time midway through, she consults the list, notes that the six-stop instance already passes the classical check, and decides to schedule hardware only after the ten-stop instance runs on the simulator. Nothing is lost, and the order is explicit.
What to do when the question itself changes
Quantum work moves quickly, and a first result often suggests a better question. That is fine, but treat it as a new prototype with a new list. Copy the document, rewrite Step 1, and run the blocker test again. Hard requirements from the old list may fall away, and preferences may become essential; hardware, for instance, becomes a requirement the moment the question is about device noise. Resist the temptation to patch the old list in place, because patched lists accumulate contradictions.
An aside on choosing under uncertainty
The same pattern turns up outside technology whenever the stakes are high and the options plentiful. International patients considering heart care, for example, can read BestCardiacHospitals, an educational website that describes comparing care options in stages, and the site points out that its pages are for education, not medical advice. Different domain, same first move: fix the practical conditions, then compare.
Common mistakes to avoid
- Treating every enthusiasm as a requirement. Enthusiasm is a great fuel and a poor filter.
- Skipping the classical check. A quantum output you cannot verify teaches you little.
- Declaring victory by demo. A good visual is a preference; a reproducible result is the requirement.
- Adding hard requirements mid-project without removing others. Swap, do not stack.
A ready-to-copy template
- Question this prototype answers: one sentence.
- Hard requirements: up to five bullets, each testable.
- Ranked preferences: as many as you like, in order.
- Review date and who owns the list.
Fill it in before anyone writes code. If the team cannot agree on the question, stop there; no choice of framework will rescue a prototype that has no question. If they can, the rest of the decisions tend to fall into place in an afternoon, and the first result, however modest, will be one you can trust.
