Let's start with a basic question: what is a need? Since need is a human function expressed since the moment of birth, should it not be relatively simple to understand the need? Certainly, the world is full of humans and their needs, and so finding the needs should be a relatively straightforward proposition. But often, it's not, on many dimensions: distinguishing want from need, picking the need that make most sense to address from among the clamor, understanding what needs mean the most to which needers, and on, and on.
I prefer to think of needs as problems, and problems are often a function of a process gone wrong. So, what's a process? In the organizational world, "process people" are those who take a more structured, ordered approach to repeated execution of a sequence of steps. But that's just a symptom of one kind of process. Process is simply anything that takes an input, and transforms it into an output. Eating, cooking, talking, any and all sorts of actions that produce results -- and results are where you need to look for problems. Process for its own sake is called legislation -- if you love that stuff, go to law school or run for congress, marketing will probably give you only scarce joy.
It is in examining results and outcomes that one finds problems -- because a problem is the description of a result that fails to meet some expectation. Fresh pancakes for breakfast meets one need; time to prepare and clean up would be another need. I can make pancakes several ways, but if the result is that I have to wash the preparation dishes and it takes me an hour I don't have in the morning in getting my kids off to school, that's a problem:
"Making pancakes takes too long and makes to big a mess".
Time, skill, equipment, and neatness are the parameters of the expectation. The solution comes in a can.
For those of you have no inclination to market this type of nifty little item, the important insight in understanding the problem it solves is to identify the problem in terms of its parameters: time, skill, equipment, neatness. In other words, working backwards from a result, desired or undesired, to understand someone's problem -- and from there, how you might characterize -- or measure -- an improvement. Making pancakes more quickly, with fewer mistakes, equipment or cleanup: instant value proposition (doesn't come in a can, yet). In other words: a problem statement is the inverse of a value proposition.
Now, which of those problems matters most to whom? Only then can you know which value proposition will sell the best? The problem statement is useless without a keen understanding of whose problem you might be addressing. The best example I know of this is Google. The original problem, as identified by many among Google's predecessors (Altavista, anyone?), was
"Can't find stuff on the internet."
There were lots of products out there, now gone, solving this problem. Now, this problem statement can easily be expanded into some basic characteristics: time, skill, equipment, among others (these parameters recur in problem statements with great regularity). It's in driving improvements on these parameters that competition is most intense and relentless. What Google understood exceeding well was who needed the problem solved -- not just blokes and gals seeking stuff, but businesses trying to find out who was seeking stuff.
"Users can't find stuff on the internet."
"Businesses can't find users looking for their stuff."
And this is where they nailed it with all those zeros: by understanding who their customers were and how they fit together. The collosus of advertising and the collosus of search are now one and the same -- because they not only understood the problem, they understood whose problem it was.

No comments:
Post a Comment