Why most teams solve the wrong problem.
Most teams do not fail because they solve problems badly. They fail because they solve the wrong TYPE of problem with the wrong tools. Classification comes before methodology, and almost nobody does it on purpose.
One tethered drone, four different problems.
Picture a fiber-optic tethered FPV drone: a tiny quadcopter you fly through goggles, except instead of a radio link it trails a hair-thin glass fiber that unspools behind it as it flies. The controls and the live video travel down the cable as pulses of light.
Put one in front of a room and within seconds people are designing solutions. A lighter fiber. A better spool. A clever countermeasure. Notice what nobody did: ask which problem they were solving. That reflex, jumping straight to the build, is the mistake. The exact same drone is a different KIND of problem depending on how much you actually understand.
The tether is not a quirk. It is the whole point, and its history is a lesson by itself, a chain of solutions, each one answering the problem the last one created.
First the drone was the problem. The answer the world reached for was jamming: flood the radio link with noise and the drone falls out of the sky. Clean, logical, and for a while it worked.
So someone removed the radio entirely. Run a fiber-optic cable from the operator to the drone and the control signal travels through glass, not air. There is no frequency to block and no protocol to spoof, so the drone flies through the densest jamming as if it were not there. The idea is decades old, sketched and shelved long ago, and only became unavoidable once the previous answer stopped working.
And the tether brings its own problems: you cannot fly past your cable, it drags, it tangles, and it hands the next team a fresh thing to ‘solve’. That is the tell. Every answer here is a new problem wearing a solution's clothes, which is exactly why naming the problem type matters more than reaching for the next fix.
Name the problem before you pick a tool.
What problems might even exist here?
Explore. Map futures, push trends to their extreme, work backward from where things could go.
A portfolio of opportunities worth watching.
What does a control link that cannot be cut even open up? An eye that never drops, anywhere? Nobody has named the problem yet, let alone chosen a drone.
You engineer a beautiful spool for a mission nobody has defined, and bet the build on the wrong one.
What is the real problem, and whose is it?
Discover. Study the job people are trying to get done, look through several lenses, find the bottleneck.
A validated problem statement with evidence.
Pilots say their drones 'keep losing the link'. Is the real problem the jamming? The range? The latency? The tether is one guess, and it brings its own costs: no mobility past the cable, drag, entanglement.
You ship a flawless fiber, then learn the link was never the real bottleneck.
What is the best way to solve this?
Execute. Optimize, prototype, run the canvas, test against the metric.
A solution and the case for it.
Now it is real: 10km of 0.37mm fiber, sub-10ms latency, a spool that pays out in flight without snapping. Optimize the fiber, the spool, the drag.
You keep running discovery workshops on a spec that is already settled and just needs building.
Where can we intervene without making it worse?
Map the system. Find leverage points, stakeholders, feedback loops. There is no stopping rule.
An intervention strategy, not a solution.
The same tethered drone is one thing in a contested zone and a completely different problem over a worksite or a crowd. Solve the link and you reshape the rules, the countermeasures, the next escalation.
You treat it as a spec, field it everywhere, and the arms race you ignored writes the next chapter.
These are not boxes. They are stages you move through.
The tethered-drone problem is not permanently any one type. It STARTS undefined (what is an uncuttable link even for?), becomes ill-defined (what do operators actually lack?), and only then becomes well-defined (10km of fiber, sub-10ms latency, a spool that pays out cleanly). It earns its way down the ladder as understanding deepens.
The room that started by engineering the spool skipped the first two stages. They decided the problem was well-defined because they wished it were. The real skill is not memorizing four categories, it is knowing which stage you are standing in right now, and refusing to use a later stage's tools before you have earned them.
Some problems never become well-defined. The tether IS the wicked case made visible: drone, then jamming, then tether, then the counter to the tether. Each answer rearranges the problem and spawns the next. There is no clean formulation and no stopping rule.
You do not solve these. You intervene, watch what moves, and adjust. Treating a wicked problem as a well-defined one is how confident teams cause the most damage: they declare victory exactly when the system starts fighting back.
It classifies before it suggests.
Tell MindrianOS you are building a tethered drone and it will not hand you spool optimization. It asks the questions that locate the stage first: is the use even defined? Do you know what operators actually lack? Only once the problem is truly well-defined does it reach for execution tools. The method follows the classification, not your mood.
That single move, naming the problem type first, is the cheapest and highest-leverage decision in the whole process. Get it right and the rest of the work compounds. Get it wrong and you spend weeks building an excellent answer to the wrong question.