Initiative vs Epic – What’s the difference, and how do you use them?

Let’s talk about the difference between initiatives vs epics in the Agile product management world. We’re going to take a look at what they are, the relationship between the two, what the differences are, and when you should use each. From my point of view, that is.

First off, the key thing to keep in mind when talking about this sort of stuff is: It depends! The context of each term very much depends on what your team calls things. Don’t just go by an article you read online, even this one.

The terminology you use isn’t as important as having a shared understanding of what each term means, how they fit together, and how you go about using them. You need to keep in mind how your team organizes and talks about their work and try to make sure that you’re aligning with that.

Otherwise, if you want to make a change with how you talk about things to align with the best practices you read about here or elsewhere, make sure you’re bringing people on the journey with you so they understand why it’s important. For example, at ProdPad, what Jira calls “epics”, we call “Ideas”.

There are some general agreements about what defining what the differences are between epics vs initiatives are, though (of course) you may know them by different names. It’s also worth defining what we mean by objectives, as well, because they sit above your initiatives at the top of the hierarchy of your ideas.

What’s an initiative?

An initiative is generally a larger-scale effort that aligns with your strategic goals for your product or your business. Each initiative is most commonly based on a problem area to solve, an opportunity to tackle, or an area to go after.

People sometimes call them “themes”, but this term is a little bit outdated now. You’ll still hear people (even us, occasionally) talking about theme-based roadmaps because it’s such a common term.

But, as I’ll go into a bit more, themes have somewhat evolved into the concept of initiatives because there’s generally some confusion about whether themes meant objectives, which are not initiatives. Speaking of which…

What’s an objective?

In the ProdPad world, and as I’ve seen in lots of other companies out there, objectives represent your higher-level goals, sitting above your initiatives. They’re there to guide the Product team, to help them decide what they should focus on over a particular period.

Your objectives will have various initiatives that you take on to achieve them, and any one initiative might be linked to multiple objectives. Each initiative could help you move the right needles for your business by solving one or a few different objectives.

There are a number of different goal-setting frameworks that organizations subscribe to – for example, here at ProdPad, we’re fans of the OKRs (Objectives and Key Results) model. Other frameworks include Balanced Scorecard, BHAGs, Strategy Maps, and GSM. What all these frameworks have in common are top-line objectives – so whichever framework you favor and whatever terminology you use, you should have ‘objectives’ in the sense of the core pillars of your overall strategy – the most important things you want to achieve.  

What’s an epic?

Epics are at one level down from initiatives on the roadmap cards that you see in our famous Now-Next-Later (NNL) roadmap.

If the objectives are like saying “Why should we do this initiative?”, and an initiative is asking “What’s the problem we’re solving?”, then your epics are where you ask “How might we solve this problem?” Epics can still be considered large bodies of work, but they’re related to a particular feature, a particular solution, or a particular way of tackling things.

Your epics can then be further broken down into user stories, and once you have those user stories, you might even break those down into different tasks (though we don’t feel the need to get quite that granular at ProdPad). How you approach that is highly subjective and is based on how your team works and their suite of task management tools.

Epics should be experiments

When talking about where epics sit vs initiatives, I like to think of epics as experiments you could run. In the ProdPad world, we call epics Ideas (and those Ideas sync directly with JIRA epics). But I like the term “Idea” because it’s pretty all-encompassing for the number of different things that an Idea could be.

It’s a potential solution, or it’s a new feature, or it’s a change in pricing or packaging. By thinking of your epics/Ideas as experiments, you’re actually outlining what might be done to solve a particular initiative. “Will implementing single sign-on reduce friction on our sign-up page? Let’s find out!”

I also like the term “experiments” when talking about epics, because an experiment could be something like building a feature, which might be a great way to solve a problem. But the best way to solve that problem could also be to take away a feature or change a feature.

By looking at your epics and Ideas as experiments, you’re not constantly driven towards just having a bunch of features on your roadmap, and building new stuff all the time. Rather, you’ve got the flexibility to find new, innovative ways to solve your customers’ problems. Your roadmap itself can then act as a tool for experimenting.

