For the past few posts I’ve been beating the drum on “finding and validating market problems.” Market discovery – to find problems worth solving – is the most important thing that product managers do if they want to make a lot of money.
I gave you an explanation of why it’s so important, a self-assessment, and I linked to a bunch of techniques you can use.
If you read those articles a set of themes starts to jump out:
You’re testing a hypothesis or generating ideas
You need either a hypothesis to test about a market, or an area or domain to investigate. For example, you might have a specific idea for a product. Or you want to try to discover what problems might be unsolved in a particular domain.
In my current job the domain is project management. I believe there are a lot of problems in project management still unsolved. Therefore, I talk to project managers and other people who work on projects to find unsolved problems. My initial research is to figure out where to focus in my next set of research. I’ll start with the hypothesis that “lots of problems in project management don’t have technical solutions yet.” If and when I discover some of those problems, my followup hypothesis will be “problem X of project management is a good candidate for a new technical solution.
You have to talk to a lot of people
To discover these problems, you will have a lot of conversations with people who are familiar with the domain, or working in the domain. There are two key points:
You’re looking for a “weak signal”
Often people won’t have a concrete sense of the problems they have. It might just be a frustration, or something they feel could be better. So you have to talk to a lot of people about their experiences in the domain.
People don’t necessarily know “their biggest problem”
You can’t simply ask your informants “what is your biggest problem?” The questioning has to be more oblique, otherwise you tend to “freeze” people. Ask them about their experience doing the job. Ask about what keeps them up at night. Or about recent challenges. Or when they have an “I suck” feeling in their job. Or, alternatively, what generates an “I rule!” feeling in their jobs, and how often that happens. They you can explore if there are ways to make more I Rule moments and fewer I Suck moments.
Get people talking with open-ended questions about their own experiences
From a technique standpoint, use open-ended questions (that don’t have Yes or No answers). And you can have a mix of provocative and “discovery” questions. Effective provocative questions get the person to think a little differently, to consider other options, to shift their point of view. For example, you might ask someone what features of Facebook should be applied to their domain. The whole tone of a discovery meeting can change in response to a question like that, when your informant says, “I’ve never considered that before,” or “I’ve never thought about that,” or “I didn’t realize that was possible,” or “No one has ever asked me that before.”
(Suffice it to say that the topic of using open questions and provocative questions to discover useful information in an interview needs its own series of blog posts!)
Once a signal starts bubbling up through the noise, you can go to the next phase
How do you know you’ve done enough interviews? You want to hear a lot of people coming up with the same problem. Ideally, people will say they’ve tried to solve this problem, but have been unsuccessful or not fully successful. Even better, they’ve budgeted some money to find a solution to this problem, but haven’t been successful in finding or buying a solution.
By the way, even if you think you already know the problem, and have an idea for a solution, don’t tell people about it at this stage. You’re really trying to find unsolved or badly solved problems, or validate that the problem you’re thinking about is actually important. You’re not pitching.
Use affinity mapping and similar techniques to discover the weak signal
If a problem doesn’t arise obviously from the interviews, you have to do some amplification. Go back through all your interviews (either via transcripts or detailed meeting notes), and pick out the “snippets” that seem to be interesting. You probably won’t find all of them the first time through, and many of the things that might be interesting won’t turn into anything useful in the end, after analysis, but do your best. This also works well collaboratively, because different people will come away with different snippets from the same conversation or notes.
Take all these snippets, from all your conversations, and analyze them. A good way is to use “affinity mapping.” Put the snippets onto post-it notes, or onto a virtual post-it note system, and try to find snippets that go together. Your goal is to tease out a weak signal from everything you’ve heard, and then use affinity mapping to amplify the signal.
For example, in an earlier life I interviewed a lot of product managers about a product idea I had. The product idea didn’t turn out to solve a big enough problem, so I abandoned it. But in the course of these interviews I heard something surprising multiple times – “I go to LinkedIn to find out how to do product management.” This shocked and surprised me – LinkedIn is a place to find out how to do product management? I never would have guessed that, and in fact, the first time I heard it I kind of ignored it. But then, when I heard it again, I realized it might reveal a problem I hadn’t discovered before, or at least a solution that a number of people were trying and which I might be able to either leverage or improve upon.
Will they pay for a solution?
Finding a problem is merely step one. The next step is to make sure there is a market for a solution. We’ll talk about that more in the future.