There can be elements out of the team’s control when working on any project. Product Managers always strive to help their stakeholders unblock situations and make progress. However, it is essential to keep track of the out-of-our-control blockers that impact a project’s timeline and budget. Tracking the blockers is even more critical for closed-scope projects.
What is Considered a Blocker
A blocker doesn’t necessarily mean that the team cannot make any progress at all. Our team continuously seeks to make progress. Anything that impacts the project timeline and budget is considered a blocker because it prevents the team from delivering the product within the agreed project parameters (requirements, budget, timeline).
In the context of this document, the term “blocker” can be defined as “something that prevents progress within the agreed-upon parameters.”
Any missing element is considered a blocker. For example (the following list is not exhaustive):
- Unanswered questions
- Missing information
- Missing credentials
- Lack of access to tools
- Unclear requirements
- Outdated or unusable design
Although acceptable through our Request For Change process, a change in the project scope is also considered a blocker —especially for closed-scope projects— because it will require research and planning time that was not accounted for when defining the project timeline and budget. Scope changes inevitably result in delays.
Generally speaking, a blocker can be anything that leads to a delay in the project timeline and, consequently, an increased cost caused by a timeline extension or the need for additional resources to complete the project within a set timeframe.
How to Track Blockers
When a blocker arises, the Product Manager must immediately take action and follow these steps:
- Log the blocker in our Notion blockers tracker.
- Configure the documentation as follows:
- Raised On Date
- Expected Resolution Date
- Status (
Fill in the details following the template.
# Background An explanation of the situation that occurred and some context on why it is considered a blocker # Effects On Project How is the project affected by this blocker? Does it affect other projects? List out all the known ways this blocker is affecting our projects. # Actions Needed *Don’t forget to filter the actions below for the project affected only.* # Resolution Was this blocker removed? If so, please add any notes related to the resolution. (i.e. How was it resolved? What was the outcome?) If there was an RFC for the blocker, please link it here.
Add at least one action to resolve the blocker following the Actions Needed template.
- Inform the primary stakeholder on the client’s side about the blocker and its possible impact (typically delays and budget increase) via email.
The Product Manager will need to continuously update the status of the blocker in the Notion blockers tracker and report any and all updates, finally, to a resolution.
As part of their daily activities, Product Managers must work to resolve any given blocker. Product Managers might not always have the capacity to resolve a blocker independently, but they must always promptly facilitate a blocker’s resolution.
Managing Commercial Expectations
Resolving blockers is always the primary objective. Yet, managing commercial expectations is an essential secondary objective.
As explained earlier, blockers usually lead to an increased timeline and budget. The team must communicate the commercial impact to the client, and the client must acknowledge their responsibility for the delays and cost increase.
Managing commercial expectations is the responsibility of the Business Development team. For the Business Development team to manage expectations efficiently, the team must establish an unambiguous communication flow between Product (identifying and resolving blockers) and Business (managing commercial expectations and creating the necessary commercial agreements).