2.4 The SME, The Gatekeeper, and Developing Stance Versatility

The SME, The Gatekeeper, and Developing Stance Versatility

Core PSPO II Principle: Domain expertise is a tremendous asset for a Product Owner, but when weaponized to dictate solutions or hoard communication, it morphs into two of the most insidious agile anti-patterns: The Subject Matter Expert and The Gatekeeper. Overcoming these traps requires developing stance versatility—the situational mastery to dynamically deploy the right stance at the right time.

To conclude Chapter 2, we explore the last two of Scrum.org's six misunderstood stances — The Subject Matter Expert and The Gatekeeper — followed by a comprehensive, actionable model for developing stance versatility across varying product lifecycle stages and organizational contexts.

---

1. Misunderstood Stance 5: The Subject Matter Expert (The Domain / Technical Dictator)

The "Curse of Knowledge"

Many Product Owners are promoted directly from specialist roles: lead software architects, senior business analysts, veteran traders, or clinical specialists with decades of domain experience. While deep domain knowledge is an invaluable foundation, it frequently leads to the Subject Matter Expert (SME) misunderstood stance, which Scrum.org sums up in one line: "Let me fill you in on how that works."

The SME operates under the subconscious conviction: "I have worked in this industry for twenty years. I know this product and our customers better than anyone. I don't need to waste time running discovery interviews or usability tests; I already know what needs to be built."

Key behaviors of The SME:

• Dictating the "How": The SME writes granular technical specifications, dictates exact database schemas, prescribes specific algorithms, and designs detailed UI layouts, usurping the Developers' accountability for solution architecture.
• Bypassing Validation: Discarding user feedback or customer research that contradicts the SME's preconceived personal opinions ("The users are wrong; they just don't understand how the system works yet").
• Stifling Innovation: When Developers suggest creative technical alternatives, the SME immediately shoots them down based on historical precedent ("We tried that in 2018 and it failed; do it my way").

+-------------------------------------------------------------------------+
|                        THE SME DYSFUNCTION SPIRAL                       |
|                                                                         |
|  PO believes they hold all the answers based on past domain experience  |
|                               |                                         |
|                               v                                         |
|  PO prescribes exact technical solutions ("HOW"), treating team as typists|
|                               |                                         |
|                               v                                         |
|  Developers lose intrinsic motivation, creativity, and accountability   |
|                               |                                         |
|                               v                                         |
|  When the solution fails in the market, Developers blame the PO         |
|  ("We just built what you told us to build!")                           |
+-------------------------------------------------------------------------+

Remediation: Channelling Expertise Constructively

An expert Product Owner does not discard their domain knowledge; they channel it through preferred stances:

• From Answer Giver to Problem Framer: Instead of providing the solution, the PO uses their deep knowledge to frame provocative, high-context problem statements: "Our settlement reconciliation currently fails on 4% of foreign currency transactions due to latency in the SWIFT network. How might we re-architect the intake flow to eliminate this failure rate?"
• From Dogmatism to Hypothesis Testing (The Experimenter): When the PO has a strong intuition based on domain experience, they treat it as an unproven hypothesis and challenge the Developers to design a low-cost experiment to prove or disprove it empirically.

---

2. Misunderstood Stance 6: The Gatekeeper (The Filter / Communication Bottleneck)

The Illusion of "Protecting the Team"

The Gatekeeper positions themselves as the exclusive, impenetrable filter between the Scrum Team and the outside world. Often operating under the noble guise of "protecting the Developers from stakeholder noise and distractions," the Gatekeeper insists that all communication must pass directly through them.

Key behaviors of The Gatekeeper:

• Information Monopolization: Prohibiting Developers from talking directly with customers, users, or business stakeholders.
• Guarding the Sprint Review: Treating the Sprint Review not as a collaborative working session, but as a scripted theatrical demonstration where the PO speaks on behalf of the team and filters all stakeholder reactions.
• The Bottleneck Effect: Refusing to allow stakeholders to clarify requirements with Developers during the Sprint, insisting that every question must be submitted as a formal request to the PO.

Systemic Impact

• Loss of Empathy: When Developers are completely isolated from real users, they build software for abstract tickets rather than living human beings. Empathy evaporates, and code quality deteriorates.
• Severe Communication Latency: Simple requirement questions that could be resolved in a 5-minute direct conversation between a Developer and an accountant take four days of back-and-forth email exchanges through the Gatekeeper.
• Single Point of Failure: If the Gatekeeper is out sick, in meetings, or on vacation, the entire product development process grinds to a halt.

Remediation: From Gatekeeper to Facilitator and Bridge-Builder

The advanced Product Owner shifts from being a filter to being a bridge:

• Direct Customer Exposure: The PO actively coordinates opportunities for Developers to shadow users, attend customer interviews, and observe usability testing sessions.
• Collaborative Refinement (The Three Amigos): Bringing a Developer (technical view), a Tester/QA (edge-case view), and a Stakeholder/User (business view) together into direct dialogue.
• Clear Guardrails: The PO establishes a simple, transparent agreement: "Developers are encouraged to speak directly with users and stakeholders to understand domain context. However, any new feature ideas or scope changes that emerge from those conversations must go through the Product Backlog, which I retain accountability for ordering."

