Strategy & Execution

AI product roadmaps require a fundamentally different structure than traditional product roadmaps because AI development is inherently uncertain and iterative.

My approach — the "Horizon" roadmap:

• Horizon 1 (Months 1–3): Committed work. Specific features with defined requirements, assigned teams, and measurable milestones. These should be 80%+ confidence items. Example: "Launch AI-powered search suggestions for English-speaking users."
• Horizon 2 (Months 4–6): Planned work with contingencies. Features that depend on Horizon 1 results. Include branch points: "If search suggestion acceptance rate exceeds 20%, expand to 5 more languages. If below 10%, invest in model quality improvements instead."
• Horizon 3 (Months 7–12): Strategic bets. Direction rather than specific features. "Explore multimodal search" or "Investigate personalized ranking." These are research-heavy and should be 2–3 parallel experiments, expecting 1–2 to succeed.

AI-specific roadmap elements:

• Data milestones: Track data collection and labeling progress as first-class roadmap items. No data = no model improvement.
• Infrastructure investments: ML platform, monitoring, evaluation tooling. These are not features users see, but they are prerequisites for shipping reliable AI.
• Re-evaluation checkpoints: Monthly reviews where you reassess Horizon 2 and 3 based on learnings. AI roadmaps should be more fluid than traditional ones.

Common mistake: Treating AI roadmaps like waterfall plans with fixed deliverables 12 months out. The technology and competitive landscape change too fast. Build in flexibility.

This tension between ML timelines and business urgency is one of the most common AI PM challenges. Here is how I handle it:

Step 1 — Decompose the project: "3 months" usually bundles data preparation, model training, evaluation, and productionization. Break it down. What can be done in 6 weeks? Often you can ship a simpler version (fewer features, narrower scope, lower accuracy) in 6 weeks and iterate.

Step 2 — Define the minimum viable model: What is the simplest model that delivers user value? Maybe a logistic regression on handcrafted features ships in 3 weeks, while the deep learning model takes 3 months. If the simple model solves 60% of the problem, ship it and iterate.

Step 3 — Parallelize ruthlessly: Data labeling, model development, frontend work, and infrastructure setup can often run in parallel. The typical bottleneck is data, not model training. Start data collection on day one.

Step 4 — Use transfer learning or third-party models: Can we fine-tune an existing model instead of training from scratch? Can we use a third-party API for v1 and build custom for v2?

Step 5 — Negotiate scope, not quality: Never ship a model you know is dangerously inaccurate just to meet a deadline. Instead, negotiate scope: "We can launch for English-only in 6 weeks, or all languages in 3 months. Which would you prefer?"

Key principle: The PM's job is not to make ML faster. It is to find the shortest path to user value given ML constraints.

Cross-functional AI teams have unique dynamics because the disciplines think fundamentally differently:

• ML engineers think in terms of model architectures, training pipelines, and system scalability. They want clearly defined inputs/outputs and technical specifications.
• Data scientists think in terms of hypotheses, experiments, and statistical significance. They want freedom to explore and dislike fixed deadlines for research.
• Designers think in terms of user journeys, interactions, and edge cases. They want clear user needs and struggle with probabilistic behavior.

My leadership approach:

• Create shared context: Everyone should understand the user problem, not just their piece. I bring the whole team to user research sessions so data scientists see the human impact of their model choices.
• Adapt communication: With ML engineers: speak in metrics and system requirements. With data scientists: speak in hypotheses and experiment designs. With designers: speak in user stories and experience principles.
• Define interfaces, not processes: Agree on what each function delivers to the others (data scientist delivers model with defined accuracy, ML engineer delivers API with defined latency, designer delivers UI with defined interaction patterns). Let each team decide how they work internally.
• Create safe failure zones: ML research has a high failure rate. Normalize this. Celebrate "We learned this approach does not work" as a valid outcome. This prevents teams from hiding bad results until it is too late.
• Joint demos: Weekly demos where all functions show progress together. This creates accountability and surfaces integration issues early.

First: do not panic. Second: do not blindly accelerate. Here is my structured response:

Step 1 — Analyze the competitor's launch (1–2 days):

