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...
🧟‍♀️💭