My balanced view on AI in product development

I am optimistic about AI in product development because I have seen it make hard work more legible. I am cautious about it for the same reason.

AI can draft faster than a team can meet. It can synthesize more material than a person can comfortably hold in one sitting. It can generate options, extract patterns, write prototype code, and turn messy source material into a first-pass artifact. Those are real advantages.

But product development is not just artifact production. It is judgment under constraint. It is deciding what problem matters, whose workflow counts, what evidence is strong enough, what risk is acceptable, and what a team is willing to put its name on.

The rule I keep coming back to

My working rule is the same one that appears across my AI-native healthcare work and my own agent systems:

• AI proposes. It drafts, extracts, summarizes, compares, recommends, and prepares.
• Experts decide. Designers, researchers, PMs, engineers, clinicians, and leaders review, correct, approve, or reject.
• Systems own facts. Deterministic services preserve state, identity, permissions, audit history, and commitments.

This rule is intentionally plain. A team should be able to repeat it in a product review, a design critique, a sprint planning conversation, or an executive readout. If the rule cannot survive the meeting, it is probably too clever to govern the workflow.

The goal is not to slow AI down. The goal is to make the right parts of the work inspectable before speed turns into risk.

Where AI is strongest

In my work, AI is strongest when it helps a team move from scattered material to a clearer next step. That includes research synthesis, requirement comparison, pattern extraction, design critique preparation, workflow mapping, content drafting, prototype scaffolding, and test-case generation.

My own agent team is built around this idea. Maren helps turn research into signals. Reid turns evidence and constraints into strategic recommendations. Hermes forms design positions. Kai tracks delivery risk. Syd builds against the spec. The agents help me think in parallel, but their outputs are still drafts until they pass review.

Learning Atlas applies the same logic to skill building. The system can collect videos, cluster topics, suggest learning actions, and connect material to primary sources. It still asks the learner to verify, practice, and build.

Clarity UX applies it to product workflow. The system can pull PRD and Linear context, shape flows and wireframes, preserve comments, and prepare prototype handoff. It still makes approval and decision trails visible.

Where teams get into trouble

Most AI mistakes I see are not because the model was used. They happen because the team skipped a product discipline they already needed.

• No evidence standard, so plausible output becomes product direction.
• No provenance, so reviewers cannot see where claims came from.
• No state model, so drafts and approved work blur together.
• No permission model, so automation writes where it should only suggest.
• No disagreement protocol, so conflict gets smoothed away instead of resolved.
• No verification loop, so speed hides defects until later.

These are not AI problems in isolation. They are operating-model problems that AI makes more visible.

Evidence-led does not mean slow

There is a lazy version of "evidence-led" that means nobody moves until every question is settled. That is not what I mean. Evidence-led product development means the team is honest about signal strength and makes decisions appropriate to the maturity of the evidence.

A weak signal can justify exploration. A moderate signal can shape a prototype. A strong signal can support a product decision. An invalidated assumption should trigger re-evaluation. The point is not to worship research. The point is to stop pretending all evidence is equal.

This matters even more in AI-native workflows because the interface can make weak confidence look polished. A confident summary, a clean prototype, or a well-written spec can trick a team into moving faster than the evidence supports.

What leaders should put in place

The practical work is not glamorous. It is state, permissions, provenance, review, and operating rhythm. That is exactly why it matters. Trust is earned in the places where the product could have hidden complexity and chose not to.

Design craft still matters

AI does not remove the need for design craft. It raises the penalty for weak craft because more people can now produce interface-shaped things quickly.

Good product design still requires hierarchy, flow, accessibility, interaction detail, content discipline, visual restraint, and sensitivity to the user’s real job. In healthcare and other high-stakes domains, it also requires accountability. The interface has to help experts review, correct, and approve without making the safe path feel like extra work.

That is where I want design teams to spend their energy. Not defending old ways of working, and not surrendering judgment to the newest tool. The mature path is more interesting: use AI to expand what a team can consider, then use evidence and craft to decide what deserves to ship.

FAQ