Building AI Products across Multiple Domains: Commonalities & Non-Commonalities

Dhruv Ghulati12:32 · May 2024 · 355 views
Thumbnail for Building AI Products across Multiple Domains: Commonalities & Non-Commonalities Watch on YouTube
TL;DR
  1. 1

    AI product managers need the same rigor around product success metrics and experiments as traditional product managers, while also handling training data, evaluation, monitoring, and technical uncertainty.

  2. 2

    The right AI development process depends on the problem, available expertise, label quality, marketplace structure, and the cost of errors.

  3. 3

    Large language models have moved some product work from hand-coded labels and responses toward prompt engineering, generated test sets, and automated evaluation.

Summary

Dhruv Ghulati compares AI product management across document extraction, fraud detection, natural language understanding, recommender systems, marketplace optimization, and assistants. He says AI product managers still need clear product metrics, experiments, and a way to test whether a system works. Their additional work includes breaking technical problems into components, planning training data and annotation, monitoring systems after launch, explaining uncertainty to stakeholders, and helping research-focused teams ship into production. The implementation choices vary by domain. A team with fraud specialists can create better labels and synthetic examples than a team without that expertise. Some products can launch with human review, while others should wait until they exceed human accuracy. For LLM products, teams can use prompt and expected-response test sets, ask an LLM to generate test data, and evaluate prompts as part of development.

Key ideas
03:47

AI product managers add technical requirements to ordinary product discipline

Dhruv says AI product management still uses product practices such as success metrics, experiments, and A/B testing. The additional requirements include a training data strategy, post-launch monitoring, orchestration layers, component design, ensembles or hybrid systems, and an annotation strategy. He also has to split broad problems into simpler components and explain technical systems clearly. The role includes working with researchers who may prefer inventing new methods, while making the case for shipping useful systems into production. AI product managers also deal with uncertain outcomes and need enough technical knowledge to keep up with rapid developments.

07:19

Evaluation depends on the expertise and resources available

Dhruv compares two document and fraud settings. In one, fraud specialists can judge whether a document was altered, a photo was replaced, or a corner was erased. In another, that expertise is unavailable, so the team must create evaluation methods from the resources it has and route uncertain cases to different groups for relabeling. The launch threshold can therefore differ. One product reached an average accuracy level and sent every case to humans for a hybrid check. Another would not launch until it beat human accuracy. The evaluation process is shaped by the people and evidence available.

08:55

Build-versus-buy decisions change when the problem is not central to the business

A team with fraud expertise can understand the types of fraud it needs to detect and generate synthetic fraudulent examples for training. A company without that expertise, especially when fraud is not a core business function, has to consider whether to build its own system or buy one. Dhruv uses this contrast to show why AI product decisions cannot be copied unchanged between companies. The same problem may demand an internal system in one setting and an external solution in another, depending on domain knowledge and the team's ability to create useful data.

09:10

LLMs shift some language work from manual labeling to prompt engineering

Dhruv describes an earlier natural-language project that required extensive handcrafted training data to classify whether statements were pro-climate or anti-climate. With GPTs, a team can ask the model the same question directly and focus more of its work on prompt engineering. He also describes assistants where responses were once hardcoded before launch. With LLMs, teams can build prompt and expected-response test sets, use an LLM to generate test data, and evaluate and optimize prompts during development. The model is therefore part of the product development process, not only the final user-facing feature.

09:51

Optimization problems must account for the surrounding marketplace

When optimizing a system with a goal function, Dhruv says the team must understand whether it operates in a one-sided or two-sided marketplace. At Uber, sending drivers toward a location where they can earn more may change the supply in that area and interact with demand. Promotions, deals, and offers can affect several parts of the marketplace at once. A locally good prediction or optimization result can therefore create unwanted effects elsewhere. Product teams need to account for those connected factors before deciding that an AI system has solved its immediate objective.

"As an AI product manager your key skill set is try to kind of deal with the personalities that exist there and try to kind of explain the benefit of shipping things in production."06:23
Who should watch
  • You are an AI product manager deciding how to set metrics, create evaluation data, or plan a launch with human review.
  • Your team is moving between different AI domains and needs to understand which practices transfer and which depend on domain expertise.
  • You are building an LLM assistant and want to replace hardcoded responses with prompt test sets and model-based evaluation.