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 thought leadership pieces you will ever encounter were written by people at large technology companies, for people at large technology companies. The vocabulary is enterprise. The examples are enterprise. The problems are enterprise.

And if you work in a small, mission-driven team — like I do — you read all of this and think: that's lovely, but that's not my life.

This post is for you.

🔍 What "Small Team" Actually Means

I'm not talking about a scrappy startup with ten people and venture capital and the promise of scale. I'm talking about the kind of team where:

You are the product function. There is no product team. There is you.

You work alongside genuinely talented specialists — a UX designer who cares deeply about the work, data scientists building things that actually matter — but without the layers of process and dedicated support roles that surround those people in a large organisation.

The "design review" happens over a cup of tea, not in a three-day design sprint with seventeen stakeholders in a room.

You may not have a dedicated analytics platform, no experimentation infrastructure, no product ops person to keep the wheels turning. Just judgement, good relationships, and a lot of tabs open.

You wear approximately four hats simultaneously, and two of them don't quite fit.

In this environment, the advice to "run A/B tests" or "align your OKRs across the portfolio" or "leverage your platform team" lands somewhere between baffling and actively unhelpful.

What you actually need is a different way of thinking about the job.

🎯 Strategy is Not a Luxury

The first trap small-team PMs fall into is treating strategy as something they'll get to later, once things are less hectic. Spoiler: things are never less hectic. If you wait for calm water to think strategically, you'll spend your entire career bailing out the boat.

Strategy in a small team doesn't mean a 40-slide deck and a quarterly planning cycle. It means being clear — genuinely, viscerally clear — about three things:

What problem are we actually solving? Not what we're building. Not what the roadmap says. What is the human problem at the centre of this work, and are we still solving it?

What does success look like? And not in a vague "users will be happier" way. In a "we will know we've done this when..." way. Concrete. Specific. Honest.

What are we not doing? In a small team, your capacity is precious and finite. The things you say no to are just as strategic as the things you say yes to. Often more so.

You don't need a framework for this. You need a clear head and about twenty minutes with a whiteboard. Do it regularly. It will save you from months of building the wrong thing with enormous conviction.

🤹 The Art of Wearing All the Hats

In a large organisation, a PM works alongside researchers, designers, data analysts, delivery managers, and a product ops person who organises the away days. In a small team, you are a PM who does research and design and analysis and delivery and is also somehow expected to be at the away day they organised themselves.

This is genuinely hard. I won't pretend otherwise.

But there are things that make it manageable.

Be honest about your edges. You cannot be excellent at everything. Know which hats fit well and which ones you're just about keeping on your head. Be transparent with your team about this — people would rather know what to expect from you than be surprised by what they don't get.

Make friends across the organisation. Small teams exist within larger ecosystems. Find the people in adjacent functions who have the skills you're missing and build real relationships with them. Not transactional — real. The informal network is what gets things done when you don't have the formal structure to fall back on.

Ruthlessly protect thinking time. In a small team, the operational pull is constant. There is always something urgent. If you don't actively carve out time to think — to step back, look at the bigger picture, and ask whether you're still pointing in the right direction — nobody will do it for you. Put it in the calendar. Guard it fiercely.

💚 The Part They Don't Tell You in the Books

Here's what I actually love about working in a small team.

The work is visible. When something ships, you can point at it and say "I helped make that." When something goes wrong, you can see why and fix it. There are no layers of process between you and the actual product.

The mission is tangible. I work in open science — on infrastructure that genuinely helps researchers share knowledge more equitably. In a large tech company, it is entirely possible to spend three years optimising a notification algorithm and never be quite sure whether the world is better or worse for it. That ambiguity doesn't exist in my job.

And the trust is real. In a small team, when you make a call, people generally let you make it. There's no committee, no sign-off chain, no three-month approval process. You are trusted to know your product, understand your users, and make good decisions. That's a privilege — and it's also, if you take it seriously, excellent training for being a better PM.

🧟‍♀️ A Word to the Small-Team Monsters

