When Product Owners Commit Code: Small Steps, Big Impact

Disclaimer: No Product Owners were harmed in the making of this story.
Spoiler: They survived. In fact… they thrived.

We never planned to tell this story.. and certainly not six years later. Back when it happened, it didn’t feel revolutionary. It felt… practical. A small fix to a small annoyance. The sort of thing teams do every day just to make life a bit easier.

But today, in a world where AI blurs boundaries and workflows become more fluid, the lesson behind this tiny experiment has become surprisingly relevant again. Because even before the age of “AI copilots”, our Product Owners had to leap across a much wider gap and yet what unfolded wasn’t about tools at all. It was about mindset. About curiosity. About empathy. And about what happens when teams stretch just a little bit beyond the edges of their roles.

This is the story of how a text-string tweak triggered four years of unexpected collaboration, how we quietly gained almost four developer-years without hiring anyone, how we lost that magic, and why we’re working to rebuild it intentionally this time.

The Pain We Didn’t Know Was Pain

Our team in 2018 wasn’t struggling. We were healthy. We shipped reliably. We liked each other. All the usual metrics and vibes were fine.

And yet… something was off.

A snapshot from a retro that year still makes me smile: an innocent-looking Trello card asking for a tiny text change. A single line. The kind of thing any developer can fix in two minutes if they weren’t juggling twelve other priorities, three bugs, and one architectural conversation.

What we later realised was that this harmless-looking card was actually a placeholder for everything that was silently draining our energy.

Because over time, our backlog had collected a whole ecosystem of micro-tasks:

• localization tweaks
• content or copy adjustments
• minor config changes
• small business-rule updates
• clarifications that needed one sentence but consumed a sprint

Individually, they were harmless. Together, they were a constant trickle steady enough to break focus, slow velocity, and force developers into a never-ending mini-odyssey of meetings, planning, updates, handoffs, and context switches.

Worse, these tiny delays slowly created a subtle but familiar tension:

business urgency ↔ customer expectations ↔ limited developer bandwidth

Not enough to spark conflict.
Just enough to build a quiet “us vs. them” divide.
And enough to make us feel like hamsters on a wheel moving fast, not far.

If any of this sounds familiar to you, trust us: we’ve been there too.

The Slightly Crazy Question

Eventually, instead of adding more structure or more meetings, we asked ourselves something unusual:

“What if we let our Product Owner into the code?”

Not to write features.
Not to build systems.
Just to read config files. Maybe tweak a text string. Maybe remove a tiny blocker or two.

It sounded a bit crazy.
But by then, we were already trying a lot of unconventional ideas so why not add one more?

And so, in 2018, our PO made their debut on GitHub. Watching them navigate the repository was a bit like watching someone learn to ride a bike with training wheels on a rollercoaster… clunky, slow, slightly chaotic but clearly moving forward.

And that was enough.

The Humble PR That Changed Everything

The first change they made?
A tiny text edit on our developer website.

Not glamorous.
Not complicated.
But meaningful.

Because in that moment we realised: role boundaries are useful, but collaboration doesn’t have to stop at them.

A small PR created a surprising sense of momentum not because of the code, but because of what it symbolised.

We weren’t chasing perfection.
We were chasing progress.
And progress arrived in the form of a single commit.

The Shift We Didn’t ExpecT

A few weeks into this experiment, something interesting happened.
The small task “mini-odyssey” that multi-step journey from request to release suddenly lost most of its steps.

Without handoff delays:

• POs were unblocked faster
• developers maintained focus
• work moved through the system more smoothly

What had taken days now took hours.

And this wasn’t a lucky Friday afternoon. This became the new baseline.

Between 2018 and 2021, our PO made:

922 contributions : commits, PRs, reviews.

The outcome?

862 developer days saved.
Almost four developer-years of regained focus, without additional headcount.

We didn’t expect numbers like that.
We didn’t measure them at first.
We felt the impact long before we quantified it.

But the numbers weren’t even the real story.

The Impact You Can’t Put on a Dashboard

What truly transformed the team wasn’t the velocity boost. It was the cultural shift.

• Empathy went up.
• Judgment went down.
• Cross-functional understanding grew.
• Technical conversations became clearer.
• Business and tech aligned more naturally.

None of this was an OKR.
Nobody tried to measure it.
It just… happened.

And when empathy rises, productivity follows.
Not because everyone works harder, but because they work better.

Suddenly, refactoring wasn’t a “tough sell” anymore.
Our PO understood why technical work mattered because they had witnessed the friction firsthand.
We even piggybacked tech tasks onto business features instead of waiting for “tech days”.

And yes.. developers wrote slightly nicer code, knowing the PO might read it.

Why It Worked

If we boil the whole experiment down to its core ingredients, it comes to three simple things:

1. A solvable, meaningful problem

Low complexity, high frequency, high interruption cost : the perfect category for cross-role collaboration.

2. A curious PO willing to try

Not to “become a developer”, but to remove friction for the team.

3. Developers who welcomed the partnership

No turf protection.
No “stay in your lane”.
Just genuine collaboration.

It worked for four years not because of heroics.. but because it made sense.

How We Lost It and What That Taught Us

Like many good practices, it faded slowly.
People left.
Others were promoted.
Newcomers naturally reverted to familiar patterns.
Momentum slipped through the cracks.

Nothing catastrophic.
Just silent regression.. the kind that happens when culture is not tended to.

And that was our biggest lesson:

Good culture is never “done”.
It must be maintained, refreshed, and rebuilt – intentionally.

Rebuilding, One Small Step at a Time

Today we’re revisiting the same mindset with intention this time.

Two new Product Owners and one business developer are already submitting PRs.
We’re once again creating space for curiosity, learning, cross-functional collaboration, and shared ownership.

Our simple plan:

• Start small
• Share context generously
• Encourage questions
• Celebrate learning, not perfection
• Repeat

It’s not rocket science.
It’s attention, patience, and a willingness to try again.

The Bigger Lesson

This was never a story about POs writing code.
It was a story about how one small act.. a text change, a tiny PR can shift an entire team’s dynamic.

When people understand each other’s world, empathy rises.
When empathy rises, productivity follows.
And when productivity and trust align, teams quietly become high-performing.

Sometimes, all it takes is one tiny commit to start something much bigger.