Scenario 3: Before starting the project, you identify risks that might arise during the development phase. Your partners ignore it and give you a go-ahead. Months later, when you start facing technical issues and convey it to them, your partners don’t remember the conversation you had at the beginning of the project.
Scenario 4: During knowledge transition sessions, you share everything that you know about the product’s development history. But you fail to remember when and why this decision came into existence. It’s difficult to recollect exact conversations that led you to take this decision. It’s all in the email threads but even those emails are hard to find.
Do you feel deja-vu reading the above scenarios?
I do. I have lost count of the times I’ve faced these scenarios. I am sure you would have faced them too sometime in your career. It’s not that I haven’t tried anything to overcome these challenges. I have tried different things apart from discussing over calls with our clients/partners-
- Mentioning all the important decisions in emails
- Mentioning all risks in the initial proposal
- Mentioning new risks in the emails as they come
- Sending MoMs with a defined structure- discussions, decisions, action items
- For any kind of technical decision, attaching an analysis document in the respective JIRA ticket and adding a comment with the final takeaway.
But, the truth is, as the product grows and the team expands, searching emails for MoMs and referring to JIRA tickets doesn’t make the cut.
Especially if you are working on a big project that goes on for years. After a time, recovering JIRA tickets and long email threads feels like digging the Earth for a dead body. I myself have faced this while recalling why we decided using Inspectlet over Fullstory? Or, why did we decide to push the MVP deadline?
So, what’s the solution?
When I started looking for a solution to this problem, I discovered that I am not alone. A lot of PMs face this problem. Thankfully, there’s a solution to tackle this problem. A product manager can maintain registers/logs for a product that can help him/her remember important product decisions. These two logs are-
- Decision log
- Risk log
Decision log
A decision log is a centralized list of all critical decisions taken throughout the product’s life cycle. It can be a business decision impacting the delivery, a technical decision, a process decision or a people decision.
This helps in effective communication in the present and then in future for recall times in conflicting situations.
What goes inside a decision log?
- What is the decision about?
- When was the decision made? (Date)
- Why this decision? Pros and cons, if any.
- Who are the contributors? Who is the approver?
- Outcome of the decision?
- When the decision was proposed?
Risk Log
It would be a centralized list of all potential risks and issues identified throughout the product life cycle. This includes all the information of the identified risk – nature of risk, level of risk, mitigation etc.
Many times, we maintain the product risk log for internal purposes only. But, keeping it open with all stakeholders really helps.
What goes inside a risk log?
- What is the actual risk?
- What is the impact of the risk?
- When was this risk identified?
- What is the impact level?
- What is the probability level? (PB Level)
- Priority level (PR level) = Impact level * Probability level (PB Level)
- Who is the owner?
- Are there any mitigation notes?
- What are the recent updates?
When to list a risk?
All the risks should be identified and communicated to the stakeholders using the Risk Log itself right at the beginning.
After that, risk identification should be a recurring activity. You can make it a part of your sprint rituals – sprint planning, retrospective or even in your daily scrum meetings.
Risks can be identified by anyone – Stakeholders, Leads, PMs, Designer, QAs or Developers.
Just as in decision log, a risk’s priority could change in future or a risk could become an issue (i.e. already occurred). You can read about Risks vs Issues. Hence, at a given time the risk register should show the updated risk information.
Also, once the risk becomes an issue it can go to the Issue Log which is the same as Risk Log and usually kept in parallel.
In short, maintaining Decision and Risk logs in your product might be an additional task for you in the starting. But, once it becomes a part of your process, it really proves beneficial in the long run. You can use it to-
- Keep everyone on the same page.
- Save time in debating/recalling the reasons for a particular decision.
- Avoid “We told you so” situations that become the root cause of conflicts..
