Back

Concepts & Patterns

Product Management Dynamics

Four lenses on product management. Berne's Transactional Analysis names ten recurring "games" in PM meetings and prescribes an antithesis for each: refuse the assigned role and respond from Adult ego state. 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. Elman reframes the PM's core artifact as story over spec and argues AI's collapse of build cost inverts the development loop, making judgment and curation the whole job. Winters validates this empirically: PM teams are dramatically more productive but not more impactful, because AI removed the engineering bottleneck without replacing the prioritization mechanism — organizations respond by either protecting the downside, maximizing output, or optimizing for impact, and only the third group channels AI into actual growth.

Created Jul 23, 2026·Updated Oct 19, 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.

The Productivity-Impact Gap

Casey Winters' research across PMs at startups through public companies surfaces a striking pattern: everyone is shipping more — more code, more specs, more prototypes, more bug fixes — but few PMs felt the dramatic increase in output had produced a similar increase in business results.

The mechanism: AI made previously uneconomic work cheap enough to do. The unprioritized work. The work that doesn't create leverage. The work that used to stay in the backlog. Keeping up with all of this actively gives PMs less time to plan the most impactful work. The thesis that shipping faster → more experiments → faster learning → faster growth breaks down when capacity to ship exceeds capacity to learn.

Before AI, engineering scarcity forced prioritization. Code was leverage, but code was expensive, so you saved it for the best ideas. Prioritization also controlled the rate of change to the customer and rejected bad ideas. When teams started shipping much faster, more additions reached customers faster — causing confusion — and many of those features should have been rejected in the first place. This is feature slop at the organizational level.

AI also shifted the bottleneck in product development away from engineering and toward design, integration of more features with the broader product, managing edge cases, organizational alignment, and shared product principles. Organizations have not yet redesigned their processes around these new constraints, and the underlying technology keeps changing faster than those processes can stabilize.

AI as Context Layer

PMs are building a personalized context layer around all of their work. The formula: favored model + company context + personal context + company tools. MCP adoption has concentrated workflows so dramatically that the interfaces of many underlying tools — analytics, ticketing, wiki — may as well not matter anymore, because that is not where they are being consumed.

PMs bring context into their favorite AI environment, do all analysis and crafting of strategy there, then export to the appropriate messaging channel — deck, doc, email, Slack. Making sure one interface has context matters more than being good at any individual tool. Skills allow company-specific standards for how certain parts of the workflow should work.

Some PMs have built this context layer personally to leverage across companies and future roles, because the accumulated context belongs to your employer and disappears when you change jobs — new roles feel like starting from scratch more dramatically than before.

Three Organizational Responses to AI

After the initial cycle of using AI → experiencing magic → building faster → experiencing mistakes, Winters identifies three divergent organizational responses. These aren't fixed types — different teams inside the same company can operate differently, and one team may move between modes.

Response 1: Protect the downside — "What if it's wrong?" Teams tighten processes after experiencing AI mistakes. They approve specific AI tools for specific use cases, with strong gates and repercussions for misuse. The advantage is quality control. The risk: spending so much effort protecting the existing position that competitors discover something fundamentally new. Innovation tends to happen off-hours with personal projects. The defining characteristic is a very defined idea of appropriate and inappropriate uses of AI, with strong enforcement.

Response 2: Maximize the upside — "Why not try it?" Teams default to trying everything, accepting some slop in exchange for speed and learning. They are working harder than ever but not growing much faster. PMs build AI chiefs of staff or central tooling to monitor projects that should never have been greenlit. Slop experiments lead to slop internal tools lead to organizational confusion internally and product confusion externally. Skills become performative — hackathons produce published skills rather than new things. Organizational slop is what happens when an organization generates work faster than it can evaluate, coordinate, or absorb it.

Response 3: Optimize for impact — "Did it matter?" These teams care about whether what they build impacts user or business metrics. They perceive AI as a lever for building things that couldn't have been built before. They have fewer tools than Response 2 teams but are more confident in them. Every artifact is written for both humans and agents. Many PMs have changed their default format — markdown or HTML replacing docs and slides. They don't equate token consumption with progress. It seems like teams in this bucket started in Response 2 first; perhaps teams have to get overwhelmed by AI before they learn to constrain it intelligently. This connects to the AI-native product development pattern of docs-to-demos and evals as the core artifact.

Judgment as Differentiator

There is a growing expectation that PMs should be able to query data, prototype, change prompts, write code, build internal tools, create agents, and define evals. But there is also a growing sense that the standard has over-rotated from understanding technology well enough to ensure good decisions to demonstrating technical ability yourself. PMs work harder to prove they're AI-native while having less time to determine whether the things their teams produce should even exist.

For mature organizations, leveraging AI to be more efficient is table stakes. Using AI to create value that couldn't have been created before AI is what is valued. This requires two things: taste — knowing what good looks like with a technology that changes what types of products can be built — and principles — the ground truth that humans and agents execute against. AI raises the value of judgment only when PMs make their judgment understandable to others and reusable.

After a brief period where PMs were expected to become engineers themselves, the engineering team is moving back to owning implementation mechanics. PM increasingly owns what should happen, why, the principles governing a product's behavior, and how success should be evaluated. The eval is becoming the core product artifact — the initial strategy doc defines what we intended to build; the eval defines whether we did.

Centralizing around AI does not mean fully trusting it. Every PM Winters interviewed has developed elaborate boundaries around what AI is allowed to know and what it can decide. A new meta-skill is emerging: managing the context AI has, the synthesis it's allowed to do, what it can execute, where human judgment is still required, and what needs human verification. The more sophisticated the AI workflow, the less the PM blindly trusts AI.

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
  • How PM Work Is Changing in the AI Era — Casey Winters — Empirical research across PM roles; productivity-impact gap; three organizational AI responses (protect, maximize, optimize); bottleneck shift from engineering to alignment/principles; judgment and evals re-emerging as core PM artifacts