Designed a governed, reusable data product that transforms fragmented job posting data into structured hiring signals — served via REST/GraphQL API to six distinct consumer personas.
Current state: Job market data is fragmented, noisy, and inaccessible as a reusable asset. Any team wanting to answer "Which ML skills are companies hiring for most in Q1 2026?" has to manually scrape or purchase data, spend weeks cleaning it, build bespoke pipelines, and produce an answer that goes stale within days.
Root cause: This work is being done redundantly — by bootcamps building curriculum, VCs doing diligence, job seekers benchmarking salaries, and HR teams setting headcount budgets. Each consumer solves the same underlying data problem independently, with no shared standard or infrastructure. Without continuous pipelines, job market signals decay within days. Skill names, job titles, and company identifiers are inconsistent across sources.
Target outcome: A governed, reusable data product that solves this once, centrally — with clear ownership, documented contracts, versioned schemas, and accessible via APIs. JobSignals as the single authoritative source for job market intelligence.
Build a Data Mesh-aligned data product — not a job board. Centralize extraction, normalization, and enrichment once; expose outputs via versioned REST + GraphQL APIs. LLM-powered parsing of unstructured job descriptions into structured skill/role taxonomy.
Avoided building a consumer-facing job board (too crowded, wrong positioning). Ruled out one-off scraping solutions — they don't build compounding value. Rejected real-time streaming for MVP in favor of reliable batch pipelines first.
PRD-defined product metrics include: API p95 latency <200ms, dataset freshness <24h, LLM extraction accuracy >92%, and 3 active downstream consumers at Phase 1 close. Instrumented via data catalog with lineage tracking.
JobSignals demonstrates how to apply data product thinking — not just building a dataset, but defining ownership, SLAs, versioning contracts, and consumer-specific interfaces. The key insight: most teams conflate a data pipeline with a data product. A pipeline delivers data; a product makes that data trustworthy, discoverable, and reusable without additional engineering from the consumer. Designing for six distinct personas forced explicit trade-offs on access modes, which surfaced the need for both an API and embedded dashboards — two very different engineering investments that serve the same underlying dataset.