Implementing Scrum · Case Studies · Podcast Episode · October 14, 2025 · 3 min read

Wearing Two Hats in Scrum? 3 Rules for Surviving as a Product Owner and Developer

Holding both Product Owner and Developer accountabilities creates real internal conflict. Three rules for wearing both hats without sacrificing value.

It’s a common and challenging scenario in many Scrum teams: one person holds both the Product Owner and Developer accountabilities. You’re 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 significant internal conflict — like being the CEO setting a vision while also being the lead engineer 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.

While the Scrum Guide permits this setup, success requires immense discipline and a clear strategy. Three rules:

Rule #1: Use Scrum Events as Your Guardrails

The Scrum Guide gives you a “permission slip” to wear both hats, but that comes with a critical condition: you must use the Scrum events to manage the context. Stop thinking of these events as just meetings — use them to deliberately force the context switch between your Product Owner and Developer accountabilities.

When to wear the Product Owner hat: Product Backlog Refinement, Sprint Planning, and the Sprint Review. Your focus must be external — talking with stakeholders, analyzing market feedback, ordering the Product Backlog to find the 20% of work that delivers 80% of the value.

When to wear the Developer hat: once the Sprint Goal is set, your primary accountability during the Sprint is Developer. This is most critical during the Daily Scrum — resist the urge to use it as a status report for your inner PO. Instead of thinking as a PO (“I think we should ditch this item”), speak as a Developer: “I’m seeing this complexity and it might impact our Sprint Goal. How can we, as a team, tackle this?” This shifts from a top-down directive to a collaborative plan.

Rule #2: Protect Your PO Time Like Gold

A significant problem with the dual role: the strategic, less-visible work of the Product Owner gets easily pushed aside by the urgent, tangible demands of coding. This leads to burnout and, worse, building the wrong product.

Be ruthless about time-boxing your PO activities — treat that time as a critical meeting with your most important stakeholder. Block it on your calendar and make it non-negotiable (e.g. “the first two hours of every day are PO focus time, no code notifications”). When you switch to Developer hat for the day, commit fully and silence the internal PO voice questioning priorities. This discipline matters because the Product Owner is singularly accountable for maximizing the value of the product — that strategic work has to 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 this dual role’s process challenges. They can’t resolve your internal conflict, but they’re your accountability partner for the process itself — helping make the context-switching between “hats” visible and effective for the whole team.

Two examples of how a Scrum Master can help:

1. During the Sprint Retrospective: asking “Did we feel Product Backlog items were sufficiently refined before Sprint Planning, or did we find ourselves doing PO-level work mid-sprint?” or “Did the necessary stakeholder communication happen, or did it seem overshadowed by urgent development tasks?”
2. During other Scrum Events: gently intervening if roles blur — e.g. if you start defining acceptance criteria during the Daily Scrum instead of discussing progress as a Developer.

Your Next Move

Surviving this dual role means recognizing you’re running a tiny internal startup — you’re the visionary and the person building the product. It’s a masterclass in discipline, but you don’t have to do it without a map. By using Scrum events as non-negotiable gates, protecting your PO time like gold, and leaning on your Scrum Master, you can create the structure needed to perform both accountabilities effectively without sacrificing value or your sanity.

What Next?

What’s one small change you’ll make after reading this? Will you block out your PO time tomorrow? Or have a conversation with your Scrum Master? Let me know via LinkedIn.

Need some real-world assistance? Contact me today.

Full disclosure: this article was created using NotebookLM, an AI tool by Google, based on my own curated sources about Implementing Scrum in the real world. Content has been carefully reviewed for accuracy. Opinions and insights shared are my own.