GUIDE 2026

Data science product development: How I’d make it a product

Josh Fechter
By
Josh Fechter
Josh Fechter
Josh Fechter
Josh Fechter is the co-founder of Product HQ, founder of Technical Writer HQ, and founder and head of product of Squibler. You…
More About Josh →
×

Start with the decision, not the model

I treat a data science product as a product that helps someone make a decision or complete a workflow using data, analytics, or a model. I start by understanding the user, the decision, the cost of being wrong, and what people do today.

A technically impressive model is not automatically a useful product. The experience may also need explanations, controls, human review, fallback behavior, monitoring, and a way to correct bad inputs or outcomes.

Work across the whole system

I would bring product, data science, engineering, design, domain experts, security, legal, and operations together early enough to shape the solution. We would examine data provenance, quality, representativeness, permissions, privacy, latency, infrastructure cost, and how the product behaves when data changes.

I would define success at several levels: user task success, decision quality, operational reliability, model performance where relevant, and unintended effects. Offline metrics can help compare approaches, but they do not prove that people can use the product successfully in context.

Ship a learning loop

I would begin with a narrow, valuable workflow and make uncertainty visible. A prototype, shadow mode, human-in-the-loop process, or staged rollout can reveal problems before full automation. I would document assumptions and establish owners for monitoring, incident response, retraining, and deprecation.

After release, I would combine product behavior, qualitative feedback, data-quality checks, and operational signals. Data science product development is successful when the system helps people make better decisions responsibly—not merely when a model reaches a target on a static dataset.

My bottom line

I use this approach to make the work clearer, not to add process for its own sake. Start with the problem, make the trade-offs visible, and revisit the decision when evidence changes.

If you are building the fundamentals behind this kind of work, the Product HQ data product manager certification is a useful next step. I also share practical lessons in the Product HQ newsletter.

Josh Fechter
Josh Fechter
Josh Fechter is the co-founder of Product HQ, founder of Technical Writer HQ, and founder and head of product of Squibler. You can connect with him on LinkedIn here.