The über-tech-geek culture has a problem with tool obsession. Twitter, Friendfeed, Google Reader–these are all basics, but each of these have multiple competitors that the most afflicted like to sample, discuss, and obsess over ad nauseam. What ends up happening is we forget what those tools are actually for, i.e. the problems they’re supposedly trying to solve. Even worse, we stop asking whether or not those problems (when we do identify them) are even problems that we currently have.

I propose a better way: just as good programmers first abstract a solution to a problem using pseudocode, those trying to solve technology problems need to abstract their technology requirements. So, rather than start with:

I want to use Twitter and Friendfeed.

We should start with higher-level statements, such as:

I want to follow what my friends are doing across the Internet in threaded fashion, and it’d be nice to be able to push real-time to my friends’ mobile phones when I post something.

We can make a list of our technology needs in this way. Go from actual need/desire to an associated technology, rather than stumbling through “solutions” in search of problems. So let’s start our list of technology needs/desires.

I want to have all of my favorite content available to me in a centralized location so that I don’t have to go to all the various sources to collect it.

I want to know if anyone is mentioning my name or my website anywhere on the Internet, and I want to be notified via text and email.

I want my friends to be able to type little blurbs from their phone, and have them come to me (and other friends) on our phones.

I want to be able to quickly see what all of my friends have done anywhere online; this way I won’t have to go check all of their various services they use.

I’d like to know if anyone within 10 miles of my location mentions a subject I’m interested in, so maybe I can respond to them.

Ok, so that’s a sample of a few abstracted problems. No products. No technologies. Now make a similar list for yourself, and when you hear about a must-have new whiz-bang service that everyone’s using, abstract its offering(s) out in a plain-language statement.

See how that statement matches your own technology problems; if it’s not a match, either add the need/desire to your list or pass on the technology–no matter how alluring it may be. Too many tools means not enough building. ::