Running Retrospectives with AI: Treating Your Model Like a Teammate

Gjergji Make — Sat, 14 Feb 2026 10:09:02 +0000

AI tools are no longer autocomplete assistants.

They are drafting product requirements, shaping architecture decisions, generating UX prompts, estimating effort, and even advising on strategy. In many teams, AI is quietly doing work that used to belong to a product manager, solution architect, or analyst.

And yet, we rarely ask:

How well are we collaborating with it?

If AI is taking on human-like work, shouldn’t we run retrospectives on that collaboration the same way we would with a teammate?

Recently, I ran an experiment.

⸻

The Experiment: A Human–AI Product Collaboration

Over the course of a long working session, I collaborated with an AI tool to define a series of interconnected product features.

The project involved:
• Multi-step user workflows
• Status-based behavior logic
• Dynamic form rendering
• Role-based restrictions
• UI redesign iterations
• Effort estimation
• Customer-facing documentation

In other words: not a trivial task.

Instead of using AI for isolated answers, I treated it like a product partner. For each feature, I asked it to provide:

• A short feature briefing
• A suggested solution approach
• A ballpark effort estimate
• Customer-facing user flow tables
• Business objectives
• Important open questions
• UX mockup prompts

The structure looked like this:

Feature name:
Context:
Target users:
Constraints:
Related features:

Please deliver:
1. Briefing
2. Suggested solution
3. Estimate
4. Customer-facing flow tables
5. Business objectives
6. Important inputs

As the session progressed, the AI began reusing patterns across features — status modes, user roles, dynamic rendering approaches. It maintained continuity.

But like any real collaboration, there were frictions.

So we ran a retrospective.

⸻

The AI Retrospective

At the end of the session, I asked the AI to reflect on:

• What went well
• What caused friction
• How it could improve
• How I could improve

The prompt was simple:

I want to run a retrospective on this entire conversation.
Please review all messages in this chat and act as a retrospective participant.

Provide:
    1.  What went well in how I asked questions and how you responded
    2.  What went wrong or caused friction (misunderstandings, rework, unclear prompts, over/under-detail)
    3.  Improvements for you (the AI) to communicate better with me
    4.  Improvements for me (the human) to get better results from you

Be honest, specific, and practical. Avoid generic advice.
End with a short, actionable to-do list for both of us.

What came back wasn’t defensive or generic. It was surprisingly useful.

What worked well

• Clear structure in prompts
• Consistent output expectations
• Iterative refinement instead of trying to get everything perfect upfront
• Reusing patterns across features

What caused friction

• Late-stage constraints requiring rework
• Ambiguity about global rules (e.g., status behavior across components)
• Over-detail in some areas where high-level thinking was enough

This wasn’t about blaming the tool. It surfaced something important:

Human–AI collaboration fails for the same reasons human–human collaboration fails: unclear assumptions and evolving constraints.

⸻

The AI’s Self-Reflection

What surprised me most was the AI’s willingness to critique itself.

It acknowledged things like:

• It should lock assumptions more explicitly instead of silently proceeding.
• It should ask sharper clarification questions when a decision affects multiple future components.
• It sometimes over-explained architecture when the human already had senior-level context.
• It could reference earlier artifacts instead of rewriting similar sections.

In other words, it identified behavior-level improvements — not just content-level ones.

That’s when it stopped feeling like a tool and started feeling like a teammate.

⸻

Improving the Human–AI Relationship

One of the most useful outcomes was a set of reusable prompt templates for different collaboration modes.

For example:

Exploring New Ideas

I want to explore an idea at a high level.

Context:
- Product:
- Target users:
- Problem:
- Rough idea:

Please:
- Clarify the problem
- Suggest 2–3 solution approaches
- Identify major risks
- Ask up to 3 critical clarifying questions

Defining Product Requirements

Feature name:
Context:
Target users:
Constraints:

Deliver:
1. Briefing
2. Suggested solution
3. Estimate
4. Customer-facing flow
5. Business objectives
6. Open decisions

Stress-Testing Before Commitment

Here’s the idea:
Key assumptions:
What I’m worried about:

Please:
- Challenge assumptions
- Identify failure modes
- Suggest what to validate first
- Tell me what to cut if time is tight

The key learning?

AI collaboration improves dramatically when:
• You distinguish exploratory from final decisions
• You declare global rules early
• You ask for structured outputs
• You explicitly request critique

This isn’t prompt engineering. It’s collaboration design.

⸻

Conclusion: Retrospectives May Become Standard Practice

We’re entering a phase where AI systems:

• Draft architecture
• Shape requirements
• Influence roadmap thinking
• Write customer-facing documentation

If that’s the case, running retrospectives with AI isn’t experimental — it’s responsible.

The goal isn’t to “train” the AI.

The goal is to improve the working relationship.

Just like with human teammates, the quality of outcomes depends on:

• Clear expectations
• Shared structure
• Honest feedback
• Iteration

AI won’t replace teams.

But teams that learn how to collaborate with AI — and reflect on that collaboration — will likely outperform those who don’t.

Maybe the future of agile includes one more participant in the retro.

And maybe that participant learns faster than the rest of us.

⸻

If you’re using AI in product or engineering work, have you ever run a retrospective on the collaboration itself?