This is the third article in the series. The first covered the ICP pre-screen, which decides which transcripts are allowed into the analysis at all. The second covered the phase map and the opportunity-analyst, which break a Job-to-be-Done into ordered moments in time and pull the opportunities out of every transcript. You can find and fork all skills on Github.
You’ve done a bunch of customer interviews and collected a wealth of opportunities (pain points, wants, needs) you could build a solution around. But which should you pursue first?
Most people go for the problem that’s been mentioned by most interviewees. Simple math, but poor outcome. After having chased after half-important problems far too many times, I’d rather solve a hair-on-fire problem shared by 5 people, than a “nice-to-have” shared by 20.
This article dives into clustering & sizing customer opportunities. The outcome: your #1 opportunity to ideate solutions to. I’ll explain my theory, my agent skills, and walk through a real life example: MyNewTechJob.
(Introduced in Article 2 of the series)
So this is where we left off. The opportunity-analyst has appended a section to the bottom of every transcript, listing the opportunities one person expressed, each one tagged to a phase.
What I do not have is a view across people: out of everything these six told me, which single opportunity matters most?
Two skills close that gap.
ICP Screener → Phase-Map-Analyst → Opportunity-Analyst → Opportunity-Clusterer → Opportunity-Sizer
The opportunity-clusterer deduplicates the opportunities across all six transcripts into one flat list, ordered like this:
Phase 1
Opportunity (e.g. “I wish I could filter for AI-native companies”)
interviewee 1 (+ exact quote)
interviewee 2 (+ exact quote)
etc
After having clustered the opportunities, we can size them to select the most interesting one to pursue. The opportunity-sizer handles this by scoring across prevalence and importance.
Once you have opportunities from multiple interviewees, you have to decide which statements are the same opportunity worded differently, and which are actually distinct. This is much harder than it looks, and getting it wrong breaks everything downstream.
Merge two opportunities that were actually distinct, and you misunderstand what your interviewees were saying. Split one opportunity into two, and you dilute the evidence behind each, so a real problem looks too small to act on.
There’s a lot of interpretation and reading between the lines here, which humans are both great (empathy!) and terrible (bias!) at. Non-surprisingly, AI doesn’t find it an easy task either. Two people can use completely different words for the same underlying need, and two people can use nearly identical words for needs that are not the same at all.
The thing that makes clustering easier is the phase map. Opportunities live in specific moments in time (I call these phases), and the same-sounding pain in two different moments is two different opportunities.
The video below scrolls through the artefact the opportunity-clusterer produced for the MyNewTechJob case. It’ss stored as a separate .md file in the folder with the transcripts.
The need to verify whether a company is truly AI-native came up over and over. On the surface it reads like one big opportunity. But in fact, it surfaced in four distinct phases (Define ideal role and company; Find roles; Execute interview; and Decide and negotiate). They share an underlying need, but the opportunities are distinct, and the product that would serve each one is different.
So the opportunity-clusterer skill never compares opportunities across phases. It runs one pass per phase, and each pass only ever sees the opportunities from its own phase.
Within a single phase, I ask myself: Could the team fix one person’s issue without touching the other’s? If yes, they are distinct.
The full set of rules is in the open-source skill if you want them.
Now I have the flat, phase-by-phase list of opportunities, each tagged with the people who raised it. One job left: pick the single opportunity to build a solution around first.
I’ve said it before, I’ll say it again: I’ve spent too much of my career building for problems that did not really matter. People would try the product once and go back to their old habits, because the pain was never big enough to make them change what they were already doing. I don’t want to build the thing twenty people nodded along to, and not one of them cares enough to switch.
Instead I weigh two things unequally. Prevalence is how many distinct people raised it. Importance is how much they actually care, on the 1 to 5 scale my interviewees gave me when I asked them to rate each pain during the interview (yes, ASK THEM!).
The simple rule I codified in the skill: do not chase an opportunity whose importance sits below 4, however many people raise it. It is better to get five people to truly love the product than twenty people to kind of like it and never use it.
Most prioritization frameworks blend scores like these into a single number and hand you a ranked list. I think that number hides the one thing you most need to see, which is the trade-off you are actually making. So instead of averaging, I look at the world through three lenses:
The most people: a peer community for senior machine-learning engineers in Germany between jobs. Three of six asked for it, but its importance is only a 3.
The deepest pain: a way to verify which companies have actually sponsored a visa before, not just claim they could. The one person living it said half his processes die at the visa step, and he would pay real money to avoid it.
The balance, and the one I would build: a way to check whether a company is genuinely AI-native before you waste an application on it. Two people, who rated it a 4 and a 5.
If you’re a Teresa Torres fan (as I am), you’ll know that the centerpiece is the Opportunity Solution Tree. Flat lists are bad, trees are good.
But my pipeline does not build that tree. The clusterer outputs a flat list (heresy!), and the sizer ranks the flat list directly. There was a version of the pipeline that tried to build the tree, and I removed it, because I could not get the AI to produce a tree I trusted. Tree-building is full of judgment calls, whether a generic opportunity is a true parent or just a vaguer duplicate of its child, whether two things are siblings or the same thing, and the AI produced structures that looked plausible and were painfully wrong.
So I accept a real limitation: a flat ranking will sometimes pick a different number one than a proper top-down tree would. I am fine with that, because of how I use the output, which is the last thing I want to say.
At the end of this pass I have one ranked list and a single recommended opportunity, backed by the exact people who raised it and their quotes. I do not treat it as a verdict. I treat it as a strong second opinion.
The human goes first, and the AI offers a different opinion to get me out of my own biased box. The sizer even writes down where its own recommendation might be wrong, and where its judgment calls could have gone the other way, and I read those notes before I commit. A machine that argues with me is worth far more than one that pretends to decide for me.
Once you’ve committed to a single number one opportunity, the work is to generate a spread of distinct solution ideas against it, rather than jumping at the first feature that comes to mind. Choosing the opportunity is where strategy happens. Choosing between solutions is the next discipline, and it is what the next article is about.
All skills are open source and forkable at https://github.com/Elsevanderberg1.
And yes, some stars would be nice <3
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.