It’s about understanding what you already have and adjusting that. You want to find ways that you could solve those problems for your product, your business, and your customers… and that doesn’t necessarily just mean having to create new code!

Can epics span multiple initiatives?

Epics normally fall under one initiative. That said, you might have an epic that is related to multiple initiatives for various reasons. Perhaps part of that epic solves for the desktop version of your app, while another part of it solves for the mobile –  you could have those as two different initiatives on two different roadmaps.

Generally speaking, though, you have initiatives covering wider time spans, and then the epics underneath relate to those initiatives. But here at ProdPad, we’re not dogmatic about it! If you have a reason to connect an epic to multiple initiatives, then you can put it in there and do just that. That way you can work on one epic and make progress against multiple initiatives. 

How do larger initiatives fit into your roadmap?

While an initiative could be big enough to span various time horizons, you would typically look to either bind it to just one or break it up into smaller pieces that still represent initiative-level stuff.

If you’re looking at an initiative that’s going to take you the whole year, then sure, you could just make it one big initiative, with all the things that you’re going to tackle… and it’ll just be super slow moving. It’ll be stuck in the Now column for quite some time because it’s a big thing to take on and you’ve got to take your time over it.

What often makes more sense is to take that initiative and articulate it into three or more smaller initiatives. You might call each part V1, V2, V3, and so on.

You might say for V1 you want to create the space for somebody to join this new community you’re building. And then V2 is about having people expand their usage of that community. And then V3 is about monetizing the usage of it.

It’s a more effective approach than just having an initiative saying “build a profitable community” – it’s too big. In this situation “build a profitable community” might actually be your high-level objective that feeds into all of those initiatives.

In ProdPad you can use tags to link those initiatives together, and that way you can filter down, and even create a version of your roadmap that just looks at that initiative. You can get an expanded view of the initiative, and all the objectives that are tied to it, all in one place.

How do you ensure that your initiatives and your efforts are aligned with your business goals, customer needs, and objectives?

By cascading things down. You should be able to read your roadmap from the top down and bottom up.

A big hat tip here to Martin Eriksson’s work on the product decision stack – As ever, the terminology differs, but the concept is simple and effective, and is a good way to visualize where your initiatives sit vs your epics.

You have your vision, your strategy, and your top-level goals. Below that you have your initiatives, then you have your epics, and finally, you have the user story-level stuff. The idea is that you go down the ladder from one level to the next, simply asking “How?”

Say your objective is to get more revenue.

Okay, how? Build a profitable community. – There’s your objective.
Okay, how? Start by building this part of it – There’s your initiative.
Okay, how? Well, let’s start with this experiment. – There’s your epic.

It also climbs up the ladder too, by asking “Why?” 

Why are we doing this login field? Because we’re building the front-end of our community… and so on up the ladder again. It’s a great way of understanding and communicating how and why you’re doing what you’re doing.

It also helps people align around how what you’re working on is going to impact the right areas of the business, and it allows you to show your work at a level of granularity that’s appropriate to the stakeholder you’re talking to.

Your execs probably don’t care about your epics, they don’t care about the future-level stuff. But they do want to know whether that initiative is making progress, whether that initiative is happening now, next, or later… But really, it’s about how that reflects back to the overall goals.

They don’t care that you’re working on features, they just care that you’re making an impact, so show them the level of work that will speak to that. 

How should you prioritize your initiatives vs your epics?

It should all be driven by the business outcomes, the business objectives, and the outcomes that are desired. So this actually takes a different turn.

Other product management tools (mentioning no names) call themselves “customer-driven” or “data-driven” or, you know, “whatever-else-driven”. I’d argue that the point is not to be driven by these things. It is to be informed  – by data and by your customers.

Ultimately, you should be business-driven, objective-driven, or outcome-driven (which is the term that I like to use).

What that means is making sure that your outcomes, the things that you’re doing, align back to the overall company goals, which is why the Now-Next-Later framework is so powerful.

What Now-Next-Later allows you to do is to very easily capture your high-level goals and objectives as they relate to your initiatives and vice versa. And then to break those down into how you’re going to do those and how you’re getting on with that, which is your ideas and the workflow status information.