---

3. Developing Stance Versatility

The Situational Spectrum of Product Ownership

No single preferred stance is universally superior. An effective Product Owner does not pick one favorite stance and occupy it permanently. Professional mastery is defined by Stance Versatility—the ability to evaluate the current organizational environment, product lifecycle stage, and market uncertainty, and fluidly transition across the preferred stances.

+---------------------------------------------------------------------------------+
|                       THE PRODUCT LIFECYCLE STANCE RADAR                        |
+-----------------------+----------------------------------+----------------------+
| LIFECYCLE STAGE       | PRIMARY STANCES NEEDED           | SECONDARY STANCES    |
+-----------------------+----------------------------------+----------------------+
| 1. Emergence          | - The Customer Representative    | - The Decision Maker |
|    (Discovery / Pre-PMF)| - The Experimenter              | - The Collaborator   |
|                       | - The Visionary                  |                      |
+-----------------------+----------------------------------+----------------------+
| 2. Growth             | - The Visionary                  | - The Experimenter   |
|    (Scaling / Expansion)| - The Decision Maker           | - The Customer Rep   |
|                       | - The Influencer                 |                      |
+-----------------------+----------------------------------+----------------------+
| 3. Maturity           | - The Collaborator               | - The Experimenter   |
|    (Cash Cow / Defend)| - The Decision Maker             | - The Influencer     |
|                       | - The Customer Representative    |                      |
+-----------------------+----------------------------------+----------------------+
| 4. Decline            | - The Decision Maker             | - The Visionary      |
|    (Sunset / Pivot)   | - The Influencer                 |                      |
|                       | - The Collaborator               |                      |
+-----------------------+----------------------------------+----------------------+

1. The Emergence / Discovery Stage (Searching for Product-Market Fit)

• Context: Extreme uncertainty. The value proposition is unproven; unit economics are unknown.
• Dominant Stances: The Customer Representative and The Experimenter must dominate. The PO spends significant time outside the building observing users, running pretotypes, testing fake doors, and establishing Time-to-Evidence.
• Supporting Stance: The Visionary provides the inspiring Product Goal that guides the exploratory experiments.

2. The Growth / Scaling Stage (Capturing Market Share)

• Context: Product-Market Fit is established; customer acquisition is surging; technical debt and scaling bottlenecks emerge.
• Dominant Stances: The Visionary (keeping the organization aligned during rapid scaling), The Decision Maker (making ruthless economic trade-offs between feature expansion and architectural stabilization), and The Influencer (aligning cross-functional departments: marketing, legal, sales, operations).
• Danger: Slipping into The Clerk stance as sales demands explode and every deal arrives with a promised feature.

3. The Maturity Stage (Optimizing Value and Defending Market Position)

• Context: Market saturation; steady cash-flow generation; incremental competition.
• Dominant Stances: The Collaborator (partnering deeply with Developers to maximize operational efficiency and refactor architecture) and The Customer Representative (uncovering latent retention friction to prevent customer churn).
• Supporting Stance: The Decision Maker optimizes Current Value (CV) while investing a portion of capacity into Unrealized Value (UV) discovery.

4. The Decline / Sunset Stage (Retirement or Radical Pivot)

• Context: Shrinking customer base; legacy technologies; obsolete business models.
• Dominant Stances: The Decision Maker (decisively sun-setting features, decommissioning infrastructure, and reallocating capital) and The Influencer (managing sensitive communications with long-time legacy customers and internal executives).

---

4. Auditing Your Stances: The Stance Retrospective

Advanced Product Owners conduct regular self-audits to detect accidental drift into anti-patterns. During personal retrospectives, use this diagnostic audit checklist:

1. "Did I write detailed technical solutions this Sprint, or did I present problems for the team to solve?" (If solutions -> Subject Matter Expert risk)
2. "Did I prevent Developers from talking directly to a customer or stakeholder this week?" (If yes -> Gatekeeper risk)
3. "Did I say 'yes' to an executive request simply because I feared their authority, or promise work to every department without naming a trade-off?" (If yes -> Clerk risk)
4. "Did I spend more of the Sprint inside the backlog tool writing tickets and acceptance criteria than talking with customers, stakeholders, and Developers?" (If yes -> Story Writer risk)
5. "Did I hold performance conversations, set individual objectives, or decide team composition for the Developers whose work I order?" (If yes -> Manager risk)
6. "Did I challenge Developers on their sizing to protect a velocity target, assign tasks to individuals, or track hours in the Daily Scrum?" (If yes -> Project Manager / Output Maximizer risk)

When you detect an anti-pattern, pause, inspect the underlying fear or organizational pressure driving it, and deliberately pivot back to one of the six preferred stances.