Back

Concepts & Patterns

Product Management Dynamics

Three lenses on product management. Berne's Transactional Analysis names ten recurring "games" in PM meetings — predictable transaction sequences with hidden payoffs — and prescribes an antithesis for each: refuse the assigned role and respond from Adult ego state. Shreyas Doshi's Antithesis Principle adds a meta-cognitive layer: every observation about human nature yields an obvious outward tactic and a non-obvious inward warning. Josh Elman reframes the PM's core artifact: not a spec but a story — a repeatable narrative about why a product matters in someone's life — and argues that AI's collapse of build cost has inverted the development loop from spec-then-build to build-then-design, making judgment and curation the whole job.

Created Jul 23, 2026·Updated Sep 15, 2026

Recent Updates

Ego States & Transactions

Berne's foundational claim is that at any moment a person speaks from one of three ego states:

  • Parent — responding as an authority figure once did. Two modes: controlling ("do as I say") and nurturing ("let me take care of that").
  • Adult — processing data, weighing probability, appraising the situation on its merits. The state that reads the spec, estimates risk, and asks for the missing number.
  • Child — reacting as one did when small. Two modes: adapted (compliant, sulking, rebelling) and natural (spontaneous, creative).

A transaction is one stimulus and one response. Three kinds:

  • Complementary — the reply comes from the state you aimed at, so the exchange continues. Adult asks a data question, Adult answers.
  • Crossed — the reply comes from an unexpected state, so communication breaks. "Where are we on the API work?" meets "You're always singling me out." The topic is dead until someone realigns.
  • Ulterior — two messages travel at once: a surface Adult-to-Adult message while the real message runs Parent-to-Child underneath. This is the raw material of every game.

Games and Their Structure

A game is a sequence of transactions that leads to a predictable outcome. It appears to be a straightforward request until the switch — the moment the initiator changes context and collects their actual reward.

People play games because games pay off: reducing tension, avoiding something feared (a real decision, admitting inability), gaining attention (what Berne calls a "stroke"), and reinforcing a fixed belief about the world ("I am not at fault," "people are untrustworthy"). A game is a low-cost, low-risk way of feeling acknowledged without the vulnerability of direct communication.

The counter-move is called the antithesis: reject the role the game assigns you and respond from Adult. When you stop supplying the expected response, the game cannot continue. The initiator typically escalates first; if you hold, Berne predicts a brief confused frustration he calls "despair" — which itself confirms a game was in progress.

Ten Games in Product Work

Why Don't You, Yes But (the objection loop)

Someone brings a problem and rejects every solution with "yes, but." The payoff: proving no solution exists, which excuses inaction and quietly proves the advisers were no smarter. Counter-move: stop advising. Hand the data processing back: "That's a hard tradeoff. Which option are you leaning toward, and what would make it work?" If they open with "X didn't work out," acknowledge it flatly and wait — no advice, no hook, no game.

Courtroom (grievances before a judge)

Two people relitigate a past decision in front of a lead. Each narrates what the other did, waiting for a ruling on who was right. The payoff is reassurance, not resolution. Counter-move: refuse the judge role. Have each person use "I" and address the other as "you" — no "let me tell you what they did." The complaint session cannot survive without its audience.

Now I've Got You (the gotcha)

Someone waits for a slip — a missed date, a wrong number in the deck — and uses the small error to unload stored grievance. The error is pretext; the payoff is justified anger they already carried. Counter-move: set the contract explicitly up front ("here is what I will deliver, and when") to deny the pretext. If you do slip, concede fast and plainly — defense is fuel.

See What You Made Me Do (blame deflection)

A teammate defers a call to you, gets interrupted mid-task, it goes wrong, and the failure is now yours. Over time people learn to stop bringing them decisions. The payoff: avoided responsibility plus a clean excuse to be left alone. Counter-move: put the decision back where it lives. "It's your call. What do you want to do?"

Blemish (nitpick to reject)

A reviewer can't get comfortable with a doc, candidate, or proposal until they've found one flaw, then uses it to dismiss the whole thing. The payoff is relief — finding fault wards off doubt and skips the harder work of judging on balance. Counter-move: force the standard into the open. "Is that a blocker or a nit? What specifically has to be true for this to pass?" Named criteria cancel the roaming license.

I'm Only Trying to Help You (the unhelpful helper)

Someone gives advice that doesn't work. When it fails they collect martyrdom rather than change the advice. If you're grateful they win; if you fail they were "only trying to help." Counter-move: turn help into a concrete, checkable agreement with an owner and a definition of done, so help can't float as a favor that manufactures guilt.

Look How Hard I've Tried (pseudo-compliance)

Someone loudly complies with a plan they intend to let fail, building a visible record of effort so eventual failure lands on the plan, not them. Counter-move: measure the outcome, not the effort. Define what "done" produces in observable terms.

Wooden Leg (the standing excuse)

"What do you expect from someone with my constraint?" The constraint becomes a permanent exemption from expectations. Counter-move: separate the real limit from the exemption. Acknowledge the genuine constraint, then hold the unconstrained part: "Given that, what's the piece we can still move this week?"