You’re able to get that all visible on one page, so if anybody’s wondering what you’re working on, why, and how it’s going to impact things, it’s there at their fingertips.

Show your work!

ProdPad is the only tool that directly connects your Now-Next-Later initiatives to your OKRs. That’s really helpful because you need to make sure that the work that you’re doing, the initiatives, and the epics that you take on, are actually going to contribute to that all-important level of business goals. Whether you’re trying to build the bottom line or to get market share or whatever is important for your business, you need to be able to show the work that you do.

That’s why ProdPad has a view that shows your completed initiatives and epics (Ideas). Not only are you able to outline what you’re actively working on and what you’re seeing in the future for your initiatives and their related epics, but you can show off by saying “Here’s what we’ve already done, and here’s what we got out of it.”

The Completed area of your roadmap shows you quite clearly what’s been worked on, and what worked and what didn’t. It’s just as important to show what didn’t work for your initiatives as what did work. It’s a little bit like math class, when you still get half the points for showing the workings, even if you didn’t get the answer you were looking for.

If you want to be outcome-driven, it’s essential to be able to look back on what you did and say whether you got good outcomes or not. It helps provide transparency and it helps to prove the ROI of your Product team, which is especially important in today’s world when businesses are becoming more and more focused on showing how you’re contributing to the bottom line.

Your product is not just a sum of the features that you’ve launched or the features that are in there. It’s a sum of all the learnings that you’ve had that have led to you choosing the right features for now and for later.

Don’t be afraid to fail, and importantly, don’t be afraid to communicate your failures. Do not sweep your failings under the rug.

Themes are out, initiatives are in

As I mentioned before, the term “initiative”, in its current context, is a newer concept that’s started to solidify around what people have previously been calling themes. “Themes” is a very popular term in the Agile world, but it can easily be misconstrued. Even theme-based roadmaps are falling out of favor and initiative seems to be taking its place.

You could call it an initiative-based roadmap, but people don’t call them that (probably because that’s just way too many syllables!). Hey, though, I don’t want to invent another new term!

Even a very popular roadmapping book I wrote the foreword for in 2017, Product Roadmaps Relaunched, talked more about themes as a concept. But, over time, the words we use evolve, right? We’ve learned some stuff in the last seven years!

Using initiatives vs epics in the real world

Here’s a direct example for you: on ProdPad’s public roadmap, we break things into initiatives and Ideas (AKA epics as we’re talking about here). I have seen literally thousands of people move towards this way of working – having a roadmap that lines up your initiatives and your epics as opposed to having a feature-led roadmap.

And that’s not just our users. I talk to a lot of people who are trying to get away from timeline-based, feature-led roadmaps, to move into a more Now-Next-Later style. In fact, we created a course on that very subject since we were always being asked how to make the transition from timeline to Now-Next-Later. You can see just by the popularity of the Now-Next-Later framework, and how people are thinking more about initiative-level stuff, that it’s had an astounding effect on how people are working.

Another big hat tip here to Teresa Torres’ Opportunity Solution Tree, whom we had a great chat with for one of our webinars. It’s a great way to work out a hierarchy for your ideas, which then maps to your initiatives and epics.

It doesn’t necessarily mean that you do everything you come up with when making your tree, and call everything that you pull out of the top of it an initiative, and therefore everything under it is an epic… But these are certainly things that could become candidates for it.

Initiatives vs epics – A rose by any other name…

So, my final thoughts on initiatives and epics:

• Make sure to use them!
• What you call them isn’t as important as how you use them.
• Don’t think of epics as just features to build but as experiments to conduct.
• Make sure that everything you’re doing is linked back to your objectives. 
• And if you’re using ProdPad, don’t forget to integrate it with Jira, or whatever dev tool you’re using!

I hope this run-through of my personal take on initiatives vs epics has helped you to reach your own understanding of how it fits with your product, and how your team can use them more effectively.

If you want to learn by doing, I’d highly recommend taking our live Sandbox for a spin, so you can see how it all fits together in terms of your initiatives vs your epics, how they help you realize your strategy, and how ProdPad can make you a better Product Manager.