When someone asks me about using quantum computing, the first thing I look at is not the algorithm or the hardware. It’s the structure of the problem. Quantum methods only become interesting when a problem has certain characteristics, for example: - very large search or configuration spaces - complex interactions that are difficult to simulate - optimization landscapes with many competing constraints - models where probabilistic sampling plays a role If the problem is straightforward, well-structured, and already handled efficiently with classical methods, quantum is usually not the right tool. And that’s completely fine. Most real-world systems today are still best handled with classical computing and machine learning. The role of quantum, at least for now, is to explore whether certain problem structures might benefit from a different computational approach. This is why discussions about quantum should start with the problem itself — not with qubits, hardware roadmaps, or algorithm names. Technology choices come later. Clear thinking comes first. Question: When you think about problems in your work or research, what part tends to be the hardest: computation, modeling, or data?

When companies experiment with quantum computing, many pilots don’t move forward. That’s not because quantum is “useless.” It’s usually because of one of these reasons: 1️⃣ The problem wasn’t clearly defined: If the goal is vague — “explore quantum” — the outcome will also be vague. Without clear success criteria, there’s no meaningful evaluation. 2️⃣ The classical baseline wasn’t strong enough: If you compare a quantum prototype to a weak classical implementation, the results don’t mean much. A fair comparison requires strong classical benchmarks. That takes effort. 3️⃣ The bottleneck wasn’t computational: Sometimes the real constraint is: - data quality - modeling assumptions - business constraints - integration complexity Quantum won’t fix those. 4️⃣ Expectations were unrealistic: If the expectation is dramatic speedups or immediate ROI, disappointment is almost guaranteed. Current quantum hardware is still early-stage. Here’s the important part: A pilot that concludes “not yet” is not a failure. It’s a disciplined decision. The real failure is investing heavily without careful evaluation. In this community, we’ll treat quantum exploration as: - structured - honest - and hypothesis-driven That’s how serious teams operate. Question: If you’ve ever tested a new technology in your company, what was the biggest lesson you learned?

If a company decides to explore quantum computing, the right approach is not: “Let’s integrate quantum into our product.” It’s something much smaller and more controlled. A realistic 90-day pilot usually looks like this: Phase 1: Problem Scoping (Weeks 1–3) - Identify one clearly defined problem - Map the current classical baseline performance - Define measurable success criteria - Decide what would count as “interesting” vs “not useful.” No circuits yet. No hardware yet. Just clarity. Phase 2: Feasibility Exploration (Weeks 4–8) - Reformulate the problem in a quantum-compatible way - Test small hybrid prototypes (often on simulators first) - Compare against strong classical baselines - Document limitations honestly At this stage, most serious teams learn more about their own problem structure than about quantum hardware. Phase 3: Evaluation & Decision (Weeks 9–12) - Was there a measurable signal? - Was the comparison fair? - Did the quantum component add modelling value? - Is this worth deeper research, or should we stop? Stopping is a valid outcome. In fact, in many cases, the correct decision after 90 days is: “Not yet.” And that’s a successful pilot — because it prevented wasted investment. Quantum exploration today is about disciplined experimentation, not dramatic breakthroughs. The companies that benefit long-term are the ones that: - Define scope carefully - Benchmark honestly - And avoid emotional decisions Question: If your team ran a 90-day pilot, what would you want to learn by the end of it?

If you work in a company and someone mentions quantum computing, the reaction is usually one of two extremes: - “We need to jump on this immediately.” - “This is too early — ignore it.” Both are unhelpful. A more balanced approach looks like this: 1️⃣ Don’t start with hardware. Start with your problem. What are you actually trying to improve? Optimization? Modelling accuracy? Simulation fidelity? If the problem isn’t clearly defined, quantum won’t fix it. 2️⃣ Map your bottlenecks honestly Is your limitation: - Data quality? - Model assumptions? - Compute cost? - Scaling behaviour? Most bottlenecks today are still classical. 3️⃣ Explore hybrid experiments If quantum is relevant, it will almost always be as a small component inside an existing workflow. Think: - Proof-of-concept - Limited-scope experiments - Controlled comparisons Not a full system replacement. 4️⃣ Define success before you begin - Is a 5% improvement valuable? - Is reduced modelling bias important? - Is learning strategic positioning the real goal? Without a clear success metric, experiments drift. Quantum exploration today is about: - Learning - Careful evaluation - Controlled experimentation Not dramatic performance breakthroughs. Companies that approach it calmly and methodically will be much better positioned if and when the technology matures. Question: If you’re in a company, what would make quantum worth even a small experiment for you?

A common question I get is: “So… is quantum better than classical?” The honest answer is: it’s very hard to compare them fairly. Here’s why. 1️⃣ Problem formulation matters: - Small changes in how a problem is written can drastically change performance — for both quantum and classical methods. - If the formulation favours one side, the comparison isn’t meaningful. 2️⃣ Classical baselines improve constantly: - Classical algorithms and hardware are extremely mature. GPUs, distributed systems, optimization tricks — they’re evolving fast. - A “quantum win” today might disappear once classical baselines are improved. 3️⃣ Overheads are real: Running something on quantum hardware includes: - state preparation - measurement - repetition for statistics - classical optimization loops These overheads matter in practical settings. 4️⃣ Noise and scale: Current quantum devices are noisy and limited in size. That means: - Results can be unstable - Scaling behaviour is not fully understood - Simulators can sometimes outperform real devices This is why serious researchers are cautious when claiming performance advantages. It’s not that quantum has no potential —it’s that fair comparison is a very technical and careful process. In business contexts, this is even more important. You don’t want to compare a well-optimized classical pipeline with a prototype quantum experiment. That’s not apples-to-apples. In this community, we’ll always ask: “Is this comparison fair?” Because that question alone filters out a lot of noise. Question: If you had to compare two technologies fairly, what do you think is the most important factor — speed, accuracy, cost, or scalability?