Two-Sided Marketplace Product Management: What’s Actually Different
A PM who joined a home-services marketplace straight from four years at a B2B SaaS company spent her first quarter doing what had always worked: she found the biggest drop-off in the funnel — a clunky provider onboarding flow — and fixed it. Signups from service providers roughly doubled. She presented it as a clear win. Three weeks later, the buyer-side team flagged that match quality had cratered: the flow she’d streamlined had removed a manual vetting step, and the marketplace was now full of providers who never showed up to jobs. Buyer retention dropped for the first time in the company’s history. She hadn’t done anything wrong by SaaS standards. She’d optimized a funnel. But a marketplace isn’t a funnel with two ends — it’s two interdependent populations, and a win on one side that damages trust on the other isn’t a win at all.
That’s the single biggest adjustment marketplace PMs have to make, and most of them make it the hard way, the way she did. Every other adjustment in this article follows from that one.
Why Marketplace PM Is a Different Job, Not a Harder Version of the Same One
In a single-sided product, your job is to make one population successful, and every metric points in roughly the same direction: more activation, more retention, more usage is good. In a marketplace, you have two populations with different, sometimes opposed incentives — supply wants higher prices and more demand; demand wants lower prices and more supply — and your product decisions constantly trade one side’s experience against the other’s. A feature that delights buyers by showing them more options can flood sellers with low-intent browsers who never convert, wasting their limited attention. A feature that protects sellers’ time by qualifying leads harder can make buyers feel like they’re being screened out.
This isn’t a matter of degree. It’s a different set of first-order questions. A SaaS PM asks “does this make the product better for our user.” A marketplace PM has to ask “does this make the product better for this side, and what does it cost the other side,” every single time, for every feature. Reforge’s guide to the cold-start problem frames this well: a marketplace needs to balance supply and demand to maintain a positive experience for both, and too much of either creates a bad experience for someone — too many sellers and most of them can’t sell anything; too many buyers and sellers get overwhelmed or start cherry-picking.
This asymmetry usually shows up in org design before it shows up in the roadmap. Most marketplaces eventually split into a supply-side team and a demand-side team, which raises the same question that comes up in any platform vs. feature team structure: who owns the shared infrastructure — search, ranking, trust and safety, pricing — that both sides depend on but neither side is incentivized to prioritize on its own. Marketplaces that leave this ownership ambiguous tend to under-invest in exactly the shared systems that determine liquidity, because each side-specific team is measured on its own side’s metrics and has no reason to fund work that primarily benefits the other side.
The Metric That Matters Most: Liquidity, Not Conversion
Liquidity is the probability that a participant who shows up will find a good match in a reasonable time. It’s the single most important number in marketplace product management, and it’s the one most PMs coming from other backgrounds don’t instinctively track, because it doesn’t exist as a concept outside marketplaces. Conversion rate tells you whether people who show up take an action. Liquidity tells you whether the marketplace is actually working as a marketplace.
The reason this matters practically: you can improve conversion on one side while liquidity gets worse overall, exactly like the onboarding example above. Provider signups went up — a conversion win — while the metric that actually determines whether the business works, match quality and completion rate, went down. Track liquidity by segment, not in aggregate. A marketplace can look liquid in the biggest city or category and be completely dead everywhere else, and aggregate numbers will hide that every time. This segment-level discipline matters even more when your two sides aren’t just different populations but different buyer types entirely — a B2B services marketplace often has consumer-like individuals on one side and procurement-driven businesses on the other, which stacks the usual enterprise vs. consumer tradeoffs on top of the ordinary supply-demand balancing act. SVPG’s writing on marketplace-style product scorecards makes a related point about critical mass: the appropriate metric focus depends entirely on what stage a given segment of the marketplace is in, not on a single company-wide number.
Managing Two Customers Who Don’t Trust Each Other Yet
Every feature decision in a marketplace product also has to solve a trust problem that doesn’t exist in single-sided products: two strangers, who have never done business together, need enough confidence in each other and in the platform to complete a transaction. First Round Review’s piece on how modern marketplaces build trust lays out the mechanics well — ratings, curation, and reducing anonymity aren’t nice-to-haves bolted onto a marketplace, they’re core product surface area, because trust is what converts liquidity into completed transactions.
Teams that treat trust and safety as a separate, lower-priority workstream — something to bolt on after growth — tend to end up rebuilding it under pressure after a bad-actor incident forces the issue. The teams that treat it as core product work from day one build it into onboarding, into search ranking (surfacing better-reviewed providers first), and into post-transaction flows (making it easy and expected to leave a review) instead of retrofitting it later. There’s a structural parallel here to API product management: both disciplines require designing for a “customer” who isn’t a single end user with a UI in front of them, and both punish teams who assume the standard single-user product playbook transfers unchanged.
Where Marketplace Products Break: The Cold Start and the Leakage Problem
Two failure modes are specific to marketplaces and worth naming individually, because each has a different fix and PMs coming from other backgrounds tend to conflate them.
The cold-start problem. A new marketplace, or a new segment of an existing one — a new city, a new category — has no supply on day one, so it can’t attract demand, and without demand it can’t attract supply. This isn’t solved by better product design alone; it’s solved by deliberately, temporarily unbalancing the marketplace to seed the harder-to-acquire side, then pulling back the subsidy once organic liquidity takes over. If you try to grow both sides evenly and simultaneously, you’ll usually get neither — new demand shows up to a thin marketplace, has a bad first experience, and doesn’t come back, which starves the supply side of the transactions that would have kept it engaged.
Leakage. Once a marketplace has facilitated a first successful match, the two parties often have everything they need to transact directly next time, cutting the platform — and its take rate — out entirely. This is the marketplace-specific version of churn, and it’s invisible in your platform’s own data, because by definition it happens off-platform. The fix isn’t just a terms-of-service ban on off-platform payment; it’s making the platform genuinely more valuable to keep transacting through than to leave — payment protection, dispute resolution, tax documentation, discovery of new matches — so leaving isn’t just against the rules, it’s a worse deal.
Pricing and Take Rate: The Lever Most PMs Get Wrong
Take rate — the percentage of each transaction the marketplace keeps — looks like a straightforward monetization lever, and PMs coming from subscription products often treat it that way: raise it, watch revenue per transaction go up, done. Writing an ordinary pricing strategy document for a single-sided SaaS product mostly means picking a value metric and a tier structure; a marketplace pricing document has to model second-order effects on the other side before it models revenue, because in a marketplace, raising the take rate too early or too aggressively directly damages liquidity — it raises the price for demand, lowers the payout for supply, or both, and either one pushes participants toward leakage or toward a competing marketplace with a lower take.
A disagreement plays out often on this exact point: growth wants to raise take rate to hit a revenue target, product argues that liquidity in several segments isn’t strong enough yet to absorb it without pushing transactions off-platform. The resolution that tends to work is segmenting the decision — protect take rate discipline in thin, still-liquidity-constrained segments (a new city, a new category) while testing increases only in the segments where liquidity is deep enough that participants have real switching costs and no easy off-platform alternative. A single company-wide take rate change treats a two-year-old category and a two-month-old one identically, which is exactly the kind of aggregate thinking that breaks marketplaces.
SaaS PM vs. Marketplace PM: What Actually Changes
| Dimension | SaaS Product Management | Marketplace Product Management |
|---|---|---|
| Primary user | One population | Two (or more) interdependent populations |
| North star metric | Activation / retention | Liquidity (match rate within a reasonable window) |
| Core risk | Feature doesn’t get adopted | One side’s win becomes the other side’s loss |
| Growth constraint | Awareness, activation funnel | Cold start, chicken-and-egg |
| Monetization risk | Pricing affects one buyer relationship | Take rate affects two relationships and can cause leakage |
| Trust requirement | Trust in the product | Trust in the product and in strangers on the other side |
A Worked Example: Fixing Liquidity Imbalance at a B2B Services Marketplace
A marketplace connecting small businesses with bookkeeping and accounting freelancers had strong overall GMV growth but a real problem hiding underneath it: liquidity in three of their five verticals had quietly collapsed to under 40% match rate within 48 hours, while two verticals — the ones the company had launched with — stayed healthy. Growth kept reporting company-wide numbers that looked fine, because the two healthy verticals had enough volume to mask the other three in aggregate.
The real constraint was headcount: a five-person product team couldn’t run five separate growth strategies for five verticals with a limited marketing budget. The team disagreed on the fix — one PM wanted to fix all five verticals in parallel with a smaller effort each; the lead PM argued for concentrating the entire subsidy budget on the single worst-performing vertical until it crossed a defined liquidity threshold, then moving to the next one. The concentrated approach won the argument because it mirrored what actually worked in the two healthy verticals at launch: they’d each gotten disproportionate, temporary attention before being left to run mostly on organic liquidity.
They subsidized freelancer payouts in the worst vertical for eight weeks, tied to a specific milestone — first 15 completed jobs — rather than a flat time-based subsidy, and paired it with a manually curated buyer waitlist that only opened as supply density crossed target thresholds by city. Match rate in that vertical went from 38% to 71% within the subsidy window, and — the number that mattered most to leadership — it held above 65% for the following two quarters after the subsidy ended, indicating the liquidity was organic and not purely subsidy-dependent. The team then moved the same playbook to the next-worst vertical.
How Do You Know When You’ve Actually Hit Liquidity?
There’s no universal number, and this is a place where marketplace PMs coming from other product backgrounds often want a clean benchmark that doesn’t exist — liquidity is segment- and category-specific, and what counts as sufficient depends on how tightly matched supply and demand need to be. A rough working test: a participant who shows up should find at least three to five reasonable options in their segment, and a match should complete within the time window that segment’s users consider normal — same-day for on-demand categories, within a week for considered-purchase categories like home renovation.
The more reliable signal isn’t a single snapshot number, it’s the trend after you stop subsidizing: if match rate and completion rate hold steady or keep improving once the artificial support is removed, you’ve built real liquidity. If they collapse back down, you’ve built a subsidy-dependent illusion of liquidity, and the underlying supply-demand balance was never actually fixed. This is the same discipline that separates a real product-led growth strategy from one propped up by unsustainable incentives — remove the crutch and see what’s actually standing on its own.
This week, if you’re running a marketplace product, pull match rate broken out by your smallest meaningful segment — city, category, price tier, whatever fragments your marketplace — not the company-wide aggregate. If even one segment is quietly failing under a healthy-looking company average, that’s where your product roadmap actually needs to go next, whether or not it’s where the loudest stakeholder pressure currently is.
References
- Reforge — “Beat the Cold Start Problem in a Marketplace” — https://www.reforge.com/guides/beat-the-cold-start-problem-in-a-marketplace
- Silicon Valley Product Group — “Product Scorecard Stages,” Marty Cagan — https://www.svpg.com/product-scorecard-stages/
- First Round Review — “How Modern Marketplaces Like Uber and Airbnb Build Trust to Hit Liquidity,” Anand Iyer — https://review.firstround.com/how-modern-marketplaces-like-uber-airbnb-build-trust-to-hit-liquidity/