If you work in a small team and you sometimes feel like the PM frameworks you're learning don't quite fit your reality — you're not imagining it. They don't.

But that doesn't mean the principles aren't sound. It means you need to translate them. Take the ideas that are useful, leave the ceremony that isn't, and build a way of working that fits the actual shape of your team.

The vision doesn't have to be small just because the team is.

Go build something that matters 🌻.

Until next time, my product fiends 💀.

 

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 💀.

Go With the Flow: Why I Love Lean Product Management

I want to talk about something I genuinely love.

Not in the "this is a good professional framework" way. In the "I think about this on holiday" way. In the "I will corner you at a conference and talk about it until you either agree with me or flee" way.

Lean Product Management.

Now, if you've been following along on this blog, you'll know we've spent some time in Scrum territory — sprints, user stories, definitions of done, the occasional flying monkey. And Scrum is useful. It really is. But Lean? Lean feels alive to me in a way that Scrum sometimes doesn't. And I want to try and explain why.

🏊 The Swimming Pool vs. The River

Here's how I think about the difference.

Scrum is a swimming pool. It's structured, predictable, and safe. There are lanes. You know the distance. You know exactly when you'll turn around. Every two weeks, you touch the wall, you catch your breath, and you go again. For a lot of teams and a lot of contexts, that's exactly what you need.

But nothing wild lives in a swimming pool.

Lean is a river 🌊. It's always moving. It shapes itself around the landscape — around real obstacles, real constraints, real feedback from real users. It doesn't stop and restart on a fixed schedule. It just keeps flowing, finding the most efficient path, clearing blockages as it goes.

And things live in rivers. Ecosystems form. Stuff actually happens.

That's what Lean feels like to me as a way of working.

♾️ Continuous, Not Cyclical

The thing that changes everything about Lean is that it's continuous.

In Scrum, value is delivered in cycles. A sprint ends, a sprint begins. There's ceremony around the transition — planning, review, retrospective. All useful things! But the rhythm is fixed, and sometimes reality doesn't match the rhythm. Sometimes the most important thing to work on becomes clear on day eight of a two-week sprint. Sometimes a user tells you something on a Tuesday that should change what you're doing by Wednesday.

Lean says: fine. Change it.

There's no waiting for the sprint to end. No "let's add it to the backlog and pick it up next time." If something is the most valuable thing to work on right now, you work on it right now. The flow is continuous and the priorities respond to what's actually happening — not to what you planned three weeks ago.

This isn't chaos. Lean is not "make it up as you go along." It's something much more disciplined than that. It's a commitment to always doing the most valuable thing, with as little waste as possible, and with the full capacity of your team focused on moving work through to completion rather than starting lots of things and finishing few of them.

🗑️ The Beautiful Obsession with Waste

Lean has a word for anything that doesn't add value: muda. Waste.

Unnecessary meetings? Muda. Work that nobody asked for? Muda. Features that took three weeks to build and have never been used? Very expensive muda. Waiting. Handoffs. Rework. All muda, muda, muda. It is so fun to say, try it!

And I find this genuinely liberating. Because Lean gives you permission — no, it gives you a responsibility — to ask "why are we doing this?" about everything. Not destructively. Curiously. With the genuine intention of protecting the team's time and the user's experience from things that don't serve either.

In practice this means: smaller batches of work, completed fully before moving on. Limits on how much is in progress at any one time (because half-done work is worth nothing). A constant eye on where things are getting stuck and why.

It means your team spends more time finishing things and less time juggling things.

💚 Why I Love It

Here's the honest answer: Lean trusts me.

It trusts me to use my judgement about what the most valuable thing to work on is, rather than binding me to a plan made two weeks ago. It trusts the team to know when something is done, rather than waiting for the ceremony of a sprint review to say so. It trusts that the people closest to the work have the best view of what's blocking it.

That freedom — that flexibility to respond to reality as it actually is, rather than as you predicted it would be — is where I do my best work. It's where I've seen teams do their best work too.

