marketplace-liquidity

Diagnose and improve marketplace liquidity (match rate/fill rate, time-to-match, reliability) by segment. Produces a Marketplace Liquidity Management Pack: liquidity definition + metric tree, fragmentation map, segment scorecard, supply/demand bottleneck diagnosis, experiment backlog, measurement plan, and operating cadence. Use for Growth teams running two-sided marketplaces. Category: Growth.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "marketplace-liquidity" with this command: npx skills add liqiongyu/lenny_skills_plus/liqiongyu-lenny-skills-plus-marketplace-liquidity

Marketplace Liquidity Management

Scope

Covers

  • Defining liquidity as reliability: how often a user can complete the marketplace’s core action (find → match → transact) within an acceptable time and quality threshold
  • Measuring liquidity where it actually happens (by “local markets” like geo × category × time window), not just in global averages
  • Diagnosing liquidity failure modes: fragmentation, supply–demand imbalance (“flip-flop”), matching/mechanics issues, and quality/trust breakdowns
  • Designing a practical liquidity operating system: scorecards, weekly review cadence, and a “whac-a-mole” rebalancing plan (move attention/inventory/incentives)
  • Producing an actionable experiment backlog to improve liquidity (supply, demand, matching, pricing/incentives, trust & safety)

When to use

  • “We need to improve marketplace liquidity / match rate / fill rate”
  • “Time-to-match is too slow” / “buyers can’t find availability”
  • “Supply and demand are imbalanced across cities/categories”
  • “Our marketplace feels unreliable” / “conversion drops due to no availability”
  • “We need a liquidity dashboard + operating cadence + experiments”

When NOT to use

  • You don’t operate a two-sided marketplace (no matching between supply and demand).
  • The primary problem is value proposition / ICP (use problem-definition or measuring-product-market-fit).
  • You only need pricing changes (use a pricing strategy skill) without a liquidity diagnosis.
  • You need a general growth plan unrelated to matching reliability (use designing-growth-loops / retention-engagement).

Inputs

Minimum required

  • Marketplace type + sides (who are “buyers” and “sellers”)
  • The core action you consider a successful outcome (e.g., request → booked; search → purchase; message → hire)
  • Top 1–3 priority segments (geo/category/user cohort) and the time window you care about
  • Best-available baseline metrics (even if rough): demand volume, supply availability, match/fill rate, time-to-match, cancellations/quality
  • Constraints: budget, incentives you can/can’t use, policy/brand/trust, engineering capacity, timebox

Missing-info strategy

  • Ask up to 5 questions from references/INTAKE.md, then proceed.
  • If data is missing, proceed with explicit assumptions and label confidence.
  • Do not request secrets or PII; prefer aggregated metrics or redacted examples.

Outputs (deliverables)

Produce a Marketplace Liquidity Management Pack (Markdown in-chat; or as files if requested) containing:

  1. Context snapshot (goal, timebox, segments, constraints, decision this informs)
  2. Liquidity definition + thresholds (reliability definition and “good enough” targets)
  3. Liquidity metric tree (north-star + driver metrics, with event definitions)
  4. Fragmentation map + segment scorecard (where liquidity is weak/strong; the “local markets” that matter)
  5. Bottleneck diagnosis (supply vs demand vs matching/mechanics vs quality; include “flip-flop” state)
  6. Intervention plan + prioritized experiment backlog (including reallocation/“whac-a-mole” plan)
  7. Measurement + instrumentation plan (dashboards, alerts, tracking gaps)
  8. Operating cadence (weekly liquidity review agenda + owners)
  9. Risks / Open questions / Next steps (always included)

Templates and expanded guidance:

Workflow (7 steps)

1) Intake + define the decision and local market(s)

  • Inputs: User context; references/INTAKE.md.
  • Actions: Clarify the goal (metric + target + by when), define the core action, pick the “local market” unit (e.g., city × category × week), and decide the decision this work will inform (what you’ll do differently).
  • Outputs: Context snapshot + local market definition.
  • Checks: A stakeholder can answer: “Which segment(s) improve by how much, by when, and what will we change based on the result?”

2) Define liquidity as reliability + set thresholds

  • Inputs: Core action, time sensitivity, quality constraints (cancellations, refunds, etc.).
  • Actions: Define liquidity as the probability of success within thresholds (time-to-match, quality). Choose 1 north-star liquidity metric and 3–6 drivers (fill rate/match rate, time-to-match, availability, acceptance, cancellation).
  • Outputs: Liquidity definition + “good enough” targets + metric tree outline.
  • Checks: The definition is measurable, segmentable, and aligned to the user’s experience (“reliability”).