Harried (overload to breakdown)

A PM accepts all requests and scope changes, takes on more and more, until nothing ships. The spectacular failure becomes the excuse for why nothing was delivered and brings in rescuers. Counter-move: refuse new requests early. Require that priorities are ranked before taking on additional work — make trade-offs visible while there's still time to decide.

Schlemiel (mess then apology)

Someone repeatedly makes messes — broken builds, blown commitments, trampled process — and banks on accepted apologies to license the next mess. Counter-move: stop auto-forgiving. Acknowledge the apology but keep the consequence. The game needs forgiveness to run.

If It Weren't For You (blame the constraint)

A person or team explains they would be shipping greatness if not for some blocker — another team, a policy, a boss — while quietly relying on that blocker so they never have to test themselves. Counter-move: remove the blocker on paper. "Say that constraint were gone tomorrow. What would you ship?" Berne calls this antithesis "permissiveness" — it unmasks whether the constraint was ever the real reason.

Applying the Framework

A practical example: your boss reviews a proposal and says it's "too aggressive," asking why a more moderate approach wasn't considered. This is a coaching question directed at a subordinate role — responding defensively or trying to please would accept that role.

An Adult response: "Market data indicated the aggressive approach was best. I understand your concern. What specific part of the premise concerns you most, so I can address it?" If revision pressure continues, stay on process: "What criteria must the final document meet for you to approve it?" This accepts the task while requesting concrete Adult-level criteria, removing the opportunity to correct a subordinate.

When Not to Play Analyst

Berne was explicit that this tool cuts badly when misapplied:

  • Labels describe actions, not people. Saying a colleague is "playing Courtroom" is hostile. Use the labels internally to understand dynamics, not as accusations.
  • Some people rely on certain patterns for stability. The goal is to protect your time and ensure honest work, not to dismantle someone's coping mechanisms.
  • Labels don't diagnose. A conversation can appear to be a straightforward Adult exchange and still involve hidden dynamics — or be completely genuine. Look for the behavioral shift and the predictable outcome before concluding a game is running.

The Antithesis Principle

Shreyas Doshi identifies a pattern he calls the Antithesis Principle: any truth about human nature can be pointed two ways — outward and inward. Pointed outward, it gives you a tactic (how people work, so you can be effective with them). Pointed inward, it is a warning: the default you must eliminate in yourself.

Everyone who is smart finds the outward tactic. Only the wise see the inward antithesis.

Examples in product work:

  • Entertainment and learning. Outward: make your content engaging so people learn from it. Inward: train yourself to learn from non-entertaining sources — boring books with unsexy titles, dense specs, dry research — so you access knowledge that charisma-dependent learners skip.
  • Charisma and influence. Outward: develop charisma to grow your influence as a leader. Inward: work to not be swayed by other people's charisma. Most smart people believe they aren't susceptible; most are wrong. Smart is not the same as wise.
  • First impressions. Outward: consciously create a good first impression. Inward: stop being the person who forms a fixed impression of someone in seven seconds.
  • Manager quality. Outward: be a competent manager so you help people do great work. Inward: become the kind of person who does great work even under an average or absentee manager — don't let your output depend on your boss's quality.
  • Analogies. Outward: explain decisions with evocative analogies (people understand better). Inward: never reason by analogy to arrive at decisions. In practice, even people who violently agree with this principle get persuaded in meetings by a clever analogy used as justification.

The deeper pattern: people love consistency, so the apparent contradiction between the outward and inward conclusions is uncomfortable. And people don't question their default programming — when everyone around them shares the same defaults, that feels like validation. The Antithesis Principle asks you to hold both conclusions simultaneously and act on each in its proper direction.

This connects to Berne's antithesis concept at the structural level: both frameworks are about refusing the default role. Berne's antithesis refuses the role a game assigns you in a social transaction. Doshi's Antithesis Principle refuses the role your own cognitive defaults assign you when processing an observation about the world.

Story as the PM Artifact

Reid Hoffman once asked Josh Elman in a LinkedIn interview: "What is the artifact that a product manager produces?" Engineers produce code, BD produces signed contracts, designers produce visuals. Elman answered "the spec" — and spent the next two decades realizing it was the wrong answer.

The spec describes a system: what it must do, what boxes to check. The actual artifact is the story — a narrative about the people who will use the product and why it will matter in their lives. Two properties distinguish a story from a spec: it must be immediately understandable by whoever you're talking to, and it must be repeatable — people need to pass it around faithfully without you in the room.

Elman's one-sentence definition of the PM role: "A product manager helps their team (and company) ship the right product to their users." Each word load-bears:

  • Helps their team — you are not the leader; you help make the thing happen.
  • Team and company — understand your domain and how it fits the bigger picture.
  • Ship — talk is free; putting the product in front of customers is what counts.
  • The right product for your users — this is the actual job: honing in on what "right" means.

The AI-Inverted Development Loop

The old product development loop ran: idea → spec → costing/scoping → build. Teams invented all the rituals of spec-writing, design review, and scoping to protect precious engineering time from bad decisions, because you only got six or eight turns around the loop per year.

