innovate big

explore needs first, tackle products later

User research and ethnography are nothing new, hot or sexy. From basic usability testing to in-depth market research, it has become a standard in one form or another in a variety of industries. Google does it, Procter & Gamble does it… everyone does it (and should continue to) but what is less common, particularly here in Silicon Valley, is a kind of ethnographic and needs research that supports the design of successful Internet products before they have been scoped out. Of course, this applies best to consumer Internet products rather than pure technology products.

Traditionally in the online world, research won’t come into play until *after* the product has already been scoped. You build it (or something close), test it and iterate accordingly. Even though this process appears on the surface to support, in some cases, successful consumer Internet products, I would argue the most successful consumer Internet products started with lean and simple objectives and *then* evolved as the “real” needs became clear over time (or when the users identified and adapted a completely different use for it: MySpace). I believe this can also apply to business models as well; start lean, simple and build around “real” needs accordingly.

What I am advocating here is a process that goes beyond product ideation and explores “real” needs in order to drive the design of consumer Internet products (not the other way around).

I think what Stan Shroeder describes as “the magic formula” is right on:

“Determine a basic need -> Create a service that satisfies it in the simplest way possible -> Open it up”

(Fred at A VC also discusses Stan’s perspective in an interesting related post about online group solutions)

But I would modify this magic formula slightly to read:

“Explore, research and understand a basic need/problem -> Create a service that satisfies it in the simplest way possible -> Open it up”

It’s not just about identifying or determining a “need” but understanding that “need”. How can you create a service that satisfies a “need” if you don’t really understand it? Of course, without proper execution, why even bother…