Hacker Newsnew | comments | show | ask | jobs | submit login

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.

However, your goals, your rules.

-----


Eh, I disagree. Programming can help you achieve flow, too. Flow seems like a meta-goal.

-----


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).

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: