👔 AI Leadership Q&A

The three AI strategy questions to always have answers to:

1. Where does AI create unique value for our users? (Not "where can we add AI" but "where does AI change what's possible for users in ways our current product doesn't")

2. Where does AI create durable differentiation? (API access to GPT-4o is not a moat. Proprietary data, customer relationships, and domain expertise applied through AI is.)

3. What's our AI-off fallback? (If the model goes down, or we need to turn it off — what happens? Products without graceful degradation are fragile.)

1. Proprietary data — data your competitors can't get. Customer interaction data, domain-specific labels, usage patterns. The longer you collect, the harder to replicate.

2. Evaluation expertise — a rigorous eval suite on your specific task is harder to build than it looks and impossible for a newcomer to replicate quickly. "We know what good looks like for our users" is a genuine advantage.

3. Domain-specific fine-tuning — models trained on your domain, your style, your users' language patterns perform meaningfully better on your task than generic models.

4. Customer trust — users who trust your AI feature and integrate it into their workflows don't switch easily. Trust compounds. Incidents erode it and are hard to recover from.

5. Speed of iteration — teams that can go from "new model available" to "deployed and evaluated" in days outpace teams that take months. Organizational capability is a moat.

What slows AI teams down (that isn't "being careful"):
• No eval suite — every change requires manual testing which takes days
• No observability — incidents are discovered by users, not by monitoring
• No staged rollout — small experiments require full production deployment
• Over-engineering the model — building custom infrastructure instead of using APIs
• Chasing every new model release — context switching destroys velocity

How to structure a competitive AI assessment:

• What they have that we don't — be specific: "Competitor X shipped an AI summarization feature in Q3. We haven't yet."

• What we have that they don't — "Our 5-year dataset of domain-specific interactions is our primary advantage. A new entrant using the same model can't replicate that in under 2 years."

• Where it's a level playing field — "We both have access to the same foundation models. Neither of us has a meaningful model advantage."

• Our plan to close gaps and extend leads — specific, time-bound, resourced.

1. Reliability risk — the model gives wrong answers and users act on them. Mitigation: eval suites, HITL for high-stakes actions, clear disclaimers.

2. Provider dependency risk — Anthropic or OpenAI changes pricing, terms, or capability. Mitigation: provider abstraction layer, eval suite that validates alternatives quickly, contractual coverage.

3. Reputational risk — a public AI failure (hallucination, bias, safety issue) that gets shared. Mitigation: staged rollouts, monitoring, incident runbook, kill switch.

4. Talent and capability risk — the skills required to maintain and improve the system aren't widely available and are expensive. Mitigation: invest in upskilling, documentation, and knowledge transfer.

5. Regulatory risk — AI regulation is evolving fast. EU AI Act, state-level regulations, sector-specific rules (HIPAA for health AI, etc.). Mitigation: legal review, documentation of model decisions, explainability where required.

The resource ask pattern: Never complain about pace without a specific, costed ask. "If we add two ML engineers and a dedicated PM, we can ship the [feature] in Q2 instead of Q3. Here's the business impact of that acceleration." Converts the conversation from complaint to decision.

The skill most undervalued: Evaluation discipline. The ability to define what "good" looks like, build test cases, and systematically measure quality is rarer than ML knowledge and more valuable for a product team. Hire for it.

Score each AI idea on four dimensions (1-5 each):

User value — how much time/effort/frustration does this save for users?
Strategic fit — does this reinforce our core value proposition or distract from it?
Feasibility — can current AI models reliably solve this with reasonable quality?
Differentiation — how hard is this to replicate once we ship it?

Ideas that score 4+ on all four dimensions are your priority. Ideas that score low on feasibility are experiments, not roadmap items. Ideas that score low on differentiation are features, not bets.

Kill signals for AI features:

• Eval score has plateaued below acceptable threshold after 2+ prompt/model iterations
• Users try the feature, then revert to manual workflow
• The feature generates more support tickets than it deflects
• Model capability improvements haven't moved the metric despite trying newer models
• The underlying task turns out to be fundamentally hard for current LLMs (e.g., tasks requiring real-world common sense, precise reasoning about rare events)

Don't kill signals: Early user confusion (solvable with UX), high initial hallucination rate (often improvable with better prompts/RAG), slow adoption (may be discovery, not quality).

Concrete things that constitute an ethics practice (not just a statement):

• Eval datasets that include representation across demographic groups where relevant
• Documented "what we won't use AI for" with the reasoning
• Clear channels for employees and users to report AI behavior concerns
• External review for high-stakes applications (legal, health, financial)
• Transparency to users about when they're interacting with AI
• Regular review of AI outputs for emerging bias patterns

The honest leadership position: "We take this seriously enough to have specific practices, not just a statement. Here's what we actually do: [specific list]. And here's what we're still working on: [honest gaps]."

EU AI Act risk classification (simplified):

• Unacceptable risk (banned): Social scoring, mass surveillance AI, manipulation systems
• High risk (strict requirements): AI in hiring, credit, healthcare, education, law enforcement — needs human oversight, documentation, conformity assessment
• Limited risk (transparency requirements): Chatbots must disclose they're AI; deepfakes must be labeled
• Minimal risk: Most product AI (recommendations, personalization, internal tools) — minimal requirements

What you should have ready: An AI system inventory, the purpose and data of each system, and a preliminary risk classification. Your legal team does the final assessment.

The "good enough" conversation with your team:

"Good enough" for incremental investment = when quality improvements are marginal (each 1% gain requires disproportionate effort) and user outcomes are positive

"Needs more investment" = when quality is below the bar for the use case, or user outcomes show clear problems (high error rates, low adoption, high edit rates after AI suggestions)

"Should be killed" = when the ceiling of current AI capability is below the minimum acceptable quality bar — no amount of iteration will get there with current technology

The incident response story structure:

T+0 to T+30min: Identified the issue [how — user report, monitoring alert, internal discovery]. Immediately [activated kill switch / disabled the feature / escalated to on-call]. Confirmed scope: [X users affected, what they saw].

T+30min to T+4hrs: Communicated to [affected users / support team / leadership] with [what we knew and what we didn't]. Kept comms factual, not defensive.

Root cause: [specific technical or process cause — not "AI hallucinated" but specifically what the failure mode was].

Changes made: [specific: added output validation layer, added test case to eval suite, added monitoring alert for this pattern, changed HITL requirement for this action type].

What I'd do differently: Honest reflection — shows growth mindset.

Diagnostic questions to ask:

→ Is the quality bar we set achievable with current AI capabilities? (If not, reset the bar or the scope.)
→ Are we measuring the right thing? (Sometimes the metric is wrong, not the output.)
→ Are we iterating systematically or by gut feel? (If there's no eval suite, you're guessing.)
→ Is the team clear on the minimum viable quality to ship? (Perfection is the enemy of progress in AI.)

Momentum interventions:
→ Ship a scoped-down version that works well for a subset of cases
→ Celebrate the learning, not just the shipping
→ Make the eval visible — "we went from 62% to 71% this sprint" is progress even without shipping
→ Time-box: "we'll iterate for 4 more weeks; if we haven't hit X by then, we reconsider the approach"

Culture-building tactics that actually work:

Assign "AI owner" roles — for each product area, one engineer is the AI owner: first to experiment with new models, responsible for the eval suite, the expert the team consults. Ownership creates expertise faster than shared responsibility.

Require AI consideration in design reviews — add "what's the AI-augmented version of this?" as a standing question in feature design reviews. Not "should we use AI?" but "have we considered it?"

Celebrate experiments, not just launches — recognize teams that ran 3 experiments and learned what doesn't work as much as teams that shipped. In AI, learning fast is winning.

Make failure safe to report — the team needs to feel safe saying "the model is behaving weirdly" or "I think we're over-engineering this." Psychological safety is a prerequisite for the constant feedback loop AI quality requires.

Concrete practices:

→ The "why not a prompt chain?" challenge — before approving any agent or multi-step architecture, require the team to explain why a simpler approach won't work. Make them build the simple version first.

→ Architecture reviews with a complexity budget — every technical choice has a complexity cost. Make that cost visible and require justification for spending it.

→ Celebrate simplicity — when a team solves something with 50 lines of code instead of a complex agent system, make that a win worth recognizing. Culture follows what gets celebrated.

→ "What are we trying to prove?" as a standing question — before any significant AI investment, be explicit about the hypothesis being tested and the minimum experiment that would validate it.