How do you make sure your organization is not overloaded with too many projects, too many ideas, and too little focus? And how do you ensure you are building the right thing? This is exactly what epics are for. In this video, I walk through the concept of epics, show you a concrete example, and explain why epics are far more effective than traditional projects.
What Exactly is an Epic?#
An epic is a large body of work that needs to be broken down into smaller pieces for implementation. One or many teams work on an epic, and every epic has a title, an owner, and a description. The size of an epic should be bigger than three months but smaller than nine months, because we want to evaluate the hypothesis behind it as fast as possible and bring value to the market quickly.
The key to an epic is the epic hypothesis statement. This is not just a description of what to build. It is a structured pitch that makes everything clear: for which customer, who wants to do what, our solution is something that provides a certain kind of value, and unlike any competition, our solution does it better. With such a description, it becomes very clear what the epic is for, what customer we are serving, and why.
Even more important: we need to define measurable business outcomes and leading indicators. These are not lagging indicators that tell us after the fact. Leading indicators tell us as early as possible, even during MVP development, whether our hypothesis is true or false.
The Life Cycle of an Epic#
The life cycle works like this: a bright idea comes from the business or from customers. We capture it using the epic hypothesis statement and put it on the product backlog. When there is enough capacity, we build a minimum viable product (MVP), which is the minimum we need to build to prove or disprove the hypothesis.
Then we evaluate the hypothesis based on leading indicators and business outcomes. If the hypothesis is true, we continue developing more features and re-evaluate. If the hypothesis is disproven, we decide: do we pivot with a new adapted epic, or do we stop entirely? This model is also used by many successful startups.
A Concrete Example: Swiss Dentist#
Let me walk through a fictional example. “Swiss Dentist” is a company with offices in all major Swiss cities. The CEO, Dr. Hans Muster, has a bright idea: a mobile app for customers to schedule and manage their dentist appointments.
The epic hypothesis statement looks like this:
Epic Name: Mobile App for Dentist Appointments Epic Owner: Dr. Hans Muster Description: For Swiss Dentist customers who want to schedule a dentist appointment, the Swiss Dentist App is a mobile application that provides the ability to schedule appointments, reschedule appointments, and search for locations. Unlike AAA-Dentist (the competitor), our solution keeps customers informed with automatic notifications.
The business outcomes: majority of appointments scheduled via the app, decreasing call centre volumes, and better customer experience. The leading indicators: less call centre activity regarding scheduling, and an increase in overall appointments due to automatic notifications.
The Power of the Pivot#
Here is where it gets interesting. For the MVP, we chose a paper prototype. We went to real customers and asked: would you download and use this app? The majority said: “Not another mobile app! I have too many already. But if it were a web application, I would happily use it.”
The hypothesis was disproven. But we did not lose months of development. We pivoted, created a new epic for a web application, and went through the cycle again. After building and rolling out the web MVP, the data showed clear improvement: call centre volumes decreased, web-scheduled appointments increased, and overall appointments grew. All of this was visible early, during the MVP stage.
This is the big advantage of using epics: you can evaluate an idea very early and make informed decisions before investing heavily.
Project vs. Epic#
The comparison is striking:
- Scope: Projects have fixed scope with a list of deliverables. Epics have variable scope defined by business outcomes and leading indicators.
- Measurement: Projects measure output (features delivered). Epics measure outcome (hypothesis proven or disproven).
- Time Frame: Projects have fixed start and end dates. Epics run until the hypothesis is validated and business outcomes are reached.
- Implementation: Projects typically use waterfall or “water-scrum-fall.” Epics use agile methodologies.
- Teams: Projects use temporary, staffed teams. Epics use stable, cross-functional teams working on a backlog.
- Budget: Projects have fixed budgets. Epics use funding across value streams.
- Operations: Projects throw results over the wall to operations. Epics include the whole operation lifecycle.
Why We Should Use Epics#
Usually what happens in organizations is this: we have many bright ideas and we want to develop all of them. But we forget that we are completely overwhelming and overloading our development teams. Some ideas are great, but others should never be developed. The result: technical debt piles up, quality decreases, and the really good ideas do not get the attention they deserve.
With epics, we apply discipline. We create the hypothesis statement, define business outcomes, identify leading indicators, build an MVP, and evaluate quickly. If the hypothesis fails, we pivot or stop. If it succeeds, we continue and re-evaluate. This ensures that development teams can concentrate on the right features and build the right thing in the right way.
Key Takeaways#
- Epics are hypothesis-driven. Every epic starts with a clear hypothesis statement that defines the customer, the solution, the value, and the competitive advantage.
- Leading indicators are essential. They allow you to validate or invalidate a hypothesis as early as possible, not after months of development.
- Build an MVP first. The minimum viable product is your fastest path to learning whether an idea has merit.
- Pivot or stop without guilt. Disproving a hypothesis early saves time, money, and team capacity for the ideas that truly matter.
- Epics beat projects. By focusing on outcomes instead of outputs, epics prevent team overload and ensure you build the right thing right.