2.3 Misunderstood Stances: The Clerk, Story Writer, Manager, and Project Manager

Misunderstood Stances and Anti-Patterns: The Clerk, The Story Writer, The Manager, and The Project Manager

Core PSPO II Principle: When organizations adopt Scrum superficially, they frequently map existing hierarchical titles and legacy management behaviors onto the Product Owner role. This produces the misunderstood stances—anti-patterns that paralyze agility, destroy self-management, and reduce the Product Owner to an administrative cog or a micromanaging taskmaster.

Scrum.org names six misunderstood stances of the Product Owner, introduced alongside the Professional Scrum Product Owner - Advanced (PSPO-A) class that PSPO II is built on: The Clerk, The Story Writer, The Manager, The Project Manager, The Subject Matter Expert, and The Gatekeeper. This section analyzes the first four; Section 2.4 covers the Subject Matter Expert and the Gatekeeper.

1. The Clerk
2. The Story Writer
3. The Manager
4. The Project Manager (often called the Output Maximizer)

Understanding these anti-patterns, their systemic root causes, and their remedies is a central competency evaluated on the PSPO II assessment. Note that the exam rarely uses the label itself — it describes the behavior and asks what the Product Owner should do instead.

---

1. Misunderstood Stance 1: The Clerk (The Secretary / Order Taker)

Behavioral Profile and Manifestations

Scrum.org characterizes The Clerk with a single sentence: "Sure, we can add that to the backlog." The Clerk aims to satisfy everybody — the customer, the stakeholders, the Developers, and the users — while making no choices and offering no vision.

This individual spends their working day in steering committees, executive briefings, and departmental meetings, taking down what managers and external stakeholders want, then formatting those notes into neat tickets.

Key behaviors of The Clerk:

