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