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