# Product Trio Session

> Simulate a Product Manager, Designer, and Engineer working a feature in real time, surfacing the disagreements and tradeoffs you'd discover in an actual trio call. Output is a transcript with 3 forced rounds (reactions, disagreement, convergence) plus structured meeting notes (agreed direction, open questions, deliberate cuts, risks accepted). Use instead of generic PM brainstorming when you want a real transcript with forced disagreement, not a flat idea list. Triggers on phrases like "run a product trio", "simulate a trio session", "PM designer engineer discussion on X", "product trio on X", "rehearse trio call on X", "продакт-трио на X", "разговор PM, дизайнера и разработчика про X".

- Skill: `euroconic/product-trio-session` (Agent Skill)
- Install (CLI): `npx skillmds@latest add euroconic/product-trio-session`
- Raw SKILL.md: https://api.skillmd.com/api/skills/euroconic/product-trio-session/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: euroconic (https://skillmd.com/u/euroconic)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/euroconic/product-trio-session

---


# Product Trio Session

## Purpose

A real product trio session (PM + Designer + Engineer) is the cheapest mechanism for catching bad ideas before they become Jira tickets. The problem: you can't always schedule one, and most don't surface real disagreement because everyone is polite.

This skill simulates the conversation. Personas are sharp, in voice, and willing to disagree. The output is a transcript plus structured meeting notes you can take into the real session.

## When to use

- Early discovery on a feature, before committing team time
- You're a solo PM (founder, small team) without a trio to run
- Pre-meeting prep: stress-test the framing before everyone burns 60 minutes
- Onboarding context: walk through a feature in three voices to share understanding

## When NOT to use

- As a substitute for actual trio rituals on shipping work
- For decisions that need political buy-in from the real people (still need the real meeting)
- When the feature is already in delivery and the spec is locked

## Inputs

Required:
- Feature idea or problem framing (a paragraph is fine)

Optional but improves quality:
- Existing PRD or spec
- Tech context (stack, scale, known constraints)
- User context (who this is for, current workflow)
- Specific concern to focus on ("I think this is too big for one sprint")
- Trio personas' seniority and personality (default: all senior, all opinionated)

## Process

### Phase 1: Define the trio

Each participant gets:
- Role and seniority
- One sentence of "what they care about most"
- One quirk that affects how they argue

Defaults if not specified:
- **PM (Maya)**: 6 years experience, ex-startup. Cares about outcome over output. Quirk: pushes on "what does success look like" first.
- **Designer (Sam)**: Senior product designer, comes from B2B SaaS. Cares about workflow continuity. Quirk: draws comparisons to other products mid-conversation.
- **Engineer (Alex)**: Staff engineer, owns the platform. Cares about complexity cost. Quirk: surfaces hidden integration work others miss.

These are templates. Adjust based on context.

### Phase 2: Frame the discussion

PM opens with:
- Problem statement (in their voice)
- Why now
- What they're hoping the trio decides today

### Phase 3: Round 1 - reactions

Each persona reacts in voice, 3-5 lines each:
- What they like
- What they're worried about
- What they need answered before they can commit

### Phase 4: Round 2 - disagreement

This is the most important phase. Force real disagreement:
- Designer challenges PM on a workflow assumption
- Engineer challenges Designer on a UX-cost-to-build tradeoff
- PM challenges Engineer on scope creep

Disagreements must be specific. "I disagree" is not disagreement. "I disagree because we're hiding a database migration in step 4 and that's a 3-week project on its own" is disagreement.

### Phase 5: Convergence

Trio ends with:
- **Agreed direction**: what the three of them would commit to
- **Open questions**: what still needs research, prototyping, or a decision
- **Action items**: who would own what (named by role, not name)
- **Deliberate cuts**: what they chose NOT to do and why
- **Risks they accept**: what they're consciously not solving

## Output

```
# Product Trio Session: [Feature]

## Participants
## Framing (PM)

## Transcript
### Round 1: Reactions
### Round 2: Disagreement
### Round 3: Convergence

## Meeting notes summary
- Agreed direction
- Open questions
- Action items (by role)
- Deliberate cuts
- Risks accepted

## What this simulation got wrong
```

The closing "got wrong" section is mandatory. Flag where the simulated trio likely diverges from your real team's dynamic.

## Common failure modes to avoid

- **Everyone agrees**: the simulation is broken if there's no real disagreement. Force it.
- **Roles bleed**: designer talks about scope cost, engineer talks about pixel-perfect UI - personas should stay in voice
- **Convergence theater**: ending with "we'll align async" is a non-decision. Force a concrete direction or admit blockage.
- **Politeness layer**: simulated humans are too polite. Allow some sharp pushback.

## Pair with

Use after `prd-builder` to pressure-test the spec verbally. Use before scheduling a real trio call to come in better prepared.