Technical Data Product Manager

The Technical Data Product Manager owns external, customer-facing data and ML products - a data API, a data feed sold as a product, a model-backed feature, a score or prediction a customer acts on - where the customer is a paying user and the hard calls are about model behavior in production, external guarantees, and what the data or the prediction is worth to someone outside the company. Core ownership is the data / ML product spec, the model-behavior and evaluation requirements (what "good enough" means to the user, the failure the customer cannot tolerate, the online and offline quality bar), and the data-as-a-product contract with its external SLA - delivered across the API and product surfaces, the experimentation platform, and the model-monitoring surfaces the product runs on. This is an individual-contributor seat reporting to a product lead, a Group Product Manager, or a product director, with end-to-end ownership of the "what" and "why now" for its data / ML surface and close partnership with data science, ML and product engineering, GTM, and legal / privacy. The load-bearing differentiator is data and ML depth applied to a customer product: this seat reads a model evaluation and knows whether the metric that moved is the one the customer feels, reasons about drift and a feedback loop months before a model quietly degrades in front of users, and treats a prediction as a feature whose output quality is the UX - not a generalist PM with "AI" in the title, and not an internal-facing data PM. It is not the Product Manager, Data Platform who owns the internal data platform our own analysts, scientists, and ML teams build on (this seat's customer is external and paying, and its success is adoption, retention, and revenue, not internal self-serve and trust), not the general Technical Product Manager whose depth is broad platform / API / infrastructure judgment (this seat's depth is data and ML specifically - model evaluation, the ML lifecycle, and data-as-a-product), and not the Data Scientist / ML Engineer who builds, trains, and serves the model (this seat owns the product "what", the quality and outcome bar, and the contract, and reads the model as the owner of the outcome, not the author of the model). Performance is visible in the external product's adoption, retention, revenue, and the model's real-world quality for customers, so better data / ML judgment produces measurable business impact. What separates great from average is shipping the model's behavior as a product, not the model, and validating value on the customer outcome rather than the leaderboard. A great data-product PM writes the failure the customer cannot tolerate into the spec and designs the graceful-degradation and override path because a model is sometimes wrong in front of a paying user, validates a model change online against the customer outcome instead of trusting an offline metric lift, treats the external SLA and the drift-and-retraining loop as first-class product commitments, and prices and packages the product around the value the customer actually gets. A mediocre one ships whatever the notebook optimized, calls an AUC bump a launch, ignores the false-positive the customer experiences as a broken feature, lets the model rot silently after go-live because monitoring was "ops", and treats an external SLA as a courtesy rather than a commercial promise with churn attached.