That's like saying your first test would be "complete project management system". That's not what you do. My first test for driving was "gentleman mid-pack", for biz, it was "$4K/month revenue". For Basecamp, the first test was probably "add a single post".
I think there may be an issue with your driving analogy.
Your goal all along seems to be to achieve flow: "After all, racing to me was all about getting access to long stretches of flow, that sensation of being so completely engrossed in an activity that you lose track of time and place."
You set yourself tasks to achieve that goal, and as each task was fulfilled, you may have realized that flow, again, required additional tasks to achieve.
Ok I see your point. But that only works because before becoming the podium winner, you have to go through the mid-pack stage. Product design is not like that. Take Square for instance, where is the small first step ? Build a device that works with iPhones and that allows people to take credit card on the move? that's the product, it can't be split into smaller chunks!
You appear to lack imagination. For Square, here is one way to break it down into units which are easily tested:
1. Can I write an iOS app that reads incoming signals via the
headphone jack such that the app can separate the input into
"high" vs. "low" signals with sufficient accuracy?
2. Using "high" vs. "low" signals, can I encode "Hello world"
into a series of signals and then decode that back into
"Hello world" in my iOS app?
3. Can I encode the typical information contained on the magnetic
strip into a series of signals and then decode that back?
4. Can I do step 3 reliably such that errors during transmission
are automatically corrected for?
5. Rather than doing all of the above via prerecorded signals
being played back from another device, can I create hardware
which has data to be transmitted baked into the ROM and still
do the encode/decode?
6. Rather than baking the data into ROM, can the hardware accept
input via a serial port, encode it, transmit that to the iOS
app, and have the iOS app successfully decode it?
7. Instead of using a serial port, can I solder in a magstripe
reader to accept the input from a swiped card and send it to
the iOS app?
8. Rather than just reading the data into an iOS app, can the iOS
app communicate with a server over the internet and transmit
the data to it?
9. Can the iOS app receive a response back from the server?
... and so on. Each one of these are valid goals and are small enough to easily get a win on before moving to the next bigger goal.
You TDD your goals. Square could certainly have started with modest goals, like we did with Basecamp, such as "get to $4K/month in revenues". That probably wouldn't have floated for them, given all the VC they took. But there are many grays between that and "unseat every POS ever".
Well I guess you could say that you could split the goals to things like "make a prototype", "convince some VCs", raise "$100,000", etc. That makes for bitable chunks, but the goal has to remain. Otherwise, what's the point of breaking one's ass for 4000$/month?
You say that because you think Square is a little gadget for taking credit cards from a phone.
That is the little goal, though -- the big goal at Square is clearly to take over all real-world payments. The cheap reader was a simple place to start. (Go check out a store that running off an iPad with Square to see what they want to become).