Skip to content

GMI as Customer Zero

Status

  • Authored: 2026-05-12 (replaces the 2026-05-08 version).
  • Stage: Discovery / problem validation.
  • Provisional. Updates as the product takes shape.

What this doc is

A profile of Global Music Imports (GMI) as the first design partner and primary test case for the product. Focused on what GMI lets us validate and design against. The working relationship — Greg Sher as product co-lead — is captured in ../../STATUS.md; this doc is about the business and the use case, not the relationship.

GMI's role at v0: co-designer, sanity-checker, and likely reference customer. Not "the wedge target." GMI is one of three consumer profiles the v0 build designs against (see ../v0/scope.md) — the others are hypothetical retailer profiles used as design forcing functions, not real customers.

Identity

  • GMI — Global Music Imports, https://globalmusicimports.com.au. AU-based, founded 2025.
  • Co-founders: Reece Specis and Greg Sher.
  • D2C-primary with a wholesale program.
  • Segment: high-end boutique musical instruments — guitars, pedals, accessories (e.g. James Tyler, Knaggs).
  • Imports direct from international boutique builders; no AU distributor in the chain for those brands.

Why GMI is the right customer zero

  • Dual-sided fit. GMI sits on both sides of the product's value:
  • Supplier-side surface: receives raw product/import data from overseas boutique builders. Lets us examine what supplier-shaped data looks like at the small-supplier end (see gmi-walkthrough-notes.md for the broader observations on supplier-side data infrastructure).

  • Retailer-side surface: runs a D2C catalogue. Lets us examine what a retailer needs from a normalized data layer. One relationship, two test surfaces.

  • Recent and small. Founded 2025; systems are still being designed. They can adopt rather than migrate, which makes them a real design partner rather than a slow procurement target.

  • Industry insider. No need to educate them on AU music retail dynamics.
  • Co-led product. Greg's industry knowledge and connections are baked into product design directly, not relayed through interviews.

What GMI lets us validate

  • A1 (funded pain). GMI's involvement is a behavioural signal — a real industry founder is investing time in the product because they want it to exist.
  • Supplier-data ingestion shape for boutique direct-import data — the small-supplier case where no internal master-data infrastructure exists.
  • Retailer-side catalogue operation pain for a small, D2C-only, niche-catalogue retailer.
  • What "minimum useful" looks like for a brand-new retailer who can choose what to adopt.
  • Supplier-side participation behaviour as observed through GMI's relationship with their builder suppliers.

What GMI cannot validate alone

GMI is a single, atypical data point. Beyond GMI we still need evidence on:

  • The AU distributor-mediated supplier model (typical for most retailers). GMI imports direct from builders — different supplier topology. ../landscape/apic.md gives indirect evidence of distributor-mediated suppliers but not direct validation.
  • Whether higher-volume retailers with thousands of SKUs have the same priorities.
  • Whether retailers with mature legacy systems (POS, ERP, ecom) can actually switch — adoption pain may dwarf product value.
  • Whether the broader music-retail catalogue (drums, audio, accessories) has the same normalization issues as boutique guitars.
  • Cross-retailer supplier overlap (A2 in the discovery plan) — whether one normalized layer is genuinely shared infrastructure across the segment, or just a tool for each retailer.

These are limits, not blockers. They define what must be validated after GMI — through multi-retailer interviews, supplier conversations, public/industry data, and broader category coverage.

What GMI provides for the build

Tier 1 — essential

  • Raw supplier feeds in their original form. The fragmented MPN/MAP/RRP CSVs Greg receives from builders, plus the scraped CSVs of images/descriptions/specs he assembles from brand websites. At least 2–3 different builders. The mess is the point — pre-cleaned versions hide the patterns the product must handle.
  • GMI's internal cleaned version of the same products. The Shopify Matrixify export, already received (../../research/inputs/gmi-shopify-export-2026-05-12.csv), is the cleaned downstream. The gap between raw and clean is the work the product has to close.
  • A workflow walkthrough. What GMI actually does with each supplier feed: who handles it, how long it takes, which tools, what breaks. Partially captured in gmi-walkthrough-notes.md; a structured call is the next step.

Tier 2 — highly useful

  • Change events, not just static catalogues. New-product announcements, price updates, EOL notices, stock change communications. Keeping data current is the harder problem.
  • Fields GMI actually cares about vs what suppliers provide. Likely a much smaller set than the raw input.
  • GMI's current taxonomy / categorisation, even if informal.
  • The downstream system the data lands in (Shopify, plus anything else).

Tier 3 — nice to have

  • Sample product imagery as received from suppliers.
  • Spec sheets / marketing copy alongside the data.
  • Any internal docs / SOPs for catalogue operations.

Conceptual / framing inputs

  • What GMI would want on day one if a normalized data layer existed.
  • Where the product's framing of the pain diverges from how it plays out in practice — surfaces blind spots.

Data we don't take from GMI

Not a process boundary — just data we don't need and shouldn't accept:

  • Customer data of any kind (D2C buyer info, orders, contact details).
  • Financial / margin data unless directly relevant to a specific product decision.

Risks tied to single-N validation

  • Optimisation lock-in. Building too tightly to GMI's specific case produces a product that fits them perfectly and nobody else. Mitigation: document every product decision against "is this GMI-specific or broadly applicable?"
  • GMI business risk. GMI is a 2025-founded startup. They may pivot, struggle, or grow in ways that change their relevance as a representative case. The product's viability should not be conditional on GMI's continued state.
  • One-operator vantage. Greg's industry knowledge is deep but is one operator's view. Cross-check load-bearing facts against ../landscape/apic.md, future AMA-channel intel, and direct retailer conversations before treating any single industry account as canonical.

Open questions about GMI as a case

About the test surface, not relationship hygiene.

  • What's the realistic catalogue size GMI grows to in year 1, year 2? Affects which scale problems we're designing against.
  • What's the cadence of new-product introduction in GMI's segment? Affects how the product handles change events.
  • Does GMI's brand mix represent any other AU boutique-importer's pattern, or is it idiosyncratic? Affects how broadly GMI generalises as a Bucket 2 case.

Suggested next step

Held — the structured workflow walkthrough call with Greg has happened; its output is folded into gmi-walkthrough-notes.md rather than a separate supplier-workflow map doc. Retailer-side intel from Tyler's domain expertise is folded directly into ../v0/scope.md. Tier 1 raw supplier feeds informed both.