AI collapsed the cost of making stuff by an order of magnitude. The loop has rearranged:

  1. Take the idea and build it quickly with AI, just to see how it works and feels.
  2. Play with the prototype and figure out how it fits the overall picture. Prototypes beat what-ifs, every time.
  3. Then design it — now that you've played with it, you know what it is. Design here means both visual/UX design and engineering design.
  4. Ship and learn.

The inversion: from spec-and-scope to build-and-play. The spec is no longer the deliverable — not aspirationally, but literally.

But demos are almost free now; working products are not. The distance from prototype to something real still takes time to cross. The most important question is no longer "does it fit in the schedule?" but "does it fit in the product?" When anyone can build anything, deciding what to build is an impact debate ("this or that"), not a resourcing debate ("this or nothing"). This connects directly to taste and curation in AI-native product development.

The risk: AI lets teams go faster and therefore cram everything in. "AI slop" in content has a product analog — feature slop. When building is cheap, deciding what to build is the whole job, and that is a story problem.

Product Vision: Purpose, Core Actions, Cycle

Elman's framework for product vision (distinct from a mission statement):

  • Purpose — why is someone picking up your product and putting it in their life?
  • Core actions — when they pick it up, what are they actually doing? There may be more than one; you must understand them all.
  • Cycle — what is the expected frequency of each core action?

The test: are people really using your product? Not DAU/MAU, not signups, not waitlist size, not ARR, not app store rank. Those metrics don't answer the question. The real measure is whether people perform the core actions at the expected cycle.

LinkedIn's purpose was to find and be found. The core action for most users — responding when someone reached out — happened once or twice a year. Understanding that low-frequency cycle was critical: the network needed many people willing to be found, and the team invested in profile accuracy rather than daily engagement prompts.

Practical measurement: focus on direct traffic (people who came to you of their own volition — typed your URL, tapped your app icon) and count only people who performed a core action, not those who briefly opened the app.

One new advantage in AI products: when users talk to or prompt your product, you have a literal transcript of the user journey. You can see the exact moment someone gave up and rephrased, and what they expected the product to do that it didn't. These transcripts must be read firsthand — you cannot have AI summarize everything and form your opinion for you. Forming the opinion is the job.

Onboarding as Story Delivery

Onboarding is the single most important moment to tell your story. The user has discovered the product and is maximally attentive — you will never get this much attention from them again.

Three segments in the onboarding audience:

  • Eagers — want in badly, ready to go. Everyone internal to your company lives in eager-land.
  • Fly-bys — heard about it, checked it out, the message didn't land, they'll bail.
  • The fuzzy middle — showed up for a reason, genuinely curious. These are the people to build around; you'll get the eagers anyway.

Design principle: more simple steps beat fewer complex ones. Elman validated this in A/B tests at multiple companies. Discrete, simple steps with clear asks and clear teaching beat single large screens or complex choices designed to minimize step count. The correct retention metric is not how many people finished the flow, but how many come back the next day or week and take a core action.

AI products have made onboarding harder. The blank prompt box — "Hi, ask me anything!" — is in some ways the worst onboarding screen ever designed. A magic box that can do anything leaves the user with nothing to do. The fix: teach capabilities concept by concept, get the user to one valuable use case quickly (ideally with their own data), and let the product demonstrate itself.

Twitter case study. When Elman joined Twitter in 2009, the company had a growth problem that was really a story problem: millions signed up but never came back because no one could explain what Twitter was. The old onboarding offered "Find your friends" or "Follow 20 random people," which most users skipped, landing on an empty compose box with no idea what to do.

The team rebuilt onboarding over two years into the Learn Flow — teaching Twitter one concept at a time as a story. First: "Find out what's happening right now with the people and organizations you care about." Then: this is a tweet (a short message, up to 140 characters, with links). Then: build your timeline — click "follow" on accounts on the left, watch their tweets appear on the right. One motion teaches the whole concept: tweets, following, timeline. The Learn Flow moved retention more than anything else shipped that year.

Sources

  • Games People Play for Product Managers — George from prodmgmt.world — Full application of Berne's Transactional Analysis to PM meetings; ten named game patterns with workplace examples and counter-moves

  • The Antithesis Principle — Shreyas Doshi — For every obvious outward tactic derived from human nature, there is a non-obvious inward antithesis; five worked examples spanning learning, charisma, first impressions, management, and analogies

  • Product Management is Still All About Telling Stories — Josh Elman — Story as the PM's core artifact over spec; AI-inverted development loop (build-then-design); product vision framework (purpose, core actions, cycle); onboarding as story delivery; Twitter Learn Flow case study

  • Games People Play for Product Managers — George from prodmgmt.world — Full application of Berne's Transactional Analysis to PM meetings; ten named game patterns with workplace examples and counter-moves

  • The Antithesis Principle — Shreyas Doshi — For every obvious outward tactic derived from human nature, there is a non-obvious inward antithesis; five worked examples spanning learning, charisma, first impressions, management, and analogies