• Zero Decision-Making Authority: When a Developer asks, "Why are we building this? Can we simplify this workflow?", the Clerk responds: "I don't know; that's just what the steering committee approved. I'll have to ask them for permission to change it."
• The Inability to Say "No": Driven by conflict aversion or a misguided desire to be "customer-centric," the Clerk says "yes" to every stakeholder request. Backlog ordering is dictated by whichever stakeholder yells the loudest, complains most bitterly, or carries the highest corporate rank — the HiPPO (Highest Paid Person's Opinion).
• Passive Transcription: The backlog is an endless repository of other people's unfiltered ideas, with no strategic filtration, no overarching Product Goal, and no evidence-based prioritization.
• Absence of Vision: The Clerk has no independent perspective on where the product should go or what market problems it should solve.

Systemic Impact

• Development Latency: Every minor clarification must be escalated through the Clerk to the real, hidden decision-makers, creating wait states that stall the Scrum Team.
• Fragmented Sprints: Because the Clerk commits to everyone, Sprints become a disjointed grab-bag of unrelated tasks across many functional areas, with no coherent Sprint Goal and severe context-switching penalties.
• Team Demoralization: Developers recognize that their Product Owner is a figurehead with no influence. They disengage intellectually, treating refinement as a rubber-stamping exercise.
• Feature Bloat and Universal Disappointment: Without a PO capable of saying "no," the product becomes a bloated patchwork of pet projects — and because everything was promised, nothing is finished on time. The very stakeholders the Clerk sought to please become frustrated.

Remediation Roadmap: From Clerk to Decision Maker

1. Organizational Mandate: Leadership must formally empower the Product Owner with real budgetary and backlog authority, publicly affirming that the organization respects their decisions (as the Scrum Guide requires).
2. Anchor Every Sprint in a Singular Sprint Goal: Require that all selected work coherently supports one goal, and stand firm against requests that fracture it.
3. Use Opportunity-Cost Framing — the "Evidence-Based No": When declining a request, never just say "no." Say: "If we build your requested feature now, we must delay the regulatory compliance goal that protects $5M in revenue. Are you prepared to sponsor that trade-off with the executive committee?"
4. Outcome-Oriented Goals: Replace ticket transcription with meaningful Product Goals, evaluating every incoming request against measurable customer outcomes.

---

2. Misunderstood Stance 2: The Story Writer (The Ticket Author)

Behavioral Profile and Manifestations

Scrum.org's portrait of The Story Writer is deliberately physical: curved back, eyes glued to the screen, small font size, and a 14-step template in Jira. Story, check. Acceptance criteria, check. And when Developers or stakeholders open a discussion, the answer is always the same: "The details are in the ticket."

Where The Clerk lacks authority, The Story Writer lacks conversation. They have genuinely accepted accountability for the Product Backlog — they have simply concluded that the accountability is discharged by writing documents.

Key behaviors of The Story Writer:

• Specification over Dialogue: Every requirement arrives as a fully-formed written artifact. Refinement becomes a read-through of the PO's prose rather than a collaborative exploration of the problem.
• Template Worship: Rigid adherence to the "As a <role>, I want <feature>, so that <benefit>" format even when it obscures meaning, plus mandatory fields, sub-tasks, and estimation rituals in the tracking tool.
• Desk-Bound Time Allocation: The overwhelming majority of the PO's week is spent inside the backlog tool. Customer interviews, market analysis, and stakeholder alignment are squeezed into the margins.
• Volume as Evidence of Work: The PO measures their own contribution by how many well-formed items they produced, not by what those items changed for a customer.

[!IMPORTANT] The 2020 Scrum Guide never mentions user stories, story templates, or acceptance criteria. Product Backlog items are simply items; user stories are one optional technique among many. A PSPO II distractor that insists on a specific story format as a rule of Scrum is always wrong.

Systemic Impact

• Lost Shared Understanding: A ticket transmits words, not intent. Developers implement a literal reading of the text and deliver something that technically matches the acceptance criteria while missing the customer outcome entirely.
• Discovery Starvation: Hours spent formatting are hours not spent with users. The backlog becomes beautifully written and strategically hollow.
• Reduced Developer Ownership: When specifications arrive complete, Developers stop proposing cheaper or better solutions — there is nothing left to solve.

Remediation Roadmap: From Story Writer to Collaborator

1. Write Less, Talk More: Bring a problem statement and the evidence behind it to refinement, and let the Scrum Team shape the item together. Aim for items that are just detailed enough to start a conversation.
2. Delegate the Mechanics: The Scrum Guide allows the Product Owner to have the Developers perform Product Backlog management activities; the PO remains accountable. Writing the acceptance criteria is exactly the kind of work the whole Scrum Team can do together.
3. Budget Time Outside the Tool: Reserve a fixed share of every Sprint for customer contact, stakeholder alignment, and market evidence, and protect it the way you would protect the Sprint Goal.
4. Judge the Backlog by Outcomes: Inspect whether recent items moved a Key Value Measure, not whether they were well-formatted.

---

3. Misunderstood Stance 3: The Manager (The People Manager)

Behavioral Profile and Manifestations

Scrum.org introduces The Manager with the questions this PO opens every conversation with: "Are you doing fun, exciting, and innovative work today? How is everybody's energy today? Are we all feeling well? How do you feel about your performance?" The Manager typically holds many one-on-one conversations with each team member.

This stance appears most often where an existing line manager, team lead, or department head is renamed "Product Owner" without giving up their people-management duties. The intent is usually benevolent — but the Product Owner accountability and the line-management accountability pull in opposite directions.

Key behaviors of The Manager:

• Performance Conversations with Developers: Running appraisals, setting individual objectives, or influencing compensation for the people whose work they also order.
• Owning Team Composition: Deciding who joins or leaves the Scrum Team, and assigning specialists to work based on their job titles.
• Substituting Management for Product Work: One-on-ones, career development, and team morale crowd out vision, strategy, discovery, and backlog ordering.
• Absorbing the Scrum Master's Work: Treating team effectiveness and impediment removal as the PO's job, which leaves the actual Scrum Master without a purpose.

Systemic Impact

• Structural Suppression of Transparency: Developers who know the PO influences their performance review will not surface bad news — a failing experiment, an unrealistic forecast, mounting technical debt. Empiricism dies quietly, because inspection depends on honest data.
• Compromised Self-Management: The Scrum Guide is explicit that Developers are self-managing and choose who does what. A PO with hiring-and-firing power over them cannot credibly leave those choices alone.
• Neglected Product Accountability: Every hour spent on people management is an hour the product goes un-led, which is precisely the gap that lets The Clerk or The Story Writer take hold as well.

Remediation Roadmap: From Manager to Influencer and Leader

1. Separate the Accountabilities: Move line management, appraisals, and compensation to a manager outside the Scrum Team. Scrum defines three accountabilities — Product Owner, Scrum Master, Developers — and none of them is "boss of the Developers."
2. Lead Through the Product, Not the Org Chart: Influence by making the vision, the Product Goal, and the customer evidence compelling, so alignment comes from shared purpose rather than reporting lines.
3. Return Team Effectiveness to the Scrum Master: Coaching, facilitation, and impediment removal belong to the Scrum Master; team-level improvement belongs to the Sprint Retrospective.
4. Keep Caring — Change the Mechanism: Genuine interest in people is a strength. Express it as a collaborator and peer, not as an evaluator.

---

4. Misunderstood Stance 4: The Project Manager (The Output Maximizer)

Behavioral Profile and Manifestations

Scrum.org describes The Project Manager as also often referred to as the Output Maximizer: this PO can show you amazing graphs and schedules in Jira, knows all about velocity and predictability, and treats maximizing output and delivering all features as their core focus. The pattern usually appears when a traditional project manager moves into the Product Owner role without shifting the underlying command-and-control paradigm.

Key behaviors of The Project Manager:

• Managing the Traditional Iron Triangle: Obsessed with fixed scope, fixed time, and fixed budget within Sprints. They treat the Sprint Backlog as a locked contract rather than a flexible plan.
• Chasing Velocity and Challenging Estimates: Arguing during refinement and planning — "Why is this an 8? That was a 5 last Sprint. Make it a 5 and we can pull in two more stories!" — and reporting velocity increases upward as proof of "productivity."
• Task Assignment and Micromanagement: Assigning specific tasks to individual developers ("Alice, take ticket 101; Bob, take 102") and tracking individual hours or percentage-complete metrics.
• Hijacking the Daily Scrum: Turning it into a status meeting where Developers report to the Product Owner rather than collaborating with each other.
• Gantt Charts and Heavy Documentation: Maintaining multi-month Gantt schedules and milestone dependency charts.

Systemic Impact: Goodhart's Law and the Velocity Trap

When output becomes the target, it triggers Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure."

+--------------------------------------------------------------------------+
|                       THE DESTRUCTIVE VELOCITY CYCLE                     |
|                                                                          |
|  PO pressures team to increase velocity (Story Points per Sprint)        |
|                             |                                            |
|                             v                                            |
|  Developers artificially inflate story point estimates (A '3' becomes an '8')
|                             |                                            |
|                             v                                            |
|  On paper, velocity surges by 40%; management celebrates "growth"        |
|                             |                                            |
|                             v                                            |
|  In reality, zero additional customer value or working software is delivered|
|                             |                                            |
|                             v                                            |
|  Technical debt accumulates as team cuts quality to hit artificial targets|
+--------------------------------------------------------------------------+

Two Scrum Guide rules make this stance indefensible:

• The Developers who will do the work are solely accountable for sizing Product Backlog Items. The Product Owner may help them understand trade-offs but has no authority to alter or dictate estimates.
• Developers are self-managing: they decide who does what and how to achieve the Sprint Goal. When a PO assigns tasks, Developers become passive workers waiting for instructions, and team accountability collapses.

The Project Manager also rejects empirical learning: when new technical complexity emerges mid-Sprint, they treat it as a "deviation from schedule" to be suppressed rather than feedback that should change the plan.

Remediation Roadmap: From Output to Outcome

1. Adopt Evidence-Based Management (EBM): Shift organizational reporting from output metrics (velocity, story points, features shipped) toward outcome metrics (Current Value, Time-to-Market, customer satisfaction, defect escape rate).
2. Decouple Sizing from Performance Evaluation: Story points are a relative, internal capacity-forecasting tool for Developers, never an organizational productivity KPI.
3. Enforce the Division of Accountabilities: The Product Owner owns the "What" and "Why" (Product Backlog, Product Goal); the Developers solely own the "How" and "Who" (Sprint Backlog, technical design, task assignment, and sizing).
4. Exit the Daily Scrum: It is an event for the Developers. The PO attends only if invited to clarify backlog items and must never run it.
5. Forecast Probabilistically, Not Deterministically: Replace Gantt commitments with throughput-based ranges and confidence levels, and celebrate value delivered rather than points burned.

---

Summary Matrix: Misunderstood Stances vs. Remedies

The remaining two misunderstood stances — The Subject Matter Expert and The Gatekeeper — are examined in Section 2.4, along with the stance versatility that lets an advanced Product Owner move deliberately between the six preferred stances.