The reason designers tend to make good startup founders is because of the way they think. Designers are trained (through education or experience) to be creative problem solvers. — In Defense of the Designer fund written by Matt KumpI worry about describing designers as "creative problem solvers" - that isn't a defining characteristic. I know plenty of business folks and engineers and whoever else who are all creative problem solvers. It's a general life skill, to solve problems, and I'm not entirely sure that word "creative" isn't redundant. I'd argue that designers' real strength lies in being "creative problem finders." What I mean is, designers have a process for finding, understanding and defining problems to solve. Finding problems isn't easy. I'm not going to talk about what makes a great problem to solve, as I think that could make up a whole post in itself and is highly personal, but I will say that the criteria is usually broad and unspecific. I'd also point out that although I use the word "problems" throughout this post, many "problems" products solve these days are actually more akin to user's needs and wants. Anyways, there's a lot of uncertainty in this process - and it's quite different from the uncertainty involved in building a product. It's uncertain not because you don't know what the answer to a question is, it's uncertain because you don't know what the damn question is in the first place. So as founders, you've got to have a certain amount of faith that the problem you've set out to solve is a good one. How do you develop confidence in your question? This is where it gets tricky. Previously, your "question" may have been somewhat simple and something that was clearly identifiable: "Users need to be able to find information easily and quickly" (Google), or, "Users need to be able to buy goods online easily, cheaply and quickly" (Amazon). But products these days seem to have gotten infinitely more complex but also more subtle about the kinds of questions they're focusing on. I am reminded of Horst Rittel and Melvin Webber's definition of a "wicked problem," of which the first statement is as follows:
There is no definitive formulation of a wicked problem (defining wicked problems is itself a wicked problem).
The idea here is that part of the challenge with "wicked problems" is that they are difficult to understand, define and describe in and of themselves. I think this is an interesting hypothesis to apply to the current generation of Internet products. Companies like DropBox, for example, solve a very simple, accessible problem: People need to back up their data in the cloud so that they can access it from multiple devices. But what about a company like Pinterest, Path or Tumblr? What "problem," exactly, are they solving? How would you state that problem? They're sort of these multivariate social problems, where you can't quite describe it succinctly because it has to do with so many people and their interacting needs and wants. These designs are less about individuals, but more about designing entire social systems that fulfill the needs of individual users. Problem definition comes in understanding the major motivators and constraints and their ramifications on the others.
But, unlike numbers, you can't just sum it up in a nice little algebraic formula, or a nice little question or statement. Social means that you are dealing with two or more people, which means every social problem is inherently multivariate. That means you need to understand the different people involved before you can design for the spaces (the interactions) between them. Which means you have to start trying to understand individual pieces of these problems before you can have any idea what your final product may look like. This scares the shit out of people who aren't comfortable with it - being able to step forwards when you don't know where you are is completely different than being able to stand still when you don't know where you are.
This requires a certain intuition. You pick your theme and then you have to go about following your intuition to the juicy bits. When I started original research around Teethie, all I knew was that communities on the internet were awesome and I wanted to make them better, and then I got around to finding out that they could be so, so much better. It's also what makes needfinding so delicious - so often, people are like riddles, they want to tell you something but you nor they know what it is, so you've got to develop an intuition for listening between the lines. And when you discover that there is something between those lines, it becomes intoxicating - the world is full of secrets (in plain sight). Putting together all these datapoints requires intuition, too. There's pattern matching that happens subconsciously that you have to let go forward before you even understand what it is you see. You are detecting from this jumble of nuggets and insights what exactly impacts these larger systems - if you knew what creates impact before, you wouldn't need to attempt to understand all of this.
I think, when it came to the first generation of web products, there was a certain process that worked alright: most people were building tools and utilities for singular people. So, for example, the first generation of blogging products realized bloggers wanted to publish content online, and so allowed them to do that. But this next generation of blogging products - the inherently social products like Tumblr - realized that bloggers wanted an audience. And so, they built tools into their system that benefited readers and bloggers both. But in order to do that, they had to understand what bloggers wanted from blogging, and what readers wanted from consumption, and match these things with a design. You have to understand as many of these minute details that make up an overarching, larger phenomenon as you can, and then you have to formulate all of those details into a cohesive approach, to which you design a solution, and then you've got to break it all up again to design the details.
"I am awaiting the day when people remember the fact that discovery does not work by deciding what you want and then discovering it." — David Mermin