Technology First vs. Needs First

There’s a debate that’s been going on in the design and user research community because the legendary Don Norman wrote an essay in which he did an about-face and decided that doing user research to start a project was mostly a waste of time.

That’s an oversimplification – he actually was only talking about those seeking the big, society changing innovations like the airplane, the telephone, and indoor plumbing.  He argues that in each of these cases, first the underlying technology had to be invented, and then only later did we discover uses for it.  So his point (and title of his essay) is – technology first, needs last (see http://www.jnd.org/dn.mss/technology_first_needs_last.html).

In part I think he’s trying to shake up those in the design community that advocate a very dogmatic approach of first doing weeks or even months of research to determine needs (e.g. ethnographic research, market research, user research), and only later come up with the technology to deliver on these needs.  I’ve also known many of these people that believe this is how innovation is supposed to happen.

Unfortunately, while I think there is an important truth to Norman’s observations, I think his conclusions have confused a lot of people.

I’d like to use this debate to try to underscore what I think is a fallacy of those that believe needs come first, and those that believe technology comes first.

In fairness, for typical, incremental innovations like improving the effectiveness of a web site, Norman thinks that observing users and determining their issues first and then using those learnings to drive technical solutions is great, and I would argue that covers the majority of what most of us do in product.  Not many of us have had the chance to work on something that radically changes society.

However, for most interesting innovations, it’s not that technology comes first and then needs second, and it’s also not that the needs come first and then technology second.  Rather, it really is a collaborative and parallel effort between product, design and engineering to come up with solutions that are both possible/feasible and useful/valuable.

When Fred Smith innovated to create what would become FedEx, it was a beautiful blend of combining a long-standing need (getting a parcel from anywhere to anywhere overnight) with a solution that was just now possible – a fleet of jets using a hub and spoke system and some impressive logistics software and hardware.

When the TiVo team innovated with the DVR, it was a beautiful blend of a long-standing need (recording was such a pain with video tapes and we hated being forced to watch commercials) with a solution that was just now possible – a low-cost Linux-based appliance with a very large hard disk and some very impressive video management software.

Apple is full of examples of just such elegant combinations of technology and need, and the iPad is just the latest.

Are FedEx, TiVo and the iPad as fundamental to society as the invention of the airplane or indoor plumbing?  Maybe not.  But are they non-incremental innovations that have had a profound impact on their respective businesses and their customers?  Absolutely.  And in every case this wasn’t just pure technology research hoping to one day be useful.  Rather, they were all innovations built on the back of hundreds of other innovations, but without question driven by the desire to solve specific hard problems addressing real needs.

Now, I think the value of Norman’s argument is that none of these innovations required months of formal market research or ethnographic research in order to understand the user or market needs.  No, the real challenge was in coming up with solutions that were feasible and usable.  The need wasn’t the issue.

Norman’s argument is similar to the argument against Waterfall or marketing-driven products.  Spending a bunch of time up front defining the problem sounds logical but isn’t the way innovation works.  And of course we learned a long time ago that you can’t get the solutions from the customer because they don’t know what’s possible.

So while I agree with Normal that spending a lot of time up front is not time well spent, I do believe there is value in framing the need or problem to be solved, as this often opens your mind up to alternative approaches to solving the problem.  But I argue for a very quick problem definition statement (e.g. an opportunity assessment).

But I think the deeper issue here is that this overly simplistic view of “technology first” or “needs first” obscures the real dynamic of what happens during product discovery.

I would argue that it’s not very hard to start with a clear need, but product discovery is really about trying to find a solution that addresses that need (it’s valuable), is usable and feasible.  Product discovery can have lots of outcomes:

– Sometimes we validate that this need is real and users are hungry for a solution, but sadly the solution isn’t yet technically feasible – either because of missing or immature core technology, or because of cost (development time or investment required), or because of performance.  I never like to give up too quickly on feasibility because so often I’ve been surprised by what the engineers can solve when you include them in the discovery process, and give them a little time to think about it and try out different approaches.

– Sometimes we find that users are not nearly as concerned about the need as we were, and it’s really not such a great product idea after all.   Or a variation of this is that we discover that there are reasons behind the current solution and they are motivated to resist changing to a better solution.  Happens way more often than we like to admit.

– Sometimes the need is real and the technology is feasible, but the solution is just so complicated or foreign that users can’t figure it out, or are unwilling to invest the time to learn.

– Sometimes the very act of putting your ideas in front of users and letting them play with it (and open their eyes to what’s possible) opens up new possibilities, occasionally even more powerful than your original concept.  We call that a “pivot,” and it’s one of my favorite surprise outcomes of product discovery.

– Most of the time, however, once we put our ideas in front of users, and we can see which aspects of their needs are addressed well and which aren’t, it provides us with the insights and understanding we need to refine our solution, sometimes in minor ways and sometimes in significant ways, but we iterate and zero in on a good solution – one that is valuable, usable and feasible.

It’s not always pretty, and it’s not always predictable, but one way or the other, you’re combining a real need with something that’s technically possible.

I think the lessons to be learned from this debate include not only Norman’s point of not going overboard on user or market research before you start considering feasibility, but also on the importance of viewing innovation as a true collaboration between product, design and technology where we strive to discover solutions that are valuable, usable and feasible.