Concept Narrative

Status (2026-05-09): Discovery / problem validation. This document articulates the product concept for use in design-partner conversations. Items marked Hypothesis are unvalidated; Out of scope items are deliberate exclusions, not omissions; Open items are pending evidence.

The problem

AU music retailers receive product data from many suppliers in inconsistent forms: spreadsheets with different column names, PDFs, marketing emails, portal exports, attached price lists. To list a product on their ecom site, in their POS, or in their ERP, each retailer cleans, normalizes, categorizes, and enriches that data independently. Across the industry, the same products from the same suppliers are processed N times, by N retailers, in N slightly different ways.

This is repeated structural cost that grows with catalog size and supplier count. It eats staff time, agency fees, and accuracy. It slows down new-product onboarding and new-supplier integration. No single retailer or supplier can fix it alone.

Who it's for

Primary: AU music retailers

Retailers carrying products from multiple suppliers, where catalog operations are a known cost and a known source of friction. Most acutely felt by: - Retailers with growing catalogs and limited ops headcount. - Retailers whose ecom and POS catalogs have drifted out of sync. - Retailers onboarding new suppliers regularly. - Retailers without an internal data team to absorb the work.

Secondary: AU music suppliers and distributors

Suppliers maintain product data in their own formats and have to support many retailers' differing requirements. Each retailer asks for slightly different fields, schemas, or update cadences. Suppliers either tolerate the overhead or under-serve some retailers.

The two groups suffer different versions of the same fragmentation. Their incentives are asymmetric — see "Hypotheses" below.

What this is, conceptually

A shared data layer for the AU music retail industry. It does four things:

Ingests product data from suppliers in whatever form they currently send it.
Normalizes it into a consistent set of fields (name, identifiers, price, attributes, media, etc.).
Maps it into a shared taxonomy and clean categorisation.
Exposes it back to retailers in a useful form: integration-ready, kept up-to-date, and consistent across suppliers.

The central idea: normalization done once, consumed by many. Industry catalog data as shared infrastructure rather than work each retailer redoes.

How it works (conceptual, not implementation)

Suppliers send data the way they already do — no platform required on their side initially.
The platform absorbs format inconsistency on the supplier side.
Retailers consume normalized data through whatever surface fits their stack — exports, an API, or a future integration.
The platform maintains the data over time: handles updates, change events, additions, retirements.
Taxonomy and field standards are governed centrally so consumers don't each invent their own.

This is intentionally vague on implementation — those decisions belong post-validation.

What value it unlocks

For retailers

Hours back per week from manual data wrangling.
Faster supplier onboarding (opt in, not redo).
Faster product onboarding (often already in the layer).
Higher data accuracy and fewer cross-channel inconsistencies.
Foundation for downstream automation: ecom pricing, POS sync, ERP integration, channel feeds.

For suppliers

Send data once in their own format; reach many retailers.
Reduced cost of supporting individual retailer integrations.
More consistent representation of their products in market.
Visibility into how their data flows downstream.

For the broader industry

A reduction in duplicated effort across the segment.
Lower barrier to entry for new retailers who don't want to build catalog ops from scratch.
An eventual integration substrate for tools that sit above catalog data.

Where GMI fits

GMI is uniquely positioned as a design partner because they are both sides at once:

Supplier-side surface. GMI receives product/import data from overseas boutique builders. This shows what raw supplier-shaped data looks like at the source — including the inconsistency, the change events, and the operational reality of receiving it.
Retailer-side surface. GMI runs a D2C catalog operation. This shows what a retailer needs from a normalized data layer — what fields they care about, what a "cleaned" record looks like for them, where the work currently happens.

One relationship lets us examine the full transformation the platform performs.

What we hope GMI specifically helps validate or shape: - What real raw supplier data looks like before any cleaning. - What GMI's actual workflow and pain shape is — in their words, not ours. - What "minimum useful" looks like for a retailer who can choose what to adopt. - What a builder/supplier would tolerate, prefer, or refuse in terms of data flow.

Hypotheses we're testing

Marked explicitly so they don't quietly harden into assumptions.

H1. AU music retailers' pain around supplier data is severe and frequent enough that a paid solution is fundable.
H2. Cross-retailer overlap in supplier base is high enough that a normalized layer is genuinely shared infrastructure rather than a per-retailer tool.
H3. Suppliers will participate once retailer demand exists, even if they have no direct incentive themselves at first.
H4. A minimal API plus a few sensible export formats is enough to power the first integrations.
H5. Retailers will pay for the value before the system is fully feature-complete.

GMI is one data point against H1, H3, and H4. H2 specifically cannot be validated through GMI alone (their supplier topology — direct boutique imports — isn't representative of the typical AU retailer's supplier mix).

What is deliberately out of scope (for now)

Deep taxonomy/spec engines. Start with minimal categorisation; refine later.
Advanced search and faceting.
Retailer workflow tooling (PIM-style editing UIs).
Custom integrations for every retailer; first wave is opinionated.
Consumer-facing surfaces (no marketplace, no D2C — this is infrastructure, not a competitor).
Pricing/business model decisions.
Brand, name, positioning, GTM.
Timeline commitments.

These are excluded by intent, not by oversight.

What we are not trying to be

Not a marketplace.
Not a retailer.
Not a replacement for POS / ERP / ecom platforms.
Not a vertical PIM tool sold to individual retailers (it is shared infrastructure).
Not a wholesale platform.

What we ask of design partners

Honest descriptions of their current workflow and pain.
Sample real data, with permission, that we can use to design against.
Reactions to early concepts and iterations.
Time, occasionally, for a 30–60 min conversation.

What design partners are not asked for at this stage: - Money. - Time commitments beyond occasional conversations. - Public endorsement. - Equity, formal role, or exclusivity. - Anything that changes their commercial behaviour with their own builders or customers.

In return, design partners get founder access, meaningful influence over how the product takes shape (taxonomy, fields, integration priorities), and — when the time comes — early access on terms reflecting their contribution.

Open items (acknowledged, not resolved)

Business model and pricing.
Specific MVP feature cut.
First-launch retailer and supplier set.
Brand, name, positioning.
Timeline (constrained by external factors; not committable now).

Suggested next step

Use this narrative as the conceptual anchor for design-partner conversations. Lead with their pain first; bring the narrative in when they ask "so what does this look like?" — not before.