21 Mar 2022
Initiatives, Opportunities, Features, Epics and Stories - What Is the Difference Anyway?
Product ManagementNavigating vocabulary in the product world can be tricky. There is no standardization in terminology, which makes communicating with stakeholders that much more difficult. What means something in one team can mean a different thing in another, and this often drives wedges when trying to align.
I’d like to explore today some core terminology in product, particularly around ‘item types.’ By understanding their origin, meaning and how to use them, hopefully we’re able to find a bit more alignment together.
Let’s get started!
TLDR
There is a mesh of product terms and development terms that often cause confusion.
Output-driven terms for outcome-driven teams make no sense.
Features are not an ‘item type’, they are a functionality your product offers.
Epics often translate to opportunities for product people.
Stories are used by both teams, but you should always take the time to understand the problem first.
Context matters in conversations.
Break up your product and development backlogs to speak the right words to the right people.
Product terms vs development terms
Before we even get to what the specific terms are, let’s take it from the top.
For many product teams, their specific item types actually come from development terminology. Product teams have started developing their own terminology, but often default to having to change it because they need to communicate with both stakeholders and teams, and that’s where things start to get dicey.
The ones I want to explore today are:
Features
Epics
User Stories
These are all very output-driven item types that don’t always correlate with the way product teams work, which is what really drives the wedge and causes so much confusion.
Features
I want to be blunt here and say “feature” shouldn’t be an item type - not ever, not for anyone.
A feature is a functionality your product has, and it is an ultimate type of output. In the context of your business, a feature is something that solves a problem for your customer.
When we’re talking about product and outcome-based methodologies, a feature is an aspect of your product. But product managers should never start with the output, they should start with the outcome.
So with that in mind, a feature is something your product offers, an aspect of your product that solves a problem, and a distinctive functionality that serves a purpose and differentiates you from your competition.
Say it with me: a feature is not a backlog item type.
Having “feature” as an item type in your backlog distracts entirely from having an outcome-based approach and silos you back into outputs. It causes more damage than anything else.
If you truly want to escape the build trap, drop this item type entirely.
Epics
An epic is for product people what we know as a problem to solve.
Epic is the term for the problem you have already defined, assessed and is ready to hand over to your development team - but that’s not where the story gets started.
Product managers start out with opportunities.
An opportunity is a much looser term, giving you room to understand the problem, come up with a hypothesis, and run experimentation.
Once you have understood the requirements for what needs to be done, you pass it on to your development team as an epic and break it down into stories, which takes us to our next item type.
User stories
I can’t actually argue against user stories at all, except to say don’t jump the gun and start writing stories before you’ve understood what the problem actually is.
User stories are above all, a planning tool.
They allow you to break up what needs to be done by adding focus to what the user needs to accomplish.
User stories will go under epics, so that once you’ve understood what problem you are solving, you have a way to plan how you will actually do it.
Bonus item type: Initiatives
Initiatives are usually a term that will translate loosely to what other teams know as projects.
I usually recommend that teams express projects as potential problems to solve, instead of features to be built. (Remember, don’t fall into that build trap!) They can be framed as a hypothesis or opportunity (How can we do x, in order to achieve y….)
Initiatives group a set of opportunities and stories together so you can understand what and why you are working on things and will link back to a set of objectives.
Which terms should I be using?
Aha! If you thought I wasn’t going to say ‘it depends’ - you were wrong.
Of course it depends, and it will depend on who you are having that conversation with.
Features are for customers, presented as benefits.
Initiatives and opportunities are for your stakeholders and business-facing teams.
Epics and stories are for your executing teams (designers, developers, engineers, etc.)
I also generally recommend breaking up ‘item types’ based on what and where you are presenting these things.
Features are for your battle cards, documentation, and website.
Initiatives and opportunities are for your product backlog.
Epics and stories are for your development backlog.
The only somewhat debatable item here are stories, as I am a fan of having a single source of truth. If you are able to get your development team to use your product tool to write stories, fantastic. If not, it’s ok. There isn’t a cut-and-dry rule here.
What is important is that you are able to get your team aligned, that you’re able to keep things transparent, and that the right team is able to find the relevant information with ease to avoid confusion.
Thanks for reading!
Andrea Saez
Read also
Experience the new way of doing product management
