Friday, 19 June 2026

Inheriting Someone Else's Garden: What Product Stewardship Actually Means


 Most product management writing assumes you started from scratch.

A blank backlog. A fresh team. A problem space you get to define. The romantic version of product — where you plant seeds in clean soil and watch something grow from nothing.

That's not the job I have. And honestly? I think it's the more interesting one.

Amongst other things, I am a product steward. Which means I inherited a garden that someone else planted, tended, and — in some cases — had very strong opinions about. And if you've ever taken on an existing product rather than building one from zero, you'll know that almost none of the advice out there is written for you.

So here's my attempt to fix that.



๐ŸŒฟ First: What's the Difference?

Product ownership — in the traditional sense — implies the thing is yours. You built it, you shaped it, your fingerprints are all over it. You know why every decision was made, because you made most of them.

Product stewardship is different. You are the custodian of something that existed before you arrived and will (if you do your job well) exist after you leave. You didn't plant the roses. You didn't decide where the path went. Some of those gnarled old trees at the back of the garden? You have no idea what they are yet. But they've been there for years and the community that uses this garden has feelings about them.

Stewardship asks something different of you than ownership does. It asks you to listen before you act. To respect what was built before you understood it. To hold your opinions lightly until you've earned the right to have them.

This is, I will be honest with you, harder than it sounds.



๐Ÿงค The Temptation to Rip Everything Out

When you inherit a product, there will be a moment — probably in the first two weeks — where you look at something and think: why on earth did anyone do it this way?

The answer is almost always: because at the time, with the information they had, it made sense. The context has changed. The team has changed. Maybe the users have changed. But the decision was made in good faith, and it served a purpose. Always keep this in mind.

This doesn't mean you never change anything. Stewardship isn't a museum — it's not about preserving everything exactly as you found it. But the instinct to rip things out before you understand them is dangerous, and resisting it is one of the most important disciplines in this kind of role.

Before you change something, ask: why does this exist? Sometimes the answer will be "nobody knows and it can go." Sometimes the answer will be "because three of our most important users depend on it and it would cost us everything to remove it." You won't know which until you ask.



๐Ÿ‘‚ Listening to the Garden

When I took on stewardship of Kotahi — an open-source scholarly publishing platform, and one of the tools we develop at eLife Pathways — the first thing I needed to do wasn't write a strategy. It was listen.

Listen to the developers who'd been working on it and know where the bodies were buried. Listen to the community of organisations using it and understand what they actually needed and now need versus what had been built. Listen to the codebase itself — what is it telling me about decisions made years ago under different constraints.

This listening phase is not glamorous. It doesn't produce a roadmap or a vision doc or a slide deck for leadership. It produces understanding, which is less visible and more valuable and it will fertilise the growth of those artefacts. 

What I learn in the listening phase shapes everything that comes after. The things I thought were problems turned out to be features. The things that looked like strengths had hidden cracks. The community had opinions I hadn't anticipated. All of that came from listening first.



๐ŸŒฑ What Stewardship Actually Looks Like Day to Day

It looks like asking "why does this exist?" before "how do we fix this?"

It looks like building relationships with the people who used the product before you arrived, and treating their institutional knowledge as an asset rather than a barrier.

It looks like being honest — with your team, your stakeholders, and yourself — about what you know and what you don't yet. Pretending to have answers you haven't earned is a fast way to lose the trust of a community that's been around longer than you have.

It looks like making changes incrementally and transparently, so that the people who depend on the product can see where it's going and trust that you're taking them with you.

And it looks like caring about the long game. Stewardship is not about what you can deliver in the next sprint. It's about what kind of garden you're going to hand over to the next person — and whether the community that depends on it will be better served because you were there.



๐ŸงŸ‍♀️ The Honest Bit

I'll be straight with you: product stewardship is humbling.


There is a particular kind of overwhelm that comes with inheriting a live product. It's not like starting something new, where the blank page is daunting but at least it's yours. Inheriting a product is like trying to board a locomotive that's already running at full steam. The track is laid. The passengers are on board. They have opinions about where the train is going and they've been on it longer than you have. And somewhere in the engine room, there are systems and decisions and technical debt you haven't found yet.

The temptation is to sprint — to catch up, to prove yourself, to show you belong on this train. Resist it. The locomotive doesn't need you to run alongside it in a panic. It needs you to get on board, find your footing, and then — gradually, carefully — start to understand what's driving it and where you actually want it to go.

There will be days when you feel like a fraud — like everyone around you knows more about this product than you do, because they do. There will be decisions where you're genuinely not sure if you're making the right call, because you don't have the full context yet, and you may never have it.

But there's something I find quietly profound about this kind of work. You are not building a monument to your own ideas. You are serving something that belongs — in a real sense — to the community around it. The product is not yours. You are its head gardener and guardian for a while.

Do it well and the garden grows. Do it badly and you set back years of work.

That weight is real. But so is the privilege of being trusted with it.


Until next time, my product fiends ๐Ÿ’€.




No comments:

Post a Comment

Small Team, Big Vision: PM When You're Not at a FAANG or other Tech Giant

Here's something nobody tells you when you're learning product management. Most of the books, courses, frameworks, and LinkedIn thou...