3) Build a segment scorecard + diagnose fragmentation

  • Inputs: Baseline data by geo/category/time window (best available).
  • Actions: Create a segment scorecard for each local market: demand, supply, matching, and quality metrics. Identify fragmentation (thin markets, long tail categories, uneven geo distribution) and “uniform needs” vs heterogeneous needs.
  • Outputs: Fragmentation map + ranked list of worst segments (where liquidity blocks growth).
  • Checks: The scorecard avoids global averages and includes enough volume to be meaningful (or flags low-confidence segments).

4) Diagnose bottlenecks (flip-flop + mechanics + quality)

  • Inputs: Segment scorecard; any qualitative evidence (support tickets, user feedback, ops notes).
  • Actions: For each priority segment, label the primary failure mode:
    • Supply-limited (not enough availability/inventory)
    • Demand-limited (not enough intent/requests)
    • Matching/mechanics-limited (ranking, discovery, response time, pricing friction)
    • Quality/trust-limited (cancellations, no-shows, fraud, low ratings) Also check for the “flip-flop” dynamic (which side is currently the constraint) and the graduation problem (top suppliers leaving).
  • Outputs: Bottleneck diagnosis per segment + evidence notes.
  • Checks: Each diagnosis includes at least 1 metric signal and 1 plausible causal story you can test.

5) Generate interventions + experiment backlog (including reallocation)

  • Inputs: Bottleneck diagnosis; constraints; available levers.
  • Actions: Create intervention options for each bottleneck type (supply, demand, mechanics, quality). Include a “whac-a-mole” plan: how you will reallocate attention/inventory/incentives across segments weekly. Convert interventions into experiments with clear hypotheses and success metrics.
  • Outputs: Prioritized experiment backlog + reallocation playbook.
  • Checks: Every experiment has (a) a segment, (b) a primary metric, (c) a target effect size or directional expectation, and (d) a plausible cycle time.

6) Design measurement + liquidity operating cadence

  • Inputs: Chosen metrics and experiments.
  • Actions: Specify dashboards/alerts, event definitions, and instrumentation gaps. Create a weekly liquidity review agenda and decision log (what gets rebalanced, what gets shut down, what gets scaled).
  • Outputs: Measurement plan + operating cadence (owners if known).
  • Checks: Each key metric is tied to a data source and update frequency; the cadence produces concrete decisions, not status updates.

7) Quality gate + finalize the pack

  • Inputs: Draft pack; references/CHECKLISTS.md and references/RUBRIC.md.
  • Actions: Run the checklist and score with the rubric. Tighten the pack until it is specific, segment-aware, and testable. Always include Risks / Open questions / Next steps.
  • Outputs: Final Marketplace Liquidity Management Pack.
  • Checks: The next 2 weeks of work are unblocked (data pulls, 1–3 experiments, cadence).

Quality gate (required)

Examples

Example 1 (services marketplace, geo fragmentation):
“Use marketplace-liquidity. We run a home cleaning marketplace across 12 cities. Goal: increase booking fill rate from 62% → 80% in 8 weeks in our bottom 4 cities. We suspect supply is thin and response times are slow. Output a Marketplace Liquidity Management Pack with a segment scorecard, bottleneck diagnosis, and a prioritized experiment backlog.”

Example 2 (B2B marketplace, category imbalance):
“Use marketplace-liquidity. We match startups with freelance designers. Liquidity is strong in ‘logo design’ but weak in ‘product design’ and ‘brand refresh.’ Goal: cut median time-to-first-qualified-match from 5 days to 2 days for product design in 60 days. Provide a liquidity metric tree, fragmentation map, and operating cadence.”

Boundary example (not a liquidity problem):
“Write Google Ads copy to get more buyers.”
Response: this is primarily acquisition/copy. If marketplace reliability is already strong, use copywriting / channel-specific growth work. If reliability is unknown, start with an intake to confirm a liquidity bottleneck first.

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Web3

defining-product-vision

No summary provided by upstream source.

Repository SourceNeeds Review
Web3

problem-definition

No summary provided by upstream source.

Repository SourceNeeds Review
General

giving-presentations

No summary provided by upstream source.

Repository SourceNeeds Review
General

measuring-product-market-fit

No summary provided by upstream source.

Repository SourceNeeds Review
marketplace-liquidity | V50.AI