• Try the feature yourself. What is the quality? What are the limitations? Read user reviews and social media reactions.
• Assess their approach: Are they using a general-purpose LLM or a custom model? Is the feature well-integrated or bolted on?
• Talk to your sales team: Are customers asking about the competitor's feature? Is it affecting deal velocity?

Step 2 — Reassess your strategy (1 week):

• If their version is mediocre: This is good news. They have set user expectations low. Take your time, ship a superior version, and differentiate on quality. "Second mover advantage" is real in AI when first movers ship poor models.
• If their version is good: You need to ship faster, but with differentiation. What user segments or use cases are they not serving well? Where can your proprietary data give you an edge?
• If it changes the market: Re-evaluate whether your planned feature is still the right investment. Maybe you should leapfrog to the next generation rather than match the current one.

Step 3 — Communicate (immediately): Brief leadership on the competitive development and your recommended response. Calm the team — competitive pressure that leads to cutting corners on AI quality is how products ship embarrassing failures.

This happens more often than most teams admit, and the PM's response in the first 24 hours determines whether it becomes a learning moment or a crisis.

Immediate response (first 4 hours):

• Assess severity: Is it a degradation (lower quality) or a failure (harmful outputs, crashes)? If harmful, roll back immediately. Do not wait for root cause analysis.
• Communicate to stakeholders: "We have identified a quality issue in production. We are investigating. Here is what we know so far and our plan."
• Identify affected users: How many users experienced the failure? Can we mitigate for specific segments?

Root cause analysis (days 1–3):

• Data distribution mismatch: Most common cause. Production data looks different from test data. Investigate feature distributions, input patterns, and edge cases.
• Infrastructure issues: Latency causing timeouts, memory limits affecting model behavior, data pipeline delays feeding stale data.
• User behavior patterns: Users interact with AI features differently than testers. Adversarial inputs, unexpected workflows, cultural differences.

Prevention for next time:

• Shadow mode: Run new models alongside production models for 1–2 weeks before switching traffic. Compare outputs without showing them to users.
• Canary deployment: Start with 1% of traffic. Monitor for 48 hours before expanding.
• Production test sets: Create evaluation datasets from actual production traffic, not synthetic test data.

Uncertainty is the default state in AI product development. The PM who waits for certainty never ships. Here is how I operate in ambiguity:

1. Separate what is known from what is uncertain: The user problem is usually clear. The business value is estimable. The ML approach has uncertainty. Focus decisions on the knowns while managing the unknowns.

2. Use time-boxed experiments: Instead of asking "Can you build this?", ask "In 2 weeks, can you build a prototype that tells us if this is feasible?" Set clear success criteria for the prototype: "If the model achieves 75% accuracy on this test set in 2 weeks, we green-light the project."

3. Plan for multiple outcomes: Create three scenarios (optimistic, realistic, pessimistic) and have a product plan for each. "If the model reaches 90% accuracy, we launch as auto-pilot. If 80%, we launch as suggestion mode. If 70%, we shelve and try a different approach."

4. Make reversible decisions quickly: If a decision is easily reversible (trying a new model architecture, testing a feature with 5% of users), make it fast. Save deliberation for irreversible decisions (committing 6 engineers for 6 months, public launch).

5. Communicate uncertainty honestly: To leadership: "We believe there is a 70% chance we can hit the accuracy target by Q3. Here is our plan A, plan B, and the decision points where we will re-evaluate." Leaders respect calibrated uncertainty more than false confidence.

This is perhaps the defining challenge of the AI PM role. Speed and responsibility are not always in conflict, but when they are, here is my framework:

Categorize features by risk level:

• Low risk (move fast): AI-powered search suggestions, content recommendations, email subject line suggestions. Error cost is low, user can easily override. Ship quickly, iterate based on data.
• Medium risk (move with guardrails): AI-driven pricing, automated customer responses, content moderation. Errors have moderate business or user impact. Ship with human review loops, monitoring, and gradual rollout.
• High risk (move deliberately): AI in healthcare, financial decisions, hiring, criminal justice. Errors can be life-altering or legally consequential. Extensive testing, bias audits, regulatory review, and human-in-the-loop are mandatory before any launch.

