Overview

A product‑led build to learn, validate, and showcase PMM skills

1) Purpose & Outcomes

  • Why this project now? Broaden hands‑on understanding of how software actually gets built (Claude Code, React, modern web app stack) and keep PMM skills sharp while job hunting.
  • What PMM capabilities am I practising/demonstrating? Problem framing, segmentation & ICP, positioning, research ops, pricing hypotheses, PLG experiments, analytics instrumentation, storytelling.
  • Definition of success (interim): By 31 Aug 2025 (target), validate a listening‑first feed reduces friction: reach ≥60% activation (first preview + wishlist + click‑out) on a small pilot, ≥50% audio‑match coverage for one test store, and run 5+ qualitative interviews capturing "moments of struggle".
  • Constraints: Limited technical depth (learning in public), platform policy (YouTube playback, Discogs API), rate limits, and time.

2) Problem & Hypothesis

  • Problem statement: Indie record stores with 1k+ Discogs listings struggle to present inventory in a listening‑first way. DJs/collectors must jump between clunky YouTube embeds and flat pages, making it slow to audition music and hard for stores to differentiate.
  • Evidence so far: Personal observations; early conversations/demos with DJs & store owners; Discogs supports YouTube embeds but they're poorly organised for continuous listening.
  • Hypotheses to test:
    • H1: A mobile, scrollable feed with inline previews increases time‑on‑listening and wishlist add rate vs current discovery.
    • H2: ≥50% audio‑match coverage is enough to deliver an "aha" moment for DJs/collectors.
    • H3: Store setup is low‑friction if Rotation connects via Discogs OAuth and requires no catalogue re‑entry; this is achieved via Supabase + Redis caching so new listings are auto‑ingested, matched, and served to users.
  • Assumptions & risks: Platform compliance (YouTube playback rules), content availability, API rate limits, background playback constraints, and reliability of the matching pipeline.

3) Audience → Segments, ICP, JTBD

  • Segments considered: DJs (travelling & local), record collectors, record store owners, store staff.
  • Primary user & buyer: Users = DJs/collectors who buy from stores; Payer = record store with a Discogs seller account.
  • ICP (company & persona): Independent record store with ≥1,000 active Discogs listings; sells online and in‑store; uses in‑store listening stations; wants a better listening experience online without rebuilding their stack.
  • Jobs‑to‑be‑done:
    • DJ/Collector: Quickly audition new stock, build a wishlist, and decide what to buy without tab‑hopping.
    • Store Owner: Showcase inventory in a listening‑first way to increase discovery and conversion while keeping existing workflows.
    • Store Staff: Support in‑store discovery ("what should I listen to next?") and shareable wishlists for later purchase.

4) Market Size (TAM/SAM/SOM)

  • Starting wedge (AU): You've identified ~20 stores in Australia with ≥1k Discogs listings (within ICP). Treat this as the initial SAM for the pilot.
  • Working ARPU assumption (for modelling only): average ICP store sits around the 1,000 tier (~A$50/mo). Actual ARPU will vary by inventory bracket once pricing is validated.
  • Adoption scenarios (AU pilot):
    • 25% adoption: 5 stores × A$50 × 12 = A$3,000 ARR
    • 40% adoption: 8 stores × A$50 × 12 = A$4,800 ARR
    • 60% adoption: 12 stores × A$50 × 12 = A$7,200 ARR
  • TAM approach (to fill later): global count of Discogs sellers with ≥1k listings × expected ARPU. Keep this formula‑driven until we collect reliable counts.
  • Value note: Rotation doesn't save staff time; it creates new customer offerings (listening‑first browsing, wishlists/alerts, in‑store discovery via kiosks). Success should be evidenced by sell‑through lift, wishlist→purchase rate, repeat sessions, not time saved.

