Before detailing the exact user stories for the feature, it is worthwhile staying a bit to think high-level about the contours of the solution and what is needed for it to make sense.
Start lean, then build from there
Once you have articulated the problem to solve, if you have a solution in mind, write the overview of the intended approach to solve the problem. Maybe a comparison of a few different solutions.
A problem without a solution
If you do not have a single hypothesis for how to solve this problem, it might be too early to think about it as an "epic". To get to the point of having a solution it can be helpful to go back to the problem section, add an opportunity tree, and have a problem solving session with team and stakeholders.
A solution without a problem
Do not move ahead and spend time thinking about a solution where you cannot articulate the problem and what you are trying to achieve with it. If you find yourself in that situation, go back to the problem section and think some more.
Headings consider adding
As you dig deeper, and depending on the type of epic you are working on, consider adding more details. Below are some of the headings that may be relevant to add.
Structured evaluation and discussion on alternative solutions to the problem. When working with this, it is helpful to work with the bullet tree to structure the thinking into distinct options with explicit pros and cons.
Show the path a prototypical user takes on website or app to complete a task.
Understanding the current user workflows, both within your product and between uses, and try to make sure the solution makes them more effective, e.g. by unlocking roadblocks in their flow. The idea is that by helping your users they will like your product and come back. Learn more on how to do this really well in the book Badass: Making Users Awesome by Kathy Sierra.
Simple drawings of a solution that can be used as a basis for discussions with both internal and external stakeholders.
Designs for the development team to use as reference when building the solution. Once you have reached this point, it is often to add the designs to the document, e.g. using a Figma embed.
Before moving ahead with any major development effort, it is worthwhile considering and tackling the most important risks, so that you do not end up having failed to deliver product value. A good mentality to have when in validation is "trust, but verify". Whether you came up with the solution yourself, or someone handed it to you, try to think: "Ok, so this might make sense, but I just want to make sure".
Specifically, it is worthwhile considering and tackling four types of risk.
- Value - Describe the evidence that customers would pay for and users choose to use this idea. If not solid, investigate.
- Usability - Describe knowledge of users' ability to figure out how to use this solution. If not known, investigate.
- Feasibility - Describe certainty of estimates for how time-consuming it would be for our developers to build this. If unknown, investigate.
- Business Viability - Describe perspective on how this solution will work with different aspects of our business model? If not clear, investigate.
Often you can learn a lot from looking at how a couple of your competitors have solved this problem. A simple way to do this is to map the user flow through their app, with screenshots from each step of using the feature, and then evaluate the benefits and drawbacks with their solutions.
Written description of how a user will perform tasks on our website or app. Here it is often helpful to consider both the main use cases, and edge use cases, e.g. skipping or trying to go back in the flow, new users vs experienced users, etc.
It is often helpful to consider what actual data the actual user is likely to work with in their use case, and to make sure that works well and looks nice, considering e.g. empty states, super long texts entered, etc.
Links to other epics that either depends on this epic, or that this epics depends on, or that is somehow related to this epic.