Mapping opportunities

After a few weeks of interviews and data, a team usually has more raw material than it knows what to do with. Mapping opportunities is how that material becomes a decision about what to work on next.

What counts as an opportunity

An opportunity is a need, pain point or desire, described from the customer’s point of view. It is not a solution. “I don’t know which of my invoices are overdue until a client complains” is an opportunity. “Add an overdue filter” is one possible solution to it.

The distinction matters because opportunities can be compared on their merits, while solutions tend to be compared on how much the person proposing them likes them. Keeping the two apart makes the conversation more honest.

A useful test: could a customer have said this sentence? If it mentions a screen, a button or a feature name, it is probably a solution in disguise.

Building the map

The structure I use most is Teresa Torres’s opportunity solution tree. At the top sits the outcome. Below it, the opportunities that, if addressed, would move that outcome. Below each opportunity, candidate solutions. Below each solution, the tests that would show whether it works.

The power of the tree is in the middle layer. Large opportunities can be broken into smaller ones:

• Getting paid takes too long
  • I don’t notice when an invoice is overdue
  • Chasing late payments is awkward and I put it off
  • Clients lose the invoice and ask for it again

The parent is too broad to act on. Each child is specific enough that a team could start generating solutions for it this week.

Build the map from your interview snapshots and other evidence, not from a brainstorm. Every opportunity should point back to something someone actually said or did. If it cannot, mark it as a guess.

Choosing where to focus

You cannot work on everything, and trying to compare every opportunity with every other one is exhausting. A tree helps here: compare siblings, the opportunities under the same parent, and pick one branch at a time.

Questions that help with the comparison:

• How many people does it affect, and how often? A daily irritation for most users beats an annual headache for a few.
• How much does it matter to them? Some pain points are mentioned in passing; others are why people are looking at alternatives.
• How well is it served today? If existing workarounds are good enough, the opportunity is smaller than it looks.
• Does it fit where the product is going? Solving a real problem for the wrong audience is still a distraction.

Rough answers are fine. The aim is a defensible choice, not a precise score. Elaborate scoring formulas mostly convert opinions into numbers that look more objective than they are.

Then, several solutions

Once an opportunity is chosen, generate at least three different ways of addressing it before getting attached to any of them. Different in kind, not three variations of the same screen. For the overdue invoices example: a reminder sent automatically to the client, a weekly summary for the user, a change to the invoice list that highlights anything late.

Comparing several options makes it far easier to see the strengths and weaknesses of each, and it protects against the most common discovery mistake: falling in love with the first idea and spending the rest of the process defending it.

The candidates that look promising move on to assumption testing.

Keep it alive

The map is not a document you finish. New interviews add opportunities or change how important existing ones seem. Shipped solutions should move the outcome, and when they do not, the map is where you go back to understand why. A map that has not changed for a couple of months usually means the team has stopped learning, not that it has learned everything.