How to Build an AI Product: Strategy, Team, and What to Skip

AI is costly, requires constant iteration, and is never really "done." Before writing a line of code, there's a checklist, a strategy framework, and a team structure that determines whether you're building the right thing — or burning capital on the wrong one.

Mayur Domadiya · June 12, 2026 · 12 min read

AI-enabled products are everywhere, but most founders and product leaders skip the most important question: should this product use AI at all? Mayank Mittal — a PM who has shipped products for GE, The Emirates Group, KPMG, and Kraft Heinz, launched two startups in IoT and AI, and holds a Carnegie Mellon MS in Information Systems Management — lays out a step-by-step approach for planning an AI product strategy using Lean startup methodology. This is the framework that determines whether your AI investment compounds or evaporates.

5 Questions to Ask Before You Build

AI adds cost, complexity, and maintenance overhead that rule-based systems don't. Before committing to an AI solution, every team should honestly answer five questions. Each one should be a clear "yes" — if any is "no" or "maybe," reconsider whether AI is the right tool.

Does the necessary data exist? Machine learning models require large quantities of real-world data that is consistent across development and testing. A weather model trained only on summer data cannot forecast a snowstorm. This data must also be accessible, properly structured, and compliant with privacy regulations. If the data doesn't exist in usable form, the first build is a data collection project, not an AI product.

Is the problem complex enough? If you can solve the problem by coding a few dozen rules, do that instead. It's faster, cheaper, and more predictable. AI is only justified when other methods can't handle the problem — usually because it involves pattern recognition at scale, continuous learning from new inputs, or variables too numerous and dynamic for explicit programming.

Does the problem change over time? Static problems don't benefit from AI's adaptive learning. If the underlying problem is stable, rule-based systems or statistical analysis are sufficient and much cheaper to maintain. If the problem shifts continuously — commodity prices, user behavior, demand signals — AI's ability to learn from new data pays off.

Can the solution tolerate imperfect results? No AI model is correct 100% of the time, even after years of optimization. If perfect accuracy is required, AI is the wrong choice. If the application can absorb a reasonable error rate while still delivering value, AI becomes viable.

Will the solution require exponential scaling? Consider a tool that tracks the freshness of an online grocery store's apples based on harvest date, location, and transit time. Rule-based logic works at thousands of daily orders. When the tool scales to millions of orders across hundreds of SKUs, the data points compound exponentially — a case where AI pays off over time.

Defining the Product Vision

If all five questions pass, the next step is a product vision: a single statement of why the product should exist and how the world improves if it succeeds. Mittal describes this as the product's "true north" — the common purpose that keeps a cross-functional team aligned when iteration gets difficult.

The framing question is: "How will the world be better if this product succeeds?" Google's 2023 vision statement — "organize the world's information and make it universally accessible and useful" — is the canonical example: concise, directional, motivating, and stable across every product decision that flows from it. An AI product vision that cannot answer this question clearly will struggle to maintain team coherence across the long development cycles that AI requires.

The Lean Startup Loop: Discovery, Validation, Scaling

Mittal's product strategy approach uses Lean startup methodology — specifically, the build-measure-learn loop applied iteratively across three stages. The goal is to avoid building the wrong product before you've confirmed you're building the right one.

Discovery: Research defines and prioritizes problems, generates hypotheses, and identifies customer segments and use cases. Each promising hypothesis gets an MVP statement — a structured description of the user, the pain point, the solution hypothesis, and the metric that will measure whether the MVP works. For an airline addressing stagnant route sales, three MVP statements might look like this: "Providing concierge services for senior citizens will increase year-over-year sales for a specific route by 5%." "Enabling 20% more mileage points for business users will increase online sales by 5%." "Offering free checked luggage up to 20 pounds will increase family bookings by 5%." Each is specific enough to test without building a full product.

Validation: Minimum viable tests (MVTs) determine which hypotheses hold under real customer interaction. Prioritize MVPs by feasibility, customer desirability, and revenue potential. Then create the lowest-fidelity prototype that generates enough signal to confirm or reject the core assumption. If the hypothesis is that senior citizens will pay more for concierge services, a landing page about the feature or a simple chatbot provides enough data to validate or disprove it before building the full system. This process cycles through build-measure-learn until the most viable MVP emerges.

Scaling: Once an MVP passes validation, scaling focuses on three customer development activities: get (customer acquisition), keep (retention and satisfaction), and grow (lifetime value expansion). The right emphasis depends on the company's stage. For the airline's concierge chatbot, the scaling phase uses the same build-measure-learn loop to identify new features, test revenue models, and plan team growth — cycling each new feature hypothesis through discovery and validation before committing.

AI-enabled products are never really "done." The model needs new data, the infrastructure needs to evolve, and what worked at 10,000 users often breaks at 1,000,000. Plan for iteration from day one — not as a correction, but as the product's natural operating mode.

The 4-Part AI Strategy

After the product vision and MVP are defined, technical planning begins with an AI strategy — four components that account for the unique requirements of machine learning systems.

Define the AI problem: Be as specific as possible. The problem statement drives every downstream technical decision: which data to use, which features to select, which algorithm to choose. A vague statement produces vague models. Effective problem statements answer: What problem are you solving, and for whom? What measurable goal does the AI need to achieve? What use cases affect that goal?

Data strategy: More than half of an AI product team's effort goes to data processing. The data strategy answers: What data exists, and what's missing? Where does missing data reside? How do you access it? How do you identify and discard irrelevant data? Data is often fragmented across business units and ownership disputes slow collection significantly — mapping this landscape early prevents expensive delays later.

Tech and infrastructure strategy: AI workloads require massive computational scale and often need to be accessible across secure internal environments, cloud-hosted customer interfaces, and mobile endpoints simultaneously. Infrastructure planning answers: who can access data securely across environments, how will the system scale as data volume grows, and how do you balance computation load for acceptable response times at scale?

Skills and organizational strategy: Before building, determine team composition. AI product teams require five categories of expertise: domain experts (subject matter knowledge for problem framing and utility assessment), engineers and architects (data pipeline, software, infrastructure, and DevOps), product designers (customer-facing interface and UX), data and research scientists (model development and ongoing accuracy optimization), and business representatives and analysts (linking product outcomes to business stakeholders). Assigning ownership of the AI solution — which business unit funds it, which team maintains it at scale — before the project starts prevents organizational friction from blocking growth later.

What This Means

The founders who waste the most capital on AI do so by skipping the five-question gate at the start. They build ML solutions for problems that rule-based logic would have solved better, faster, and cheaper. The ones who compound value are the ones who apply disciplined discovery before committing — validating customer desirability, confirming data exists, defining a specific problem statement, and planning for the compute and talent costs before the first model trains.

The Lean startup loop is not a constraint on AI ambition — it's the mechanism that makes ambitious AI products actually reach users. Each iteration through build-measure-learn is an opportunity to reduce the gap between what the model does and what customers need. The AI engineering work that closes that gap at production scale is where the investment compounds. Getting the strategy and team structure right before that engineering work starts determines how much of that investment actually reaches customers.