Despite your best efforts, it is quite likely that risks and rabbit holes will abound and threaten the release date for any new feature, initiative, or solution that your team is trying to ship. As a product manager, it is not only your responsibility to anticipate the risks or rabbit holes that might affect the ability to ship on-time.
Other than delaying shipping dates, risks and rabbit holes may also introduce bugs and breaking changes in your product, decreasing the overall usability and likeability of your product.
Having a central location where you can capture risks, as well as plans and procedures to mitigate them, is an effective way to focus the team. It’s also an effective communication piece with other teams and stakeholders in the company, assuring them that you’re taking the appropriate steps to limit or mitigate any mistakes, errors, or concerns.
In this article, I’ll cover what I mean by risks and rabbit holes, the common types that might affect the delivery and efficacy of your release, and also walk through a simple and easy-to-use risk register template. The template can be used as the central location for listing, communicating, and discussing different types of risks and steps to resolve them.
As you’ve probably noticed, I used two different terms to describe two different kinds of issues that might arise: risks and rabbit holes. Although both sound similar in some respects, their definitions veer and differ ever so slightly:
| Term | Definition |
| Risk | These are the known issues that will affect the delivery of your project within the budgeted time frame |
| Rabbit hole | These are the unknown issues — such as technical implementation ambiguities, design feasibility issues, or misunderstood dependencies — that might derail the project due to the time needed to investigate the feasibility and eliminate ambiguity |
Because these two different “types” of risk exist in a project, you mustn’t just capture and understand the known ones that your project might suffer from. You have to also understand the rabbit holes (also termed as the “known unknowns”) that your team anticipates or guesses may cause an issue down the line. With rabbit holes, the team won’t be too sure about them unless they take the time to investigate them further.
Both types of risk can easily be captured, discussed, and organized into a table known as a risk register.
As the name suggests, a risk register is a single location where all the known risks and rabbit holes that can affect your project are accumulated, considered, and dispatched. The goal is to either investigate or rectify them in the short-to long-term. A risk register forms a crucial part of many different types of product management documents and templates, from discovery docs to written epics.
The best time to create a risk register is during the discovery and planning stage of the product development lifecycle, i.e. when your team is just starting to break ground on what to build next and are shaping high-level options for the proposed solution.
Whenever a solution is being formed or a new feature is being built, a discussion about risks and rabbit holes should be an equal priority. These need to be talked about in the problem statements or the associated user stories to build out the said features.
After setting up the risk register, don’t stop there! A risk register should be as up-to-date as possible. It’s important to manage risks throughout the entirety of the product delivery process, and rabbit holes always appear when you least expect them.
As a product manager, it is your responsibility to ensure that the risk register is up-to-date and that the team identifies rabbit holes throughout the product delivery process. It’s also your responsibility to be a committed communication piece to both internal and external stakeholders. Your job is to relay the nature of the risks and how they impact the delivery of your new feature.
A comprehensive risk register should have the following components:
| Component | Description | Example |
| Date raised | This is the date that the issue is raised. Although this sounds like a basic requirement, it can be a crucial element to include when, exactly, the issue was brought to the team’s attention.
This helps the team gauge not only how long the issue has been open, but also helps provide “breadcrumbs” via time stamps. |
23 December 2022 |
| ID | This is a unique ID attached to the risk. It can be in any format — the purpose is to assist the team to find and reference this risk or rabbit hole in the future.
Follow any naming or identification convention used in the organization. |
ID: 123456 |
| Product area | This is part of the product affected by the risk or rabbit hole. This can include any frontend elements that may be affected (e.g. misaligned columns, errors in spelling, navigation issues, or any other breaking changes) or any backend systems and dependencies that could also be affected.
Optionally, this can be changed to include the specific actions in your user journey that might result in an error. |
Login page
Profile page Messaging page SQL database Submitting a form Sending a friend request Typing out a message |
| Description | This is a description of the risk or rabbit hole that is or could be affecting your product. This can be formal or informal — the most important thing is that it communicates the reader what the problem is and why it exists. | New features may cause incorrect information to be displayed on the profile (e.g. name, age, etc.). This could be due to the new CSS code that we’ve injected into the branch as part of the new feature. |
| Type | Classify the issue as either a risk or a rabbit hole. Read above to see how to differentiate the two. | Choose one of the following:
|
| Probability | Based on discussions with your team when the risk or rabbit hole is raised, consider the probability of it occurring from the implementation of your new feature.
How you determine the probability of this risk or rabbit hole is up to you and your team. If it’s a technical risk or rabbit hole, consult your senior and/or lead engineers to understand the issue better. If it’s a frontend or design issue, lean more on your frontend developers or product designers for their discernment. However you decide, make it clear whether the risk or rabbit hole will or will not happen if and when implementing the new feature into your product. |
Probability uses a five-point scale as follows:
|
| Impact | Here, impact means not just how many customers could potentially be affected by the risk or rabbit hole, but also how deep the impact would be for said customers as well.
Again, this should be discussed within your team and the classification of the impact should be determined by various subject matter experts. |
Impact follows a five-point scale as follows:
|
| Investigation | (OPTIONAL) Where the issue is classified as a rabbit hole rather than a risk, ensure that someone on your team is in charge of investigating — whether in the form of a spike or otherwise — to determine the following:
|
Spike shows that this will only appear for profiles created after a certain date |
| Priority | Based on the type of issue it is, the probability of it occurring, the expected impact on customers, and the results of the investigation if it is a rabbit hole, the team can set a priority for when and where they want to tackle it during a sprint while delivering the feature. It can also happen during the quarter if there are lines in the sand for the delivery of the new feature.
Risks should then be addressed based on the priority assigned to them and systematically completed by the team on a sprint or quarterly basis |
Priority follows a six-point scale as follows:
|
| Response | This forms the basis of either the next steps to mitigate or monitor the risk and or rabbit hole, or it can be concluded as a known risk or rabbit hole that won’t be fixed. This is possible if it’s high complexity, low probability, or a low-impact scenario.
The response should be framed as action points that your team can follow in the future when implementing the fix. It’d be the main source of attention for other stakeholders who may read or refer to your risk register. Ensure that the language used here is clear, concise, simple, and to the point. |
Examples include:
|
| Owner | Finally, allocate a risk or rabbit hole owner to the ticket to ensure that there is a directly responsible individual (DRI). Someone on the team can refer to them when needed. | Ian Khor |
You are the product manager of a team within a social media giant. Your team is looking to introduce a new way of logging into your product via third-party authentication methods. However, during the initial discovery and design of the feature, your team finds several risks and rabbit holes that may or may not derail the completion of the feature on time, if at all.
Take the following steps so that you are fully utilizing the potential of the risk register.
Take time to record the issue as and when the team raises it, including the following:
Take the time to ask the team about the issue, what is being impacted, any assumptions or legacy knowledge they may have, and provide a quick, summary description shareable with the rest of the organization.
This information will populate the “description” section of your risk register.
In addition to the description of the issue provided by your team, discuss whether this issue has a known problem and solution (a risk), or whether the problem is known but the solution is muddy or unclear (rabbit hole).
If the issue is a rabbit hole, investigate it fully — whether via a spike or otherwise — to determine the questions we have the answers to and ones that we can only answer once we implement the new feature.
When allocating a member of your team to investigate, ask them to timebox their investigation based on the severity of the rabbit hole. Spending too long on an investigation about an unknown rabbit hole is itself a rabbit hole! Once the timebox is done, get them to report their findings about the following:
Fill in the priority, response, and ownership sections of the risk register based on the team discussion and investigation results.
I’ve created a risk register template free for use! You can make a copy or download it from Google Sheets to customize and use it for your own projects:
Google Sheets risk register template.
Use the above tips and you’ll be creating your own risk register like a product manager in no time! If you’d like me to review your resume, please feel free to visit me on Superpeer here or view my online portfolio at www.iankhor.com
Thanks for reading!
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
It’s important to distinguish between these roles and create an infrastructure where they come together to build useful products.
At its core, product lifecycle management (PLM) software is a tool designed to manage every aspect of a product’s lifecycle.
Scenario analysis is a strategic planning tool that helps you envision a range of possible future states and the forces behind them.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
