Wearing Two Hats in Scrum? 3 Rules for Surviving as a Product Owner and Developer
Introduction:
The Internal Tug-of-War
It's a common and challenging scenario in many Scrum teams:
One person holds both the Product Owner and Developer accountabilities.
You are responsible for setting the product vision and maximizing its value, while also being deep in the technical details of building the increment.
This dual role can create a significant internal conflict.
It's like being the CEO, setting a vision, worrying about the market, and being the lead engineer deep in the code fixing bugs.
And when those two roles disagree inside your head, who wins?
This constant switching can lead to a nagging feeling that you're "cheating the process”…
Tweaking priorities based on technical ease rather than true value.
How can one person (YOU?) fulfill both of these demanding roles without feeling like they are constantly fighting themselves?
While the Scrum Guide permits this setup, success requires immense discipline and a clear strategy.
This article will outline that strategy in three key rules.
Before you begin reading this in depth article…
You Can Listen To My Podcast Episode
Instead Of (Or In Addition To?!)
Reading This Article.
In The Podcast Episode — AND This Article — We Cover:
Rule #1: Use Scrum Events as Guardrails to Force Context Switch Scrum Events, Context Switching, Scrum Discipline
Execution Discipline: When to Fully Wear the Developer Hat (The Daily Scrum Test) Daily Scrum, Developer Role, Sprint Goal, Self-Management
Rule #2: The Burnout Trap: How to Protect Your Critical PO Time (The 70/30 Problem) PO Time Management, Developer Burnout, Backlog Refinement
Rule #3: How to Leverage the Scrum Master to Enforce Boundaries Scrum Master Coaching, Accountability Partner, Scrum Boundaries
You can read a detailed “chapter summary” — with direct links to the podcast section — at the end of this article.
* PLEASE NOTE *
THIS article
— which is a summary and overview based on
the content of the podcast episode above —
is part of an experiment I am running.
For more context, please listen to
podcast10.mvizdos.com
or you can
click here to read more about the experiment and see all current episodes of “Implementing Scrum Unscripted - Podcast” series now.
Subscribe To My YouTube Channel
Click on the button to see all episodes of the podcast on YouTube or click here now to subscribe to my YouTube Channel and get notified when I release my next episodes!
ok… so let’s continue the reading (well, you reading not us together heh)….
Rule #1:
Use Scrum Events as Your Guardrails
The Scrum Guide gives you a "permission slip" to wear both hats, but that permission comes with a critical condition: you must use the Scrum events to manage the context.
The core concept is to stop thinking of these events as just meetings.
Instead, use them to deliberately and consciously force the context switch between your Product Owner and Developer accountabilities.
This prevents them from blurring into a confusing and ineffective mess.
The events become your guardrails.
When to Wear the Product Owner Hat
Your Product Owner hat must be firmly on during Product Backlog Refinement (PBR), Sprint Planning, and the Sprint Review.
In these events, your focus must be external:
Talking with stakeholders, analyzing market feedback, and meticulously ordering the Product Backlog to find the 20% of work that will deliver 80% of the value.
Your entire mindset should be on the what and the why of the work, not the technical implementation.
When to Wear the Developer Hat
Once the Sprint Goal is set, your primary accountability during the Sprint is that of a Developer. Your focus shifts entirely to execution—the how.
This distinction is most critical during the Daily Scrum.
You must resist the urge to use this event as a status report for your inner PO.
Your participation in the daily scrum must be strictly as a developer.
You are not there to get a status report for the PO, even if the PO is you.
This means reframing your updates.
Instead of thinking as a PO and saying, “I think we should ditch this item,” you must speak as a Developer: “Okay team, I'm seeing this complexity and it might impact our Sprint Goal commitment. How can we, as a team, tackle this?”
This shifts the focus from a top-down directive to a collaborative, team-based plan.
Rule #2:
Protect Your PO Time Like Gold
A significant problem with the dual role is that the work of the Product Owner—which is strategic, less visible, and involves lots of communication—gets easily pushed aside by the urgent, tangible demands of coding.
This leads to burnout and, worse, building the wrong product.
The solution is to be ruthless about time-boxing your PO activities.
You must treat your PO time as if it were a critical meeting with your most important stakeholder.
A highly effective tactic is to block this time out on your calendar and make it non-negotiable.
For example, you might decide that "the first two hours of every single day are PO focus time," with no code notifications allowed.
Then, when you switch to your Developer hat for the day, you commit fully and try to silence the internal PO voice questioning priorities.
This discipline is critical because the Product Owner is singularly accountable for maximizing the value of the product.
That strategic work must be prioritized over simply building features quickly.
Rule #3:
Don't Go It Alone
Leverage Your Scrum Master
The Scrum Master is an essential accountability partner for navigating the process challenges of this dual role.
While they can't resolve your internal conflict, they are your accountability partner for the process itself, helping you maintain the discipline required to manage it effectively.
A Scrum Master’s job is to ensure the Scrum framework is understood and enacted, which includes upholding transparency.
For the person in a dual role, this means the Scrum Master can help make the context-switching between "hats" visible and effective for the whole team.
Here are two clear examples of how a Scrum Master can provide support
1. During the Sprint Retrospective:
A skilled Scrum Master can ask probing questions that reveal the impact of any role-blurring.
They might ask, "Did we feel the Product Backlog items were sufficiently refined before Sprint Planning, or did we find ourselves doing PO-level work mid-sprint?"
or
"Did we see evidence that the necessary external stakeholder communication happened this sprint, or did it seem like the PO accountability was perhaps overshadowed by urgent development tasks?"
2. During other Scrum Events: The Scrum Master can gently intervene if roles blur inappropriately.
If, during the Daily Scrum, you start defining acceptance criteria (PO work) instead of discussing your progress as a Developer, the Scrum Master can help refocus the conversation back to its purpose—planning the day's work to achieve the Sprint Goal.
Takeaway 4:
WHAT IS ONE OF YOUR OWN IDEAS?
KEEP SCROLLING TO LEARN MORE ABOUT HOW TO DO THIS!
[ pause here for a short commercial break ]
Purchase Your Link To The Enhanced Scrum Guide
[ Learn more at EnchancedScrumGuide.com ]
Your Next Move
Surviving this dual role really means recognizing you're running a tiny internal startup.
You're the visionary and the person building the product.
It is a masterclass in discipline, but you don't have to do it without a map.
By following these three rules:
1) Using Scrum events as non-negotiable gates
2) Protecting your PO time like gold, and
3) Leaning on your Scrum Master
You can create the structure needed to perform both accountabilities effectively without sacrificing value or your sanity.
What Next?
Watch the full video for more in-depth examples and insights!
And… let me ask you to answer this for me (please!)….
What’s one small change you will make after reading this?
Will you block out your PO time tomorrow?
Or have a conversation with your Scrum Master?
Let me know via a direct message on LinkedIn here.
Two More Things…
1) Subscribe to my YouTube Channel today.
2) Subscribe to my “Implementing Scrum” weekly email now!
Need some real-world asssitance?
Contact me today (or connect with me on LinkedIn and let’s chat there via “direct message”).
* FULL DISCLOSURE *
This podcast episode and article [lightly edited by me] was created using NotebookLM, an AI tool by Google, to generate an audio overview based on my own curated sources about Implementing Scrum in the real world.
The content has been carefully reviewed for accuracy.
Any opinions or insights shared are my own, and the AI was used solely as a tool to assist in presenting the information.
PO vs. Developer
The Internal Conflict
3 Rules To Survive Wearing Both Hats In Scrum
Key Moments In This Episode
0:00 Introduction:
The PO-Developer Dual Role Problem Scrum, Product Owner, Developer, Michael Vizdos
0:36 The Core Conflict:
Why PO & Developer Roles Fight Internally PO vs Dev, Internal Conflict, Scrum Accountability
3:35 Rule #1:
Use Scrum Events as Guardrails to Force Context Switch Scrum Events, Context Switching, Scrum Discipline
5:15 Execution Discipline:
When to Fully Wear the Developer Hat (The Daily Scrum Test) Daily Scrum, Developer Role, Sprint Goal, Self-Management
8:08 Rule #2:
The Burnout Trap: How to Protect Your Critical PO Time (The 70/30 Problem) PO Time Management, Developer Burnout, Backlog Refinement
9:26 Rule #3:
How to Leverage the Scrum Master to Enforce Boundaries Scrum Master Coaching, Accountability Partner, Scrum Boundaries
11:01 Summary & What's Next:
Navigating Stakeholder Pressure PO Survival Guide, Saying No, Stakeholder Management