Archive for May, 2007

How much Web 2.0 are you using?
May 29, 2007

If you’re trying to build a successful web service, it’s important that you understand that you aren’t just competing for users and attention, but also for the time it takes for a user to get interested enough in your product to return frequently. The truth is, for all the services and applications out there, even the most voracious computer user isn’t likely to rely on more then half a dozen different applications (at the most) on a regular basis.
For example, I am on a computer no fewer the eight hours a day. Rarely does a notable company launch a product without me being aware via the constant stream of news that I have at my disposal. I consume more e-dust in a day then most computer users do in a month. But when it comes to defining how many services I use regularly, and how much I am wedded to them, the list is small. Very small. Here is a list of online applications in the Web 2.0 space that I interact with….


  • GMail – Mail client
  • Netvibes – RSS management
  • PBWiki – Wiki for managing the staff I work with. I also maintain a couple pages as an online notepad for myself.
  • 30 Boxes – Calendar for managing the staff I work with.
  • WordPress – not necessarily Web 2.0, but it’s an online-only app I use for both work and fun.
  • Live365 – For listening to the radio at work.
  • Joost – I have a beta account and am looking forward to seeing how they unfold, so the grade is “incomplete” here.


  • YouTube – Perhaps twice a week I’ll end up watching a video from YouTube that was posted in a blog or received via email. I do not have a username and account.
  • Woot – When I have a second, I’ll scoot over to Woot to see what’s for sale. I keep meaning to add their feed to my Netvibes page. No username and account here either.
  • Google Search – Perhaps half a dozen times a week I’ll use Google to locate information. That said, I do not rely on it nearly as heavily as many folks and try to sign out of Gmail whenever I perform a search; the less iBigBrother knows, the better.
  • Wikipedia – I bypass Google all together and go to Wikipedia when I need facts or core information.

That’s about it. Aside from MyBlogLog, which I am always logged in to but passively use, I wouldn’t consider myself a person devoted to any service or application. The list is LONG of sites that I have signed up for, played around with, and never re-visited (Ning, Shopify, MySpace, LinkedIn, Remember the Milk, Sitekreator, etc). I was on the payroll of a somewhat popular local-review site / social network for a few months last year, but rarely return to visit. I’m a paid moderator of a sports-based message board, but I don’t really consider that as being a Web 2.0 application (even though it is based on user-generated content). And I visit Digg pretty regularly, although I have no desire to ever have an account and participate in the community.

After compiling the list above, I realize that no matter how much I stay aware of available products in the web-o-sphere, and no matter how much many of those products would help me in a practical way, the fact remains that I rely on very few of them. The applications I use daily are for (respectively) communicating, getting news, making announcements in the workplace, managing timelines in the workplace, blogging, and listening to music.

When I look at the list of logins and passwords I have to others sites, I see a common theme emerge: the sites I signed up for but do not use simply do not fill a daily need. While that sounds simple, it hits at the crux of what separates essential applications from interesting applications. Web based services and products that succeed and ultimately profit fill specific needs – the need to find information, the need to communicate and interact with others, the need to store information, etc. Applications that don’t fill a specific need won’t be around for long.

Is the lesson a bit redundant? Perhaps. But when you are dialing in the goal of your own projects, it is essential to your survival that you not only address a need, but that there be someone – a LOT of someones – on the other end of the pipe for whom that need is addressed.

The pool of potential users is virtually unlimited.  But their time, attention, and focus is extremely narrow.  If you have dreams of long term success and viability, it is essential that you make your product indispensable in their lives.


Rule # 14 – Impress your mother, not your friends
May 21, 2007

Techheads are an interesting lot. Despite protestations to the contrary, there is more ego in the programming/startup community then most anywhere else I’ve ventured. You’re as likely to see the Loch Ness Monster, Bigfoot, and a Unicorn playing Scrabble on a moon made from cheese as you are to find a software developer willing to admit, “I don’t know.” As a result, when folks start building products and companies and applications, they almost invariably head straight to the message boards and blogs looking for attention – get the approval of other super smart programmers, and you’re on your way!

TechCrunch, Mashable, digg, etc. There appears to be no prize with a higher value then getting a write-up on a validated Web 2.0 site. On the positive side, this attention will no doubt get a few thousand sets of eyes to click on the site and possibly sign up for and try the product. Yippee! Mission accomplished! The “Early Adopter” crowd is on board!