5) Competitive & Alternatives

  • Direct/indirect competitors: Discogs native experience, Bandcamp store pages, embedded players on store sites, DIY playlists, marketplace listing pages.
  • Switching costs & wedges: Plug‑in value on top of Discogs (no catalogue rebuild). Listening‑first UX. Faster audition → wishlist → buy click. Store‑branded demo pages.
  • Positioning statement: For independent record stores with large Discogs inventories who want to make listening effortless, Rotation is a storefront add‑on that turns merchant pages into a listening‑first feed with playable previews and wishlists. Unlike flat listings and scattered embeds, Rotation centralises audio and accelerates audition‑to‑cart without disrupting existing workflows.

6) Product Scope (MLP) & Experiments

  • Current MLP: Ingest Discogs inventory → match playable previews → mobile feed with inline player, wishlist, and outbound buy links.
  • Shipped so far: In progress. Building prototype flows while learning React/Claude Code; focusing on end‑to‑end "first playable preview" path.
  • Next experiments:
    1. Store demo page pilot with 3 target stores; success: ≥30% of visitors play ≥1 preview; target: by 31 Aug 2025.
    2. Wishlist email alerts (notify when saved records drop in price/come back in stock); success: ≥20% CTR to Discogs.
    3. Audio‑match coverage uplift (pipeline tuning); success: increase coverage from baseline to ≥50% for a test store.
  • Activation definition: First preview played + wishlist add + outbound click within first session.
  • Core metrics: Activation %, 7‑day return rate, previews per session, wishlist adds/session, click‑through to Discogs, matched‑audio coverage %.
    • Metric definitions:
      • Play: either ≥5 seconds continuous playback or a time‑skip event fired.
      • Purchase: tracked via UTM if available; if not, use outbound click‑through + wishlist conversion as proxy.
  • North star (current build): End‑to‑end auth + preview → wishlist → click‑out path functioning reliably.

7) Research Plan & Evidence Log

  • Interview targets: local stores with robust online presence and frequent uploads (esp. 1k–2k Discogs listings), plus DJs/collectors and store staff.
  • Scripts & artefacts: discussion guide link, prototypes.
  • Value & WTP prompts (use in interviews):
    • What new offerings would this enable for your customers (online/in‑store)?
    • If 100 customers used this feed weekly, how would that change sales patterns or inventory turnover?
    • If Rotation generated +5–10 wishlist adds per 100 views, how valuable is that to you?
    • Which KPIs would you watch first (sell‑through, AOV, return sessions, foot traffic at listening stations)?
    • Van Westendorp: At what monthly price is it too cheap / good value / expensive but worth it / too expensive?
    • Would you run this on in‑store listening stations? What would success look like there?
  • Interview log:
    • Date | Who | Segment | Key quote | Implication
  • Usability notes: friction, confusion, time‑to‑value.

8) Pricing & Packaging (Hypotheses)

  • Value metric candidates: Active inventory size (primary), matched‑audio count, connected stores, or traffic volume.
  • Initial tier hypothesis (from builder notes — to be validated):
    • Free: <100 active listings
    • 500 tier: A$30/mo
    • 1,000 tier: A$50/mo
    • 5,000 tier: A$80/mo
    • 10,000+ tier: A$100/mo

    (Ranges reflect early thinking; exact listing brackets to be finalised after store interviews/WTP.)

  • Models to test:
    1. Tiered by inventory (as above) with clear indie discounts.
    2. Usage‑based add‑on for matched‑track volume during busy drops.
    3. Hybrid (base tier + usage credits).
  • Ethical guardrails: Transparent indie discounts; seasonal credits; easy downgrade/opt‑out.
  • Willingness‑to‑pay plan: Qual interviews + directional Van Westendorp; anchor against incremental revenue (sell‑through lift, wishlist→purchase rate, AOV), improved customer experience (plays/session, return sessions), and in‑store behaviours (feed used at listening stations).
View upcoming product

Want to discuss this project?

Get in touch to learn more about my approach and process.

Contact