Practical principles:

• Build safety into the process, not as an afterthought: Include bias testing and safety review in the definition of done, not as a separate gate that delays launch.
• Ship narrow, expand carefully: Launch AI for a limited scope where risks are well-understood. Expand to higher-risk use cases after proving safety and reliability.
• Create a pre-mortem habit: Before every AI launch, ask: "What is the worst thing that could happen? Are we prepared for it?"

Board members want to understand three things: (1) How does AI create competitive advantage? (2) What are the risks? (3) What is the investment and expected return?

Structure your board presentation:

• Market context (2 minutes): What are competitors doing with AI? Where is the industry heading? Frame AI as a business imperative, not a technology experiment.
• Strategic thesis (3 minutes): "We believe AI will [specific business outcome] by [specific mechanism]." Example: "We believe AI-powered personalization will increase customer LTV by 25% by reducing time-to-value for new users." Be specific and measurable.
• Progress and proof points (3 minutes): Show early results, customer quotes, or A/B test data. Boards respond to evidence, not promises. "Our AI pilot with 10% of users showed 18% higher engagement."
• Investment ask (2 minutes): How many people, how much compute, how much time. Compare to the expected return. Be honest about uncertainty: "We expect ROI between $5M and $15M in year 1, depending on model performance."
• Risks and mitigation (2 minutes): Address AI risks proactively: regulatory (GDPR, EU AI Act), reputational (bias incidents), technical (model failures), and competitive (commoditization). Show you have a plan for each.

What to avoid: Technical jargon, demo-driven presentations (boards do not care about demos), and vague promises ("AI will transform everything"). Be concrete, be honest, be strategic.

Knowing when to kill an AI project is one of the hardest and most valuable skills for an AI PM. The sunk cost fallacy is especially dangerous in AI because "with more data, the model might improve" is always a tempting argument.

My kill criteria framework (define before starting):

• Time box: "If we have not achieved 80% accuracy after 3 months of focused effort, we stop." Set this before the project starts when you are rational, not during the project when you are emotionally invested.
• Diminishing returns: Track accuracy improvement rate over time. If accuracy was 60% in month 1, 72% in month 2, 76% in month 3, and 77% in month 4 — the learning curve has flattened. More time will yield marginal gains.
• User signal: If users in beta testing consistently prefer the non-AI alternative, no amount of accuracy improvement will make the feature successful. The problem is the product concept, not the model.
• Opportunity cost: The ML team working on this project is not working on something else. Every quarter this project continues, re-evaluate: "Is this still the highest-value use of these people?"

How to kill gracefully:

• Document what you learned. Failed experiments are valuable if the learnings are captured.
• Acknowledge the team's effort publicly. Killing a project should not feel like punishment.
• Redirect the team to the next highest-priority opportunity immediately. Idle time after a killed project destroys morale.

In AI, traditional product moats (brand, network effects, switching costs) still apply, but there are AI-specific moats that are even more powerful:

1. Data moat: The most durable AI advantage. If your product generates unique data that improves your models in ways competitors cannot replicate, you have a compounding advantage. Example: Google Maps has more driving data than any competitor, so their traffic predictions are better, so more users use Google Maps, generating more data.

2. Feedback loop moat: Design your product so that user interactions directly improve the AI. Every search, click, correction, and override is a training signal. The product gets better with use, creating a virtuous cycle that competitors starting from zero cannot match.

3. Integration moat: Embed AI deeply into the user's workflow so that switching requires retraining a new system on their specific context. A writing assistant that has learned your tone, vocabulary, and preferences becomes more valuable over time.

4. Domain expertise moat: Combine AI with deep domain knowledge that general-purpose AI companies lack. A legal AI startup with former lawyers on the team understands edge cases that a pure technology company would miss.

5. Trust moat: In high-stakes domains (healthcare, finance, security), the first AI product that earns regulatory approval and user trust has a massive advantage. Trust takes years to build and seconds to destroy. Competitors must earn the same trust from scratch.

What is NOT a moat: Using a cutting-edge model (competitors can use it too), having good engineers (they can be hired away), or being first to market (fast followers catch up if you do not have a data or feedback loop advantage).