Skip to content

Customer-Zero Profile

Status

  • Authored: 2026-05-08
  • Stage: Discovery / problem validation
  • Provisional. Updates as the relationship develops.

Identity

  • Customer zero: Global Music Imports (GMI), https://globalmusicimports.com.au.
  • Co-founders: Reece Specis and Greg Sher.
  • Founded 2025. AU-based. D2C-primary with a wholesale program.
  • Segment: high-end boutique musical instruments (guitars, pedals, accessories — e.g. James Tyler, Knaggs).
  • Relationship to founder: pre-existing personal connection with one co-founder. Not formed via Employer work. Co-founder has been informed of this product and is willing to act as design partner.

Why GMI fits as customer zero

  • Dual-sided fit. GMI sits on both sides of the platform's value proposition:
  • Supplier-side: they receive product/import data from overseas boutique builders. This lets us examine what supplier-shaped data looks like in their context.
  • Retailer-side: they run a D2C catalog operation. This lets us examine what a retailer needs from a normalized data layer. One relationship, two test surfaces.
  • Recent and small. Founded 2025. Their systems are still being designed; they are positioned to be a true design partner rather than a slow procurement target.
  • Industry insider. No need to educate them on AU music retail dynamics.
  • No commercial entanglement with the Employer (per ../constraints-and-separation.md).

What this relationship lets us validate

  • A1 (funded pain). N=2 evidence point: a real industry founder is keen to engage. Behavioural signal, not opinion.
  • Supplier-data ingestion shape — for boutique direct-import data specifically.
  • Retailer-side catalog operation pain — for a small, D2C-only, niche-catalog retailer.
  • What "minimum useful" looks like for a brand-new retailer who can choose what to adopt.
  • Willingness of suppliers to participate in centralized data flow — through GMI as supplier-of-data.

What this relationship cannot validate

This is the most important section. GMI is a single, atypical data point. Beyond GMI we still need evidence on: - Whether the AU distributor-mediated supplier model (typical for most retailers) has the same data-quality pain shape. GMI imports direct from builders, which is a different supplier topology. - 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 catalog (drums, audio, accessories) has the same normalization issues as boutique guitars. - Cross-retailer supplier overlap (Assumption A2) — whether one normalized layer is genuinely shared infrastructure across the segment, or just a tool for each retailer.

These are not blockers. They are limits. They define what must be validated after GMI by other means (post-employment outreach, public/industry data, etc.).

Engagement scope

Phase 1 — During current employment

Permitted: - Data sharing for product build (with explicit permission, per constraints memo). - Design-partner feedback on prototypes and artifacts. - Pain-framing conversations — led by GMI describing their pain first, not the founder describing their framing first. - Walkthroughs of GMI's current workflow and tooling.

Forbidden: - Introductions to other retailers or suppliers. - Sales or marketing collaboration. - Public association with the project. - Any joint outreach. - Acting as a reference customer.

Phase 2 — Post-employment

  • Reassess intros, sales help, broader collaboration — subject to Schedule 1 restraints active at the time.
  • Define formal design-partner or pilot terms in writing.

What we will ask GMI for

The product's value lives in transforming messy supplier inputs into normalized retailer-ready outputs. So we want both ends of that transformation, plus the work between them — not just clean product data.

Tier 1 — essential

  • Raw supplier feeds in their original form. Spreadsheets, CSVs, PDFs, email attachments, forwarded emails — exactly as received from each builder. At least 2–3 different builders. The mess is the point; do not accept pre-cleaned versions.
  • GMI's internal cleaned version of the same products. Whatever ends up downstream: master spreadsheet, Shopify export, Notion page, etc. The gap between raw and clean is what 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. Pair with the data ask, not separately.

Tier 2 — highly useful

  • Change events, not just static catalogs. 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.
  • Their current taxonomy / categorisation, even if informal.
  • The downstream system the data lands in (POS, ecom platform).

Tier 3 — nice to have

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

Conceptual / framing inputs

  • GMI's wishlist: if a normalized data layer existed, what would they want on day one?
  • Honest feedback on whether the founder's framing of the pain matches their lived experience — or where it doesn't.

Out of bounds (do not ask for)

  • Customer data of any kind — their D2C buyers' info, orders, contact details.
  • Financial / margin data.
  • Anything covered by an NDA or distribution agreement between GMI and their builders without explicit builder awareness.

Format and permission

  • Get real raw data first. Anonymisation can be applied later for provenance hygiene; synthesised data hides patterns the product must handle.
  • Ask explicitly: "Is any of this covered by an NDA or distribution agreement with your builders that would make it problematic to share, even for product development?" The answer determines what's safe.
  • Document permission per dataset (short email exchange suffices): what was shared, when, on what understanding.
  • Send the request as Tier 1 only — don't dump the full list at once. Tier 2/3 items naturally surface during the workflow walkthrough.

What we will not ask of GMI yet

  • Money.
  • Time commitments beyond design-partner conversations.
  • Equity or formal role.
  • Public endorsement.
  • Anything that changes their commercial behaviour with their own builders or customers.

Risks specific to single-N validation

  • Optimisation lock-in. Building too tightly to GMI's specific case will produce a product that fits them perfectly and nobody else. Mitigation: document every product decision against "is this GMI-specific or broadly applicable?"
  • Politeness bias. Personal relationships invite supportive feedback. Watch for "this is great" vs "here's what's broken for me." Behaviour > opinion.
  • Founder-relationship creep. Casual collaboration can form expectations (equity, role, partnership) that are hard to walk back. Be explicit early about role: design partner, not co-founder, unless that's renegotiated openly.
  • GMI business risk. They are a 2025-founded startup. They may pivot, struggle, or grow in ways that change their relevance as a representative case. Don't make the project's viability conditional on GMI's continued state.
  • Disclosure history. Conversations have already happened. Going forward, anchor on him describing his pain first; avoid leading with the founder's pain framing, which may be characterizable as Employer-derived under Clause 19.3.

Open questions

  • Does the GMI co-founder expect anything in return for participation (equity, free use, influence over taxonomy/roadmap)? Surface this early; don't let it accumulate.
  • What is the cadence of conversations and data exchange — weekly, monthly, ad-hoc?
  • In what form is data-sharing permission documented? Email confirmation per dataset is the minimum acceptable.
  • Are both co-founders aware of and supportive of the engagement, or just the connected one? Affects continuity if internal dynamics at GMI change.

Suggested next step

Two parallel asks of the GMI co-founder, both within the Phase 1 scope: 1. Share a representative sample of their builder/import data (anonymised or not, his call) with explicit permission — first concrete dataset for the build. 2. Walk through their current catalog operation workflow on a call — input for the next artifact, the retailer workflow & pain map.

Next artifact in this repo: retailer-workflow-and-pain-map.md, populated from GMI's workflow walkthrough.