….and 3 months later, when another similar service comes along, or when you add payments to your service, the Early Adopter crowd you were so eager to impress will move on to the next Next Big Thing.

It boils down to this: the problem with people who understand the internet and understand software is that it is near impossible to turn them in to a sticky audience. They are interested in what’s new, not your aging product. They are interested in what’s getting attention TODAY on TechCrunch, not what was written about yesterday. And worst of all, the Early Adopter isn’t likely to pay for your service since there is likely a “free” option lurking somewhere on the web, and of all people, the Early Adopter will be able to find it.

So, who should you be building for and catering to? Mom. More specifically, “soccer moms” in the suburbs who spend less then an hour a day on the computer. These folks are seeking a solution that makes their days of carpooling, cooking dinner, balancing the family checkbook, and all the other hundreds of things that go in to being good at their jobs easier. They don’t have the time, and more importantly, the inclination to hop around looking for the “best” solution to their problem. They are simply looking for a solution that works. How else do you explain Hotmail and AOL continuing to sign up email accounts when Yahoo! and Gmail have tools and software that are far superior? With the “Mom” crowd, you don’t have to be the best. You simply have to be good enough and they will stay with you. Offer a solution that solves their immediate problem and you can bet they won’t leave your product for a competitor any time soon.

Even better, this audience is not averse to paying for a product that helps them. What’s $10 a month for an online tool that helps Mom and Dad know what child needs to be where and when? What’s $49 a year for a product that sends a report of all the websites accessed by Junior’s computer each week? What’s $30 a year for a place to upload photos and share them with friends? So on and so forth. Make a simple solution for a real-life problem and you’ll find an audience loyal to your application and rarely demanding of having the next big thing (Ajax, Flash, etc.) worked in to the product.

Quit trying to impress the programmer crowd. It’s a losing battle and aside from some short-lived instant gratification on the off-chance you can end up in the discussion, the only thing you’ll be left with after the Early Adopters come (and go) will be an abnormally high hosting bill. Instead, focus on the customer that is the easiest to find, the easiest to keep, and the easiest to extract money from: Mom.

Google Stole My Idea, but I’ll still do it better then they will
May 10, 2007

A week or so ago, Google launched a feature/product called “Google Web History.” In short, Google Web History saves all of your searches and with a simple download, it will also store all of the places you have gone on the internet. The goal is simple: have everywhere you have been on the web accessible to you just like you were searching for something new. Fair enough.

I actually began putting together the details of this very idea a month or so ago. My intention was to build this service because I needed it for personal use – there were tons of things I found on the web that I didn’t bookmark but would invariably want/need to find at a later date. I would be forced to try and retrace my steps and with a little luck, I could find the page. Sometimes I couldn’t, or the link would be broken, or the content would have been updated, or something would happen where I simply wasn’t able to get back to exactly where I wanted to be. Thus the idea for Motley Box was born.

I love mocking up logos, even though I’m a pretty bad designer and work my way around MS Paint and the GIMP like a 3rd grader.

(Something like…)

Motley Box logo

(Or maybe….)

Motley Box Logo 2

(Could be something like this, whatever…)

Motley Box Logo 3

Motley Box Logo 2

Motley: assortment: a collection containing a variety of sorts of things

Box: a (usually rectangular) container; may have a lid

While some people are leery of putting their ideas out for all to see, I am comforted by the fact that (1) virtually no one is reading this blog, so this is really more of a way for me to spell out what’s in my head about this issue and (2) on the off chance someone is reading this, maybe they’ll have some insight to offer me as I go forth with my under-dog role.


I was hoping to develop a plugin or cookie-system that would log everywhere an individual person had visited on the web, cache the page, and store it somewhere like Amazon S3. I was mildly disappointed when Google launched their service, until I dug a little deeper and came up with the following reasons why my service developed my way, doing essentially the same thing but approaching it differently, can still be a success.

1. I doubt Google is intending to put much muscle behind promoting this service outside of simply allowing it to exist. They simply have taken search/indexing technology that they already had and leveraged it in to a user application. The Google brand is strong and will no doubt bring in lots of signups, but that doesn’t mean the idea can’t be improved upon and the deployment be more effective.

