Engineers must make tradeoffs between time-to-market and detailed product requirements.
I admit it. I was fixated on the TV screen during the recent Olympic Games. I particularly enjoyed the biathlon, which competes with curling as one of the most peculiar winter sports. Biathlon is essentially a Nordic ski race where the competitors, carrying rifles, make stops to shoot at targets. It combines aerobic fitness with marksmanship, as maxed-out competitors carefully aim at the targets and fire between breaths and heartbeats.
Typical rules are that the competitors take five shots. If they hit each target, they continue racing the circuit. For each target missed there is a penalty lap of 100 to 200 meters before they rejoin the race course. Some competitors shine at the shooting range. Ideally, one would rapid fire accurately, and continue racing. But many have heaving shoulders while gasping for air, and are unable to accurately shoot until they recuperate a bit. Their strategy is to delay the first shots until they know they are in a slightly recovered state, and then fire. Even then, many competitors delay each shot, making sure they have the open sights on the target before squeezing the trigger. Others shoot rapidly. There is a strategic tradeoff to be made between accuracy (percentage missed), total time at the range, and the size of the penalty loop.
This brings me to product requirements. This is analogous the tradeoff that product marketing and engineering face when defining a new product. You can take more time in getting the product requirements just right, and then execute. Or you can go forward quickly, but with unverified product requirements.
Like the biathlon competitor who takes a few more seconds to fire, there is a Faustian bargain to be made: Delay several seconds and you are that much further behind the pack. But miss, and you are even further behind. Does delaying lead you to a better definition or to a substantially better product that enables you to avoid a "penalty lap" of a redesign?
The answer is "It depends." In the ideal world you have verified and prioritized the product features, and there is no ambiguity. You execute against this list. But the ideal world, like the ideal capacitor, is a fiction. Just as we model imperfections of capacitors and other components, we should be aware that we never have perfect market information.
Different situations require different strategies. If you are creating the first in a long line of derivative products (think iPhone), then the "penalty lap" for missing the definition can be extreme. If you are making architectural choices that you will have to live with for a very long time, then I suggest taking those extra breaths and get the definition just right.
Other situations require more rapid shooting. This includes situations where the requirements are uncertain, and are difficult to perfect. Think about entering a new market. There is only so much knowledge that can be reaped without being a participant. In this case, getting a product out there may be the fastest way to gather the detailed requirements.
My analogy with biathlon would be where a competitor didn't trust the sights and suspected they were misaligned. In this case, it is better to take a first shot, and see which way you missed. Then you could systematically compensate for the later shots. Of course, no one does this in biathlon, as they are always sighted in ahead of time, so there is a limit to all analogies.
Wait until near-perfect, then execute. Execute quickly, and then polish. I've seen both work, and I've seen both fail. The situation defines the strategy.
Fast shooting or slower shooting? Where have you seen success and failure in product development?