What Volunteer Product Work Taught Me 

This blog talks about what the months of volunteer product work actually taught me.
No theory. No frameworks. Just what I saw, what I did, and what I learne 

The Beginning

Nobody warns you that the hardest product work you will ever do might be unpaid.

When I joined as a volunteer Product Owner, I had one question from day one: how do you hold a team together when people keep leaving?

Twenty people. Good intentions. Real skills. And almost no movement.

The problem was not motivation. Everyone wanted to contribute. The problem was structure. Or the absence of it. Nobody knew what we were building. There was a date, a timeline, but a timeline towards what, exactly, was a question nobody had answered out loud.

I have seen this called a coordination problem. Sitting inside it, it felt simpler than that. It felt like a team that had never been introduced to itself.

That was my starting point.

The Structure Problem

The first thing I did when I joined was open Confluence. That was a mistake.

Meeting notes dropped randomly. Pages with no owner. Decisions buried under other decisions. New people joined, could not find what they needed, recreated documents that already existed, and eventually left. Then the cycle started again.

Jira was the same story. Tickets everywhere, no context, no clear definition of done. Some looked like they were generated and pasted directly without anyone asking whether the task made sense in the first place.

This is the risk of AI tools nobody talks about. The risk is not not using them. The risk is of using them without judgment.

But the tools were just the symptom. The real problem was that nobody knew what they were building. Not in the vague early stage way. In a deeper way. People were executing tasks without understanding the product.

It felt like a team that had never been introduced to itself.

The mess was not the problem. The mess was the result of a deeper problem, nobody had ever stopped to ask what we were actually building, and why.

That is where I started. And the first attempt to fix it failed completely.

So, what exactly worked? Here is what happened.

I started with Confluence. Reorganized everything, regrouped, merged, deleted, created clear structure with guidelines anyone could follow. Then Jira. Obsolete tickets deleted, completed work marked properly, remaining tasks matched to actual expectations.

Within days, it was undone.

A key stakeholder kept adding pages anywhere, creating tickets without structure, assigning work without context. Every morning, the previous day's work was partially dismantled.

When I raised it, the message was clear: the product was running before you came. You are here to make things easier, not to complain.

So I stopped cleaning after them.

Instead I built the new structure quietly on the side, without touching what was already running. When the next sprint came, I presented it as ready to try. No confrontation. No complaint. Just something functional.

It worked.

The lesson was not about Confluence or Jira. It was about timing.

Fixing things loudly creates resistance. Fixing things quietly, then presenting them as already working, removes the argument entirely.

Adapting Across Cultures 

I grew up professionally in India, where accountability is direct. If something is not moving, you say so. If someone is responsible, you name it. It is not personal. It is how work gets done, and it works.

France operates differently.

Not better or worse. Just differently. 

The same directness that signals commitment in one culture signals aggression in another. The same clarity that feels respectful in one context feels like blame in another.

I had to learn to code switch.

I stopped assigning tasks as instructions and started framing them as conversations. 

I began asking what people thought would work before sharing my own view. 

I learned to agree first, let people try their approach, and offer alternatives only when needed.

This is not about abandoning how you work. It is about understanding that the same goal can be reached by different roads depending on who is walking with you.

The most useful thing I did was stay curious about the difference rather than frustrated by it.

The most useful thing I did was stop taking it personally.

What This Means for Any PO

Everything I have shared is specific to a couple experiences. But the pattern is not.

Volunteer teams are the most extreme version of a problem that exists everywhere. 

In startups, in nonprofits, in internal innovation projects, in any team where resources are thin, authority is unclear, and people are doing their best with what they have.

If you are a PO walking into that environment, here is what I would tell you.

You do not have to make it perfect on day one. It will work out eventually. When you are overwhelmed, start from one end, any end. HR, documentation, vision, roadmap, it does not matter which. Everything is connected. Once you clear one thing, the picture starts to come together and you move faster than if you had spent that time trying to figure it all out in your head first.

Sometimes moving helps you think better than thinking does.

Pick the most visible problem and solve it quietly. People trust working things more than good ideas. Adapt to the people around you before expecting them to adapt to you. Break tasks smaller than you think necessary. And draw your lines clearly, early. Because if you do not define what is yours, someone else will redefine it for you.

And above all, nothing is personal.

The product is not yours. The team is not yours. You can pour your energy, your thinking, your patience into something for months and it still belongs to someone else. So when a decision goes against you, when credit disappears, when structure you built gets dismantled overnight, drop it. It was never your battlefield.

Save your energy for the product.

That is what months of volunteer agile practice taught me. Not a framework. Not a methodology. Just that.

Thank you for reading along!