You understand that Nothing Important Happens In The Office. For the past six months, you’ve been vigilant about finding time and funding to get out. You’ve diligently recorded your observations. You’re proud of your rapidly improved ability to avoid leading the conversation. It seems instinctual at this point to recognize the most obvious trend – and you know that’s not enough. First, you’re going to need to support that assertion with market facts. Second, you need to find out if there are other sub-trends that you should pay attention to in this release cycle.

You know that the data you need is there – you have been responsible with your call reports, recording the information right after the interview ends. You’ve gathered relevant analyst reports (even though you’re taking them with a grain of salt). Customer Support will present the enhancement request analysis to you next week. Oh, and there are two sets of competitive analysis to consider, as well.

The good news is that the answers are there. The bad news? Somehow, you need to figure out how to divine the truth from the avalanche of market evidence you’re surrounded with.

This really involves two primary actions – clustering and prioritizing.

Clustering involves grouping market inputs into common themes, and articulating an accurate and descriptive market problem to describe the commonality.

Discovering the market problems buried in the evidence takes a bit of practice to master. We can organize the inputs in a number of different ways – but nothing can replace the human analysis that turns raw evidence into compelling market problems. In order to do this well, we have to make a shift from feature-think to problem-think.

If you’ve attended Practical Product Management, you may remember this clustering technique. We call it affinity mapping, and use it during positioning.

Let’s say that we talk to one customer who tells us that they produce reports for three other departments. All 3 departments need a different report, with slightly different data. They all need them once a week, but they each request a different delivery day.

Right now, your product will allow her to produce all of that….so what’s the problem?

You browse through the rest of the call report, and notice that this customer said they have a toddler at home, and she’s trying to balance that and her career. Later, she noted that she’s producing twice as many reports as she was at this time last year.

Hmmm…..her responsibilities are increasing, and she’d rather be at home. Could it be that her problem is “reports take too long to produce, even when they are nearly identical?” and perhaps, “reports have to be manually produced, even when their delivery time is known ahead of time”?

One test of a problem statement is to imagine that you could run an entire launch centered around solving that problem. Would it be exciting? Would you feel good about telling your best customers that you solved that problem?

Now remember – you won’t solve every problem you discover. That will be determined by priority, resources, and elapsed time. However, you should attempt to make every single problem statement compelling. Try to write it in a way that makes you want to solve it. Then, prioritize it and act accordingly.

As you move through your market inputs, add evidence to existing problems – or create new problems, if the evidence supports it. As you write these, it will get easier and easier to write compelling statements, and to remember existing statements as you review additional evidence.

Clustering does take some practice – and it’s absolutely essential to accurately planning a release. First cluster, then prioritize.

Prioritizing is when we assign an indicator to the market problem, to describe its relative urgency and importance. It sounds pretty simple, doesn’t it? And thankfully, sometimes it really is. Usually, though, prioritization is a complex problem of our own! Think of all the things that can affect priority:

• You might have a contractual obligation to fulfill. These contractual commitments are usually bad for reasons that would take another article to explain – for our purpose here, it will suffice to say that these are generally the top priority as soon as they occur.
• What is the strategic direction of the company? We have to consider overall goals, and somehow account for their relative importance.
• How important are the needs of existing customers? Do you have renewal revenue to maintain, or do you need to focus more heavily on new license revenue?
• How difficult is this to solve? I know that we want to say “this is the most important market problem, solve it first”….but sometimes, reality dictates that we break that up into smaller chunks, or delay solving it because we just don’t have time or the right resources. Some people will say this is feasibility; I disagree. Engineers are generally brilliant folks who can solve nearly anything, given enough time. We don’t always have enough time.
• How important is the competition to our priorities? Is there pressure to follow the competition, or are we free to explore opportunities to leapfrog them?
• Does our management want to cater to the analysts? We have the reports – how intently do we listen to them?
• And of course, we also want to consider frequency – how many times have we heard this particular problem?

Before we can accurately prioritize, we ought to consider these factors – because if we’re not clear on our criteria for prioritization, we’re apt to become lost in it.

Armed with our criteria, we can go through the market problems and actually assign a priority. As you create the problem statements, I suggest that you assign each one a rough indicator – I still like to use high, medium, and low on the first pass. They’re reasonably vague, so we can assign one without getting too lost in the details. Since we’re collecting market data all the time, this indicator is focused purely on the market need, without regard for product or release cycle.

After the first pass,those items with a “high” indicator will be your top priorities. When it’s time to create the Market Requirements Document (MRD), these are likely to be included. Sometime before the MRD is deemed “final”, we need to do a second pass for priority, as well. During this pass, we should consider relative important for this particular release. Our output will be a numbered list, 1 through N, describing the exact priority of each market problem.

All the market evidence in the world won’t help us if we can’t tease out market problems, and prioritize them appropriately. After the evidence has been collected, take the time to cluster the inputs, write good problem statements, and get clear on priorities. The expert guidance you provide through clustering and prioritizing will help your team create products that delight users and sell themselves.

Stacey Weber is a consultant at Pragmatic Marketing. She has more than 7 years of experience in software product management. During that time, she developed a focused interest in the improvement of requirements gathering, analysis, and review. She has led efforts to increase market focus, improve roadmap planning, and increase the effectiveness of requirement reviews with development teams. Contact Stacey.