Why are you building this next? It is the most useful question anyone can ask a founder, and the hardest one to answer well. I have answered it badly more than once. I have shipped features because a stakeholder was loud, because a competitor had launched something similar, and because the idea was exciting on a Tuesday afternoon. Some of those features got used. Several did not, and I could not have told you beforehand which would be which.
Opportunity mapping is the habit that fixed that for us. It is not a framework you buy or a tool you install. It is a short, repeatable way of writing down a problem, the evidence that it exists, who it affects, and what you expect to change if you solve it, before anyone designs anything. Then, crucially, going back afterwards to check.
Marketplaces make this harder than it is for most products, because there are two sides with two different sets of problems, and the only problems that really matter are the ones that stop a transaction from happening. This post covers the version we use with marketplace founders: how to map each side, how to find the opportunities that sit where both sides meet, and how to pick the one worth building first.
What Opportunity Mapping Is
An opportunity is an unmet need, a pain point, or a desire that a real user has. A feature is one possible way to address it. Opportunity mapping keeps those two things separate for long enough to choose well. You collect the opportunities, size them, and only then argue about solutions.
The best-known version of this idea is the opportunity solution tree, described by product coach Teresa Torres in her book Continuous Discovery Habits. It starts from a single desired outcome, branches into the opportunities that could drive it, and only then into candidate solutions and the experiments that test them. If you have never used it, it is worth reading in full.
What we use day to day is a hybrid. There is no single correct process for every team, because the right amount of structure depends on your stage, the size of your team, and how much the founders already trust the product function. A two-person founding team needs something they can fill in in twenty minutes. A product team defending a roadmap to a board needs something with more evidence attached. The card below scales to both.
The Opportunity Card
Every opportunity gets one card. Nine fields, written in plain language, before any design work starts. The last three are filled in after release.
| Field | What goes in it |
|---|---|
| The problem | One sentence describing what users experience, not what you want to build |
| Problem size | How many people hit it, over what period |
| Supporting evidence | The numbers, recordings, or conversations behind the claim |
| Affected users | Which side, which segment, at which step |
| The hunch | Your hypothesis for why it happens and what would fix it |
| Expected benefit | The metric you expect to move, and roughly by how much |
| Did it solve it? | Filled in after release, against the same metric |
| New evidence | The post-release numbers |
| What we learned | Including what surprised you and what you now suspect |
The first six fields turn a feature request into a testable bet. The last three turn the bet into learning. Most teams do something like the first half informally. Very few go back and complete the second half, and that is where most of the value is, because it is the only part that makes your next estimate better than your last one.
Here is one we filled in on our own site. Over a ninety-day window, 804 visitors stayed past the first page. Of those, 57 started creating an account, about 7 percent. Only 8 finished their profile, about 14 percent of the people who started. Looking at the funnel, most of the drop-off happened on the third of four signup pages. The hunch was that four pages asked for too much effort too early, and that collecting the same information in three pages would lift completion.
Shortening the flow did help. The more useful line on the card was the last one: the drop-off also suggested our entry pages were not explaining enough value for a stranger to want to invest the time at all. That became the next card. Without the follow-up field, we would have shipped the shorter form, declared victory, and missed the bigger problem sitting one step earlier.
Why Marketplaces Need Two Maps
On a single-sided product, every user wants roughly the same outcome. On a marketplace, buyers and sellers want different, sometimes opposing things. Buyers want choice, speed, and low prices. Sellers want demand, predictability, and good margins. A change that delights one side can quietly cost the other.
That is why we map each side separately first. Put buyer opportunities on one board and supplier opportunities on another, using the same card for each. Write them from that side's point of view. “I cannot tell whether this provider is available next week” is a buyer opportunity. “I do not find out about a booking until the day before” is a supplier opportunity. They may turn out to be two ends of the same problem, but you only see that once both are written down.
Find Where Both Sides Meet
Once both maps exist, lay them next to each other and look for the overlap. The opportunities that matter most on a marketplace sit at the moment of transaction: the point where a buyer and a seller need to find each other, trust each other, agree, and complete. A pain that blocks that moment for either side blocks it for both.
A simple way to see this is to walk through a single transaction step by step, from search to repeat purchase, and pin each card to the step where it happens. Our journey mapping template is built for exactly this. You will usually find that the cards cluster. A few steps collect pain from both sides, and those are your strongest candidates.
Take a hypothetical marketplace for booking freelance photographers. On the buyer map there is a card about not knowing what a shoot will cost until after a back-and-forth. On the photographer map there is a card about wasting time quoting jobs that never book. Separately, each looks like a modest improvement. Together, they point at the same step, the quote, and at one opportunity: making price visible earlier. That single change would serve both sides at once, and it sits right on the path to a completed booking.
“On a marketplace, the opportunity worth building first is usually the one both sides complain about from opposite ends.”Darren Cody, Marketplace Studio
Size Opportunities By Frequency And Pain
You will have more opportunities than you can address. Sizing is how you choose without defaulting to whoever argues best. Two questions do most of the work. How often does this happen? And how much does it hurt when it does?
Frequency is usually measurable: how many searches, bookings, or signups hit this step in a typical month. Pain is harder. The most honest signal is behaviour. Does the user abandon, work around the platform, contact support, or take the transaction elsewhere? A problem that causes people to leave is more painful than one that causes them to grumble and continue.
| Frequency | Low pain | High pain |
|---|---|---|
| High | Polish later, batch with similar fixes | Build first |
| Low | Leave it | Watch it, fix when it grows or affects key users |
On a marketplace, add a third question: which side is constrained right now? Early on, one side is almost always harder to get and keep than the other. An opportunity that helps the constrained side is worth more than an equally sized one on the side you already have plenty of, because it unlocks transactions that the other side is already waiting for.
Pick The Wedge
The output of all this is a short list, not a roadmap. Pick the one opportunity that is frequent, painful, close to the transaction, and on the constrained side. That is your wedge: the single problem you solve so well that people choose your marketplace over the alternative they use today.
For a founder who has not built yet, the wedge is the heart of the first version. Everything else on the map can wait, and writing it down is how you make peace with that. For a live marketplace, the wedge is the next epic, and the card is the answer to “why are you building this next?” that you can forward to a co-founder, an investor, or a developer.
Close The Loop
The part of opportunity mapping that is easiest to skip is going back. Release day is busy, the next card is already waiting, and the original estimate is a little embarrassing to revisit. I understand the pull. But a card without its follow-up is just a well-written feature request.
Set a date, usually sixty to ninety days after release, and fill in the last three fields against the same metric you named in the expected benefit. Some bets will land. Some will not, and those are often the more useful ones, because they tell you something about your users that you did not know. Over a few cycles, the cards become a record of how your marketplace actually behaves, and your hunches get noticeably sharper.
If you are at the idea stage, opportunity mapping pairs naturally with validating your marketplace idea before you build: validation tells you the problem is real, and the map tells you which part of it to solve first. It is also a core part of our pre-development work, where we map both sides with founders before a single screen gets designed. It is the cheapest point in the whole journey to find out which problem is worth your budget.