2. I don’t think Google’s Web History feature is easy to use. My idea was to have a home page with a search box and/or a toolbar search-box plugin that linked to your history. Type in “pasta recipe” and the pasta recipes you have browsed in the past show up. That’s it. Google’s tool has a calendar, category filters, timestamps, and other bells and whistles. I think that’s overkill. Their product seems to focus on indexing your activity and making it look like an index. My idea is to make it super easy to find web pages you have visited before.

3. I don’t think Google is going to leverage the power of group behavior in to their product. Their leveraging is likely going to be to help Google serve more effective ads to the user(s). My idea will be to integrate a way to share your history across networks of friends, communities, and groups. By carefully building a system of weighing what sites and pages are actually useful, a new search engine can be built essentially from the browsing habits of individuals. This search engine can even be broken down in to parts – “microsearches” – where you can get search results that fit your taste by virtue of the fact that they reflect the taste of people LIKE you. Imagine a group of Web 2.0 junkies who join a “Web 2.0” group. The collective browsing of that group could shape what sites and tools are most useful and interesting to that specific group of people.  And if you didn’t know anything about a subject but were interested in learning, you could find folks who WERE experts and use their browser history as a jumping off point for what blogs and sites were keeping them up to date and informed on the chosen topic.

The relationship possibilities are endless.

4. I don’t think Google is going to realize the potential of this tool. From the word go, this system will bridge the gap between being forced to bookmark a site or risk not finding it later. I consume a lot of internet pages every day. I bookmark a few sites, tag a few pages that are super important, and let some things go for good knowing if I need them again I can hopefully find them later. This tool offers something in the middle: you don’t have to do anything active (like clicking to bookmark a page or posting to to save a site, but it can easily be found nonetheless.

So, it begins. I have become a quasi-victim of Google having the ability to develop and deploy anything they want in a much shorter time then a guy like me. That said, I think that there is opportunity – a LOT of opportunity – to beat Google by being simpler, more direct, and more focused on providing a product/application that provides awesome power to the user, not the ad-server. This will be my first attempt.

Rule # 13 – Underwhelm the masses.
May 9, 2007

You’ve certainly heard the expression, “Less is more.” That’s ridiculous. Less is less, which is a good thing. Less is an absence of clutter. Less is an absence of noise. Less is the ability to focus on making something specific really, really good. Less is the ability to make a fortress impenetrable, a wall un-scalable, a moat un-passable, because you aren’t wasting your resources trying to build a castle you’ll never visit a thousand miles away.

I can’t claim much credit for this Rule (37Signals puts it well in their previously mentioned “Getting Real” and it’s been discussed extensively in other places as well), but it’s worth writing out in my own way none the less.

There is a tendency in new products to try and be “feature rich,” particularly if you are building something for businesses to use. We’ve all done it. In fact, the time-to-launch for my biggest project yet was literally extended by years because we focused on squeezing in everything we could for the first release. Aside from the fact that getting something released in the first place and then adding to it is a much better strategy, there is a much more profound reason to leave features off of your product: no one will use a bloated application. No one.

The solution is to do less with your application, not more. What specific problem are you solving or what specific issue are you addressing? Got it? Now, build that well and quickly get out of the way. No one needs a buddy list that ties in to the their grocery list that syncs to their calendar and uses the Flickr API for pictures of groceries that converts to RSS. No one. However, buddy lists can be useful. Grocery lists can be useful. Calenders can be useful. RSS can be useful. Quit cross-breeding things just because you can.

I would be willing to wager that if you took a bloated application and launched it, and then took the core competency of the bloated product and launched it at a different, unrelated URL, you would find that the “feature rich” application was no more popular, no more highly trafficked, no more sticky, then the single feature application residing somewhere else. You’d also find that most of the extra features on the feature rich application were used by most users only a handful of times before they forgot about them entirely.

The point is that mashing things together to create more features will simply give your application more features no one will use and waste precious hours of your life that could be spent doing something more fun. You don’t see mechanical engineers wasting time building toilet paper holders that measure air temperature and monitor traffic reports, do you? So why should you be any different? Less is less, and let’s keep it that way.