Scrum is a great place to learn the shape of product thinking. The vocabulary, the cadence, the discipline of breaking things down. But Lean is where I feel like a product manager rather than a process manager.

It's the river, not the swimming pool. It's always moving. And I genuinely love it 🌊.

Until next time, my product fiends 💀.

 

Done is a Feeling (Until it Isn't)

 Picture the scene.

It's the end of a sprint. The developer closes the ticket. Someone marks it done. There is a small, collective exhale around the team. Progress! Victory! The thing is finished!

Except.

The QA person opens it the next day and finds three edge cases nobody tested. The stakeholder sees the demo and says "oh, I thought it would also do X." The user tries it in production and it breaks on mobile.

Was it done?

Technically, in the sense that someone moved a card across a board — sure. Actually done? Not even close. And this, my little product fiends, is the gap that the Definition of Done exists to close 💀.

🤔 What Is the Definition of Done?

The Definition of Done (DoD, because we love an acronym) is a shared, explicit agreement between your team about what "done" actually means for a piece of work.

Not what you think done means. Not what the developer thinks done means. Not what the stakeholder who commissioned the work thinks done means.

What the team — collectively, with all its members' hats on — has agreed done means.

This sounds obvious. It is, in practice, startlingly rare.

In the absence of a Definition of Done, every person on the team is operating from their own internal definition. And those definitions, I promise you, are not the same. The developer thinks done means the code is written and the tests pass. The designer thinks done means it looks right. QA thinks done means it's been tested in all the edge cases. The PM thinks done means it's shipped and users can access it. The stakeholder thinks done means it does the thing they imagined, which they now realise they didn't fully explain at the start.

All of these are valid. None of them alone are sufficient. The DoD puts them in the same room and makes them shake hands.

📋 What Goes in a Definition of Done?

This varies by team, by product, and by type of work — but here are the things I'd expect to see in a healthy one:

✅ Code complete — it's written, reviewed, and merged.

🧪 Tests written and passing — unit tests, integration tests, whatever your standard is. Define it.

🎨 Design signed off — does it match the spec? Has the designer looked at it?

♿ Accessibility checked — is it usable by the people who need it?

📱 Cross-browser / cross-device tested — yes, even mobile. Especially mobile.

🚀 Deployed to staging — it works somewhere other than a developer's laptop.

📝 Documentation updated — if it changes how something works, the documentation knows about it.

👀 Accepted by the Product Owner — someone with the authority to say "yes, this is what we asked for" has looked at it and agreed.

Your list might be shorter. It might be longer. What matters is that your team wrote it together and everyone refers to it.

🌱 Definition of Done vs Definition of Ready

Bonus content, because you stayed till the end and you deserve it.

The Definition of Done has a sibling: the Definition of Ready. Where DoD tells you when work is finished, DoR tells you when a piece of work is ready to start.

Think of it like a recipe. The Definition of Ready is your mise en place — everything chopped, measured, and on the counter before you start cooking. The Definition of Done is the moment you plate up and declare it a meal.

A Definition of Ready might include things like: the user story is written; acceptance criteria are defined; design is complete; dependencies are identified; the team has estimated it.

If a ticket doesn't meet the DoR, it shouldn't go into a sprint. Full stop. Pulling half-prepared work into a sprint is how you end up with a sprint full of "almost done" tickets and a retrospective full of sighs.

👷 Making It Stick

Definitions of Done only work if they're alive. A DoD written once, posted somewhere, and never looked at again is a decorative object, not a working agreement.

Revisit it in retrospectives. If something keeps slipping through that your DoD didn't catch, add it. If something in the DoD no longer reflects how you work, remove it. It should be a living document, not a compliance checkbox.

And — this is the bit that gets uncomfortable — use it. When someone says "it's done," ask: does it meet the Definition of Done? All of it? Not to be difficult, but to be honest.

Because the kindest thing you can do for your team is give them a shared standard to work to, and then hold that standard. Consistently. For everyone.

🧟‍♀️ From the Monster's Notebook

Done is not a feeling. It is an agreement.

The feeling is lovely — that little exhale at the end of a sprint or at release, the satisfaction of watching a card move across the board. I am not suggesting you abolish it. By all means, exhale. Move the card. Celebrate.

Just make sure, before you do, that you and your team mean the same thing when you say the thing is finished.

Because the only thing scarier than unfinished work is work that thinks it's finished 👻.

Until next time, my product fiends 💀.

Taming the Flying Monkeys: A Guide to Stakeholder Management

If you've been following along on our yellow brick roadmap 🟨🧱, you'll know we've already covered backlogs, user stories, and the art of breaking down work. Today we're venturing somewhere altogether more treacherous.

Stakeholder management.

Now, I want to be clear: stakeholders are not the enemy. They are not, despite what you might mutter under your breath after a particularly spirited "this should take five minutes" conversation, flying monkeys sent to destroy your sprint 🐒.

They are people. With opinions, pressures, deadlines, and — here's the important part — information you often need. The trick is learning how to work with that energy rather than getting swept off to a castle in the sky.

🧙 First: Know Your Cast of Characters

Not all stakeholders are the same. In my experience, you'll meet a few recurring characters on this particular yellow brick road:

The Wizard — senior, influential, occasionally behind a curtain. Doesn't always engage directly but their opinion carries enormous weight. Ignore them at your peril; over-involve them and they'll micromanage everything. Find the rhythm.

The Tin Man — wants to help but often doesn't know how. Full of good intentions, sometimes lacks the context to make them land. Give them structure and they'll be one of your greatest allies.

The Scarecrow — full of ideas. Wonderful, chaotic, sometimes brilliant ideas. Needs gentle focus and a clear "yes, and here's where that fits" or "not right now, and here's why."

The Lion — has the authority but not always the confidence to use it. Needs to be brought along on the journey, not presented with a fait accompli at the end.

You will have all of these in your organisation, probably in the same room, possibly in the same meeting. Good luck 🧡.

🗺️ The Map Matters More Than the Territory

The single most important thing I have learned about stakeholder management is this: people behave badly when they feel out of the loop.

Not because they're difficult (well, sometimes). But because uncertainty makes people anxious, and anxious people fill the gaps with assumptions. Usually wrong ones. Usually ones that create more work for you.

The antidote is communication. Not constant communication — that's its own problem — but consistent, predictable communication. A regular update. A clear signal when priorities shift. A heads-up before a decision lands, not after.

You don't need to consult everyone on everything. But you do need everyone to trust that they'll know what they need to know, when they need to know it. That trust is the road. Without it, the flying monkeys win.

🎯 Influence Without Authority (Or: You Are Not The Boss of Anyone)

Here's a truth they don't put in the job description: as a Product Manager, you have enormous responsibility and very little formal authority. You don't manage the developers. You don't manage the designers. You certainly don't manage the CFO who just had "a quick idea" that would "only take a week."

What you have instead is influence. And influence is built on three things:

Credibility — do you know what you're talking about? Have you done your homework? Do you explain your reasoning, or just assert your conclusions? Credibility is earned slowly and lost quickly.

Relationships — do people feel heard when they talk to you? Do you follow up? Do you give credit where it's due? This is the stuff that makes the difference between someone who fights your decisions and someone who supports them even when they disagree.

Transparency — do people know where things stand? Is your reasoning visible? Transparency doesn't mean sharing everything; it means not surprising people with things that affect them.

Get these three right and most stakeholder management problems quietly solve themselves.

💬 On the Difficult Conversations

They will happen. Someone will want something you can't deliver. Someone will disagree with a decision. Someone will send an email at 4pm on a Friday that begins "just a quick thought..."

A few things that have helped me:

Go to the conversation early, not late. The longer you wait, the bigger the gap between what someone expects and what's actually happening.

Separate the person from the position. They want what they want for a reason. Sometimes the reason is political. Sometimes it's personal. Sometimes it's actually very valid and you've missed something. Find out which before you decide how to respond.

Don't have the difficult conversation over email. Just don't.

And finally — be willing to be wrong. Some of the best product decisions I've been involved in started with a stakeholder pushing back on something I thought was settled. They were right. I updated my thinking. The product was better for it.

🌻 The Monster's Verdict

Stakeholder management is not a dark art. It is not manipulation. It is not politics (well, not only politics).

It is, at its core, the practice of building enough trust with enough people that when you do need to make a difficult call, you have the relationships to support it.

Find your allies. Respect your sceptics — they often have the sharpest questions. Keep the Wizard informed. Give the Tin Man structure. Channel the Scarecrow's ideas. Back the Lion.

And when the flying monkeys come — and they will — remember: even they were just following orders 🐒.

Until next time, my product fiends 💀.

The Art of Saying No (Without Becoming the Office Villain)

Let's talk about the word that makes most Product Managers break into a cold sweat.




No.




Not "not right now." Not "that's a really interesting idea, let me add it to the backlog" (translation: no). Not "we'd love to explore that in a future sprint" (translation: also no).


Just... no. Clean, clear, and — if you do it right — kind.


Because here's the thing nobody tells you when you start in product: saying no is not a failure of collaboration. It is, in fact, one of the most important things you will ever do for your team, your users, and your product. The monster in me would argue it's an act of love 💚.

🙅 Why Do We Find It So Hard?

Because we're people-pleasers dressed up as strategists, most of us.


We want to be helpful. We want stakeholders to feel heard. We want developers to think we're reasonable. We want users to feel like their feedback matters. All of those things are good — genuinely — but when "yes" becomes our default, we stop being product managers and start being feature factories. And feature factories don't build great products. They build bloated, confused ones.



There's also the fear of being wrong. What if this is the thing that would have changed everything? What if the stakeholder knows something we don't? These are real anxieties. I have had them. You will have them. They are, in the vast majority of cases, a distraction.

🧠 No Is a Strategy, Not a Rejection

Saying no is how you protect the yes.


Every time you commit to something — a feature, a sprint, a scope — you are implicitly saying no to everything else that could have gone in its place. The question isn't whether you're saying no. It's whether you're saying it consciously, with intention, or letting the yeses pile up until the whole thing collapses under its own weight.


Think of it like your product garden 🌱 (regular readers will know I enjoy a garden metaphor). You cannot grow everything at once. Some plants crowd out others. Some need the same soil and the same light. Choosing what to grow — and what to compost — isn't cruelty. It's gardening.

🗣️ How to Actually Do It

Lead with the why, not the what.


"No, we're not building that" lands very differently from "We've looked at this and here's the tension: building this now would delay X, which our heaviest users are blocked on. Here's what we think is the right call, and here's when we'll revisit." One closes a door. The other explains the map.


Use data where you have it. Use honesty where you don't.


"The data suggests this affects less than 5% of users" is a useful no. But "we don't have the data yet, and here's how we'd find out" is equally valid. What isn't useful is pretending you have certainty when you don't. People can tell.


Offer an alternative — but only if there is one.


Sometimes the right alternative is "let's revisit this in Q3." Sometimes it's "here's a lighter version we could test." Sometimes — and this is okay — there genuinely isn't one, and the honest thing is to say so. Don't invent alternatives just to soften the blow. That's not kindness; it's postponing the conversation.


Say it once. Say it clearly. Don't over-apologise.


A no buried in three paragraphs of qualifications isn't a no. It's an invitation to keep pushing. If the answer is no, say it. Then explain it. Then stop talking.

👾 The Part Nobody Warns You About

Sometimes people will be annoyed.


That's okay. It doesn't mean you got it wrong.



Part of the job is holding the line when the right decision is unpopular. Not stubbornly — always be open to new information, and be genuinely willing to change your mind when the evidence changes. But don't mistake pressure for evidence. Those are different things.



The PMs I have respected most in my career have been the ones who said no and explained why, rather than the ones who said yes to everything and delivered nothing. One of those is a collaborator. The other is a liability.

🌻 A Final Thought From the Monster

You are not the office villain for saying no.


You are the person who decided that the thing you are building is worth building well. That the team's capacity is finite and precious. That your users deserve a product that knows what it is.


Say no with honesty, with empathy, and without apology.


And then go water the things that are actually growing 🌱.




Until next time, my product fiends 💀.

Tending Your Product Garden: What a Backlog Actually Is

 

🌱 Tending Your Product Garden: What a Backlog Actually Is

Let’s start with what a backlog isn’t:

• It’s not a to-do list

• It’s not a guarantee

• It’s not a shopping list

• It’s definitely not a dumping ground for ideas (@nathan lisgo — you know who you are)

• And it’s not a place to send bad ideas to die (be kind — compost them quickly)

Think of your backlog as a garden.
Its purpose? To nurture and curate product ideas over time — letting them sprout, grow, be pruned, or pulled out by the roots if they don't belong. It’s a living space for:

• Information gathering

• Stakeholder conversations

• Early validation

• Prioritisation

• And a little gentle weeding

Do most teams do this well?
Honestly — not really. But I have a dream that one day we will.
And how do we get there?
Incrementally. Person by person. Ticket by ticket. 🌻

---

🧱 What Should Be in a Well-Tended Backlog?

Here’s your essential garden inventory:

• 🌼 User Stories: Little idea seedlings, written from a user's perspective, that describe valuable outcomes.

• 🪴 Tasks: Actionable steps — your spades and trowels — broken down from stories.

• 🐛 Bug Fixes: Nasty pests you need to catch early before they chew through your codebase.

• 🌿 Technical Debt: Roots tangled underground. You might not see them immediately, but ignore them too long and the whole thing becomes unstable.

• 🌱 Research Topics: Curious little sprouts. They might grow into features... or they might not.

---

🌞 What Should a Backlog Do?

A healthy backlog should:

• Prioritise: Focus on what’s ripe for picking. Not everything blooms at once, and your team's capacity (shudder, “resources”) is finite.

• Be Transparent: Like a well-labelled garden bed. Everyone — developers, stakeholders, the odd drive-by VP — should be able to see what’s growing, what’s in bloom, and what’s gone to seed.

• Adapt: Gardens change with the seasons, and so does product. Weather conditions (AKA market shifts, leadership whims, user feedback) matter.

• Stay Aligned: Don’t let your team start growing pineapples in a rose garden. Keep your product strategy front and centre.

---

🧑‍🌾 And Who’s the Head Gardener?

That would be your Product Owner or Product Manager — the one walking around with a clipboard, a watering can, and too many opinions about “value.”

They don’t do it alone. Good gardeners talk to everyone:

• Developers (to learn what’s feasible)

• Users (to learn what’s needed)

• Stakeholders (to learn what’s suddenly “urgent”)

• Competitors, data, and even the weather (ok fine, market trends)

---

🌻 Final Thoughts From the Garden Bench

So, dear Product Monster — be gentle with your backlog. It’s not a junk drawer or a to-do list from hell. It’s your product garden.

Nurture it. Prune it. Talk to it. Be ruthless with the weeds.
You’ll never get it perfect, but with love, curiosity, and a good pair of secateurs, it will grow into something useful, beautiful, and genuinely valuable.

Until next time — keep those ideas watered, those bugs squashed, and may your Product Garden bloom.

🧑‍🌾👾

User stories. But why?

 

User stories. But why?

Since the dawn of humankind, we have listened to and shared tales with one another , the best ones being scary, creepy bump in the night tales, which most definitely are true. Whether to teach or to entertain, storytelling is intrinsic to our mental wiring. Sure, we can produce manuals and list instructions but nothing cements in our lizard brains, quite like a tale well told. 

Some of you maybe old enough to remember project charters, heck some of you may have spent months writing them. For it to then be passed to a higher-up stakeholder to sign it off. And what does our higher-up stakeholder do? Ask a junior team member to read it and let them know if it’s ok to sign it off. For those of you haven’t experienced this, we actually got paid to do this merry little dance 💃.
The pitfalls are obvious (if they are not, comment below and we can tell that story at our next campfire gathering!🔥). I won’t bore you with them here, instead let’s discuss how to avoid said pitfalls and reduce risk. 

Keep It Simple, Stupid 💋

Product monsters are always tempted to provide more and more detail, from "Once upon a time, in a land far, far away..." to so much context we risk losing our audience. For our user stories we can strip the excess thrills and chills right back...

Stick to a standard template: 

As a [type of user], 

I want [an action], 

so that [a benefit/a value]. 

For example:

 "As a frequent traveler, I want to receive flight delay notifications so that I can adjust my plans accordingly." 

Maybe not the most engrossing story ever told but in a single sentence, we get it! Always adopt the user’s perspective. 

👱Utilise user personas:

The above example would be even better if we would refer to “Fred, our frequent traveller, wants to receive…” If you have done your persona work, you will know all about Fred and why this matters so much to him and this creates a real knowledge shortcut for your team and collaborators. 

👭Engage in Collaborative Discussions: 

Involve cross-functional teams—including developers, designers, and stakeholders—in conversations about user stories. Just like sitting around a campfire and sharing scary stories while toasting marshmallows. Except this time, you are removing fear, and risks are getting toasted as your storytelling shines a light in all the dark corners. This collaboration fosters a shared understanding of user needs and promotes diverse perspectives. 

💚Define Clear Acceptance Criteria: 

Establish specific conditions that determine when a story is complete. Clear acceptance criteria ensure that the developed feature aligns with user expectations and requirements. More simply put, define what "done" looks like, in this case we would start with:

"Fred doesn't have to log in to his his frequent flyer account as he receives a push notification telling him of a delay. 

Fred will continue to receive updates if the information changes further" 

and because you have collaborated with your team you will be able to provide technical definitions of what done looks like, which will guide developers. 

👷Break Down Stories into Manageable Tasks: 

Divide larger user stories into smaller, actionable tasks that can be completed quickly. This approach maintains focus on user needs while ensuring steady progress. The effort you put in during your campfire conversations and creation of done definitions will really feed in to this part of the work. You may have a team which would like this done up front as much as possible, or you may have more tenured team who prefer to slice, do, slice, do - one chunk at a time. Either is fine - providing that it works. You can experiment with your team, story telling, and task breakdown to find your team's optimal approach. 

👍Prioritise Based on User Value: 

Assess and rank user stories by the value they deliver to the user. Prioritising in this manner ensures that the most impactful features are developed first. 

🥳Iterate and Refine Regularly:

As with your product or team backlog, continuously revisit and update user stories based on developer feedback and changing requirements. Regular refinement keeps the development process smooth and makes those campfire stories a little less scary! Which brings us to the end of today's campfire tale. Not as scary as I normally I like my stories, but then I don't won't want to be scared at work! So my little product fiends 💀, until the next bump in the night...

Epics and features and tasks! Oh My!

❓ So many routes, where do they go? How best can I navigate through them? 

 You maybe wondering when to use a feature. Or an epic or a theme. You maybe wondering how long it is until you've finished work for the day (me too!). But for this venture into far off lands (Oz, I am ripping off Frank L. Baum today, fiends) you can get many answers and form many opinions on what is the “right way” to melt a woman break down work. The truth is, providing you are able to break down (or slice) work and everyone is aligned to, and, using the same language, it doesn’t matter - what matters is it works for your team and if it stops working, you can click your heels together three times and change your environment. 👠👠

 For clarity, I will summarise the terms most commonly used in technology development and provide a description. As a general rule of thumb, the bigger your organisation and the bigger the work is, the more levels are used. For example a technology department with 10 developer teams could have work broken down across 4 or more levels of hierarchy, smaller departments do not need the extra complexity so would be at home with 2 or 3 levels. 

💭Themes: These represent high-level strategic objectives or focus areas that guide the organization's efforts over extended periods, often spanning multiple years. Themes help in aligning portfolios with business strategy and investment priorities. 

💬Epics: Under themes, epics are significant initiatives that require substantial investment and development effort. They are large bodies of work that can span longer periods of time. Epics should be sliced definitively, unlike themes which are much broader. 

Epics can be further categorised and/or sliced if they are too big into smaller epics: 

🧕Business (or Functional) Epics: Customer-facing initiatives that deliver direct business value. 

🧰Enabler (or Non-Functional) Epics: Initiatives that support the delivery of business epics, such as infrastructure developments or architectural improvements. 

💡Capabilities: These are higher-level functionalities that could spark work spanning longer periods of time (sometimes the lifespan of a product). Capabilities are decomposed into features:

👀Features: Features are services or functionalities that fulfill a stakeholder need. They are critical components that enable the realisation of capabilities. 

💻User Stories: These are short, specific descriptions of functionality from the end user's perspective. User stories are small enough to be completed within a short span of time and are the building blocks for features. 

👷Tasks: Tasks break down user stories into actionable steps for the development team. They represent the smallest unit of work and are typically completed within a few hours to a day.   

In my team, we typically use Epics, Stories and Tasks but adapt as required to make the work more accessible for the DEVELOPERS. This is important as it brings all this gobbledegook to the why bother? Why do all of this? Essentially, what we want to do is click our heels and bring “it” home. As there is no place like home, we will get there more efficiently if we all know what we are doing, why we are doing it and how we are going to do it. 

Breaking work down like this, requires a brain 🧠, a lot of heart 💖 and sometimes a fair bit of courage 🦁. Thank you for joining me on this yellow brick roadmap 🟨🧱, I hope you continue with me. Just mind the flying monkeys 🐒. 

Enter the Product Monster's lair...

 

🧟‍♀️ Enter the Product Monster’s Lair

Welcome to the Ramblings

Hello, curious creature. You’ve just wandered into the lair of a Product Monster — a place full of mismatched metaphors, post-it ghosts, backlogs that whisper in the night, and a deep, unshakable love for the wonderfully weird world of product management.

If you came here for polished frameworks and TED Talk precision, you might want to back away slowly. But if you’ve ever found yourself spiralling about how to define a Story vs. a Task vs. an Epic while referencing The Wizard of Oz, or if you believe a backlog should be more garden than graveyard — then welcome. You’re in the right place.

🧠 Why Ramble?

Because product is messy.
Because clarity often emerges through chaos.
Because the best insights sometimes sound like overheard conversations between a slightly sleep-deprived PM and a talking whiteboard.

The Ramblings of a Product Monster is a space to capture those moments. Not case studies. Not retrospectives. Just honest, curious, occasionally feral thoughts about the strange, strategic, emotional work of building things for humans.

👾 Why “Product Monster”?

Because we all have a bit of monster in us.
The part that fights for users like a protective beast.
The part that hoards data and eats context for breakfast.
The part that snarls when someone says, “Can we just squeeze this into the sprint?”

This blog embraces that energy — the emotional reality of working in product, from the thrilling to the utterly deranged. And it gives that monster a voice.

🌻 What You’ll Find Here

• Product concepts, explained with storytelling and sass

• Themes you didn’t ask for, but will never forget (Wizards! Campfires! Gardens!)

• Genuine reflections from the product trenches

• Resources and rants, sometimes both at once

• A refusal to be boring, even when discussing capacity planning

🪵 One Last Log on the Fire...

This is a space for those who think critically, feel deeply, and occasionally shout into the void of JIRA. It’s for anyone who’s ever wanted to click their heels three times and land in a place where product makes sense.

I’ll share what I know, what I wonder, and what I still haven’t figured out — and maybe, just maybe, we’ll grow something good together.

Now, grab a cup of coffee, a pair of secateurs, and a torch for the dark corners of the yellow brick roadmap. Let the ramblings begin.

Until the next growl, spark or whisper...
🧟‍♀️💭