5 Critical Checkpoints on the Product Roadmap
On any road, there are the usual sign markers showing useful information, locations for services, and sometimes, checkpoints set up by law enforcement authorities. These checkpoints are intended to ensure compliance, e.g., sobriety, seat belts, or in other situations to reroute traffic due to hazardous conditions ahead, e.g., rock slides, excessive flooding and snow, and so on. Bottomline, the purpose of a checkpoint is to ensure that we are equipped for our onward journey, that it continues to be safe, and we get to our destination without too much unplanned adventure.
The Product Roadmap is a similar journey in its own right. What checkpoints should we have to inspect if the journey continues on its planned route, or take detours as necessary?
Drivers & Law Enforcement
The cross functional product team is in the driver’s seat. They decide the destination consistent with the overall market and product strategy (e.g., we need to move from on-premise to cloud), high level milestones on the journey based on some prioritization (e.g., by the end of q1, we will have done x, by end of q2, we will have done y). They stock up the vehicle with the right people and resources, they break up the journey into smaller milestones (e.g., we ought to get to place z before night fall), keep an eye on the road, the weather, the fuel gauge and make short term adjustments as necessary to optimize the trip, all the while marching down towards the final destination.
Senior management and executives are the equivalent of the law enforcement authorities, a little more vested in the destination and the occupants of the vehicle. They periodically inspect if the journey is going as planned (e.g., if we add to or remove a few people in the vehicle, will it go faster? Hmm!), if the intermediate milestones are being met, or changing some of the intermediate milestones, or even the final destination, based on the overall strategy and events in the market (e.g., Cisco just acquired our competitor, or we just signed a partnership with Salesforce).
Checkpoints are necessary. Let’s see what formal checkpoints we should have for our product roadmaps.
Checkpoint #1: Concept Review
The Concept Review, as the name suggests, is to validate the destination, to make sure we have asked the right questions and are satisfied about wherewe want to go and why. Make no mistake, this is not quite yet about how we will get there. The main focus is the destination. Once that is established, a preliminary discussion of how long it will take, what we need, etc., can follow.
The core product team members (Product Manager, Engineering Manager, Product Marketing Manager) are responsible to do the ground work and present a summary to senior management (VP Product Management, VP Engineering, CTO, GM).
Whether you are in a large company working on the 10.0 release of your product, or driving new innovation leading to a 1.0, or whether you are in a startup and being lean and nimble and wanting to fail fast and fail forward, it is a good idea to pause for this checkpoint, before driving too far down the road. How much ground work you might need to do might depend on the appetite for risk and unknowns, and the latitude that senior management is willing to give you.
In a startup, this might be a short conversation. Perhaps you have defined some hypotheses, done a few experiments, whipped up a landing page and estimated interest from visitors, and proven the concept in the form of a very light weight MVP.
In a large company, this is likely a more involved conversation, that looks at market opportunity and impact (e.g., incremental bookings impact, or cost reduction and margin impact), competitive advantage (e.g., how does this position us against our biggest competitor SAP?), go-to-market (e.g., can our existing channel partners sell this?), and alignment with overall strategy. Again, the end goal, the strategic outcome and the rationale for it are the primary drivers for this conversation.
Once the concept is approved, its a sign from law enforcement to move forward on the journey. From here on, the product team organizes itself to get into the mechanics and the plan of what and how.
From a roadmap standpoint, we have a general high level idea of the desired outcome (e.g., move to cloud), and a rough idea of timeframe (e.g., 2H2017 or even down to the quarter 4Q2017). It is quite possible, and actually recommended, that a product team has a pipeline of concept ideas to help grow the business and increase the impact of the product for customers and the company. Some concepts may have one or two people, typically architects, evaluating the technology feasibility. We know these as “skunkworks projects”.
Some concepts may have nothing to do with product development, but may be in the realm of go-to-market (e.g., we need to refine our pricing and channel readiness for the SMB market or we need to have reference customer case studies). If a concept has the potential to create significant impact to the business, and requires non trivial resources to come to fruition, then it is worthwhile to have a Concept Review checkpoint.
The simple question to ask is — do we have any asks of the senior management team? If not, those ideas are simply tasks and activities on someone’s plate, still important to get done.
The core product team members (Product Manager, Engineering Manager, Product Marketing Manager) are responsible to do the ground work and present a summary to senior management (VP Product Management, VP Engineering, CTO, GM).
Whether you are in a large company working on the 10.0 release of your product, or driving new innovation leading to a 1.0, or whether you are in a startup and being lean and nimble and wanting to fail fast and fail forward, it is a good idea to pause for this checkpoint, before driving too far down the road. How much ground work you might need to do might depend on the appetite for risk and unknowns, and the latitude that senior management is willing to give you.
In a startup, this might be a short conversation. Perhaps you have defined some hypotheses, done a few experiments, whipped up a landing page and estimated interest from visitors, and proven the concept in the form of a very light weight MVP.
In a large company, this is likely a more involved conversation, that looks at market opportunity and impact (e.g., incremental bookings impact, or cost reduction and margin impact), competitive advantage (e.g., how does this position us against our biggest competitor SAP?), go-to-market (e.g., can our existing channel partners sell this?), and alignment with overall strategy. Again, the end goal, the strategic outcome and the rationale for it are the primary drivers for this conversation.
Once the concept is approved, its a sign from law enforcement to move forward on the journey. From here on, the product team organizes itself to get into the mechanics and the plan of what and how.
From a roadmap standpoint, we have a general high level idea of the desired outcome (e.g., move to cloud), and a rough idea of timeframe (e.g., 2H2017 or even down to the quarter 4Q2017). It is quite possible, and actually recommended, that a product team has a pipeline of concept ideas to help grow the business and increase the impact of the product for customers and the company. Some concepts may have one or two people, typically architects, evaluating the technology feasibility. We know these as “skunkworks projects”.
Some concepts may have nothing to do with product development, but may be in the realm of go-to-market (e.g., we need to refine our pricing and channel readiness for the SMB market or we need to have reference customer case studies). If a concept has the potential to create significant impact to the business, and requires non trivial resources to come to fruition, then it is worthwhile to have a Concept Review checkpoint.
The simple question to ask is — do we have any asks of the senior management team? If not, those ideas are simply tasks and activities on someone’s plate, still important to get done.
Checkpoint #2: Plan Review
The goal of the planning stage is to consider appropriate constraints (e.g., we will not drive after 10pm, we must cover 600 miles each day), trade-offs (e.g., if we take a short lunch break, we can reach the hotel in time and find a good restaurant for dinner), priorities (e.g., visiting national parks on the way is important), and resources (e.g., we only have two people who can drive, and only one who is comfortable to drive at night).
The end result is more clarity about the journey, and we can answer with more specificity, questions about timeframes, and intermediate milestones. The Plan Review Checkpoint is an opportunity for senior management to review the plan, question the assumptions, trade offs, priorities and resources. Some things are what they are (e.g., there is road work next 60 miles, and we can’t go any faster — the classic equivalent of our platform can no longer scale without refactoring, sorry!), some things are open for inspection and review (e.g., what do we need to cover 700 miles instead of 600 each day, can we drive until 11pm at night instead of 10pm, is it really important to visit all national parks). This is also an opportunity to course correct the overall direction.
In the Plan Review meeting, additional core team members (Program/Project Manager, Architect, UX Lead) are required to answer specific questions about the what and how.
Once the plan is approved, the journey moves into the development stage. Whether you follow Agile, or some adapted version of Agile, or some other development methodology, you will have appropriate interim milestones, sprint meetings, demo days, that the product team is required to manage and review. These are the equivalent of keeping the eye on the road, making short term optimization and adjustments to the plan as necessary. Senior management is typically not going to micro manage this, however it is important for the Product Manager to keep abreast of the status of these interim deliverables, and ensure appropriate near term decisions are being made.
From a roadmap standpoint, we now have more visibility into the journey. If earlier we estimated to achieve some outcome by 4Q2017, we are now able to say with a reasonable degree of confidence that it is going to be October 2017, with additional clarity on what will be delivered each month, assuming no further surprises or detours. A good project team will ensure there is room to accommodate any surprises. This raises the specter of sandbagging estimates and schedules, and an air of mistrust prevails. This is only the symptom of a bigger problem of lack of collaboration and communication within the team. It is the Product Manager’s responsibility to ensure good partnership within the cross functional stakeholders.
The end result is more clarity about the journey, and we can answer with more specificity, questions about timeframes, and intermediate milestones. The Plan Review Checkpoint is an opportunity for senior management to review the plan, question the assumptions, trade offs, priorities and resources. Some things are what they are (e.g., there is road work next 60 miles, and we can’t go any faster — the classic equivalent of our platform can no longer scale without refactoring, sorry!), some things are open for inspection and review (e.g., what do we need to cover 700 miles instead of 600 each day, can we drive until 11pm at night instead of 10pm, is it really important to visit all national parks). This is also an opportunity to course correct the overall direction.
In the Plan Review meeting, additional core team members (Program/Project Manager, Architect, UX Lead) are required to answer specific questions about the what and how.
Once the plan is approved, the journey moves into the development stage. Whether you follow Agile, or some adapted version of Agile, or some other development methodology, you will have appropriate interim milestones, sprint meetings, demo days, that the product team is required to manage and review. These are the equivalent of keeping the eye on the road, making short term optimization and adjustments to the plan as necessary. Senior management is typically not going to micro manage this, however it is important for the Product Manager to keep abreast of the status of these interim deliverables, and ensure appropriate near term decisions are being made.
From a roadmap standpoint, we now have more visibility into the journey. If earlier we estimated to achieve some outcome by 4Q2017, we are now able to say with a reasonable degree of confidence that it is going to be October 2017, with additional clarity on what will be delivered each month, assuming no further surprises or detours. A good project team will ensure there is room to accommodate any surprises. This raises the specter of sandbagging estimates and schedules, and an air of mistrust prevails. This is only the symptom of a bigger problem of lack of collaboration and communication within the team. It is the Product Manager’s responsibility to ensure good partnership within the cross functional stakeholders.
Checkpoint #3: Execution Review
As we go through the spring planning meetings, daily stand ups, sprints, and demo days, at some regular intervals, it is useful to have Execution Review checkpoints.
The goal of this checkpoint is to assess how we are progressing. For the product team, it is important to highlight any risks to the intermediate milestones or the overall plan. Risks can be qualified as technology risks (e.g., new technology, software/hardware dependencies, third party components, etc.), people risks (e.g., critical person falls sick or decides to get married), market risks (e.g., competitor’s product release negates the advantages we hoped to provide), and so on.
Good program/project managers assess risks and help qualify with attributes in detail to review with senior management: what is the risk, when was it identified, what are the undesired outcomes, how severe are the down sides, what is the probability of occurrence, what are the steps to mitigate undesired outcomes, who is tasked with mitigation, is the risk being monitored or closed.
The product team, led by the program manager, must ensure the risks are communicated to and understood by senior management, and present alternatives, mitigation, decision options for review. This could potentially impact the product roadmap.
The goal of this checkpoint is to assess how we are progressing. For the product team, it is important to highlight any risks to the intermediate milestones or the overall plan. Risks can be qualified as technology risks (e.g., new technology, software/hardware dependencies, third party components, etc.), people risks (e.g., critical person falls sick or decides to get married), market risks (e.g., competitor’s product release negates the advantages we hoped to provide), and so on.
Good program/project managers assess risks and help qualify with attributes in detail to review with senior management: what is the risk, when was it identified, what are the undesired outcomes, how severe are the down sides, what is the probability of occurrence, what are the steps to mitigate undesired outcomes, who is tasked with mitigation, is the risk being monitored or closed.
The product team, led by the program manager, must ensure the risks are communicated to and understood by senior management, and present alternatives, mitigation, decision options for review. This could potentially impact the product roadmap.
Checkpoint #4: Go to Market Review
At this point, we are a long way into our journey. Hopefully we’re enjoying it, except, well, for the nagging “are we there yet?”!! All the sprints and the stand ups, and the occasional late nighters (yes, sometimes we just have to drive through the night) are all things that will be part of the stories we will share some day over beer.
Meanwhile, more important work is at hand, ‘cause just because we built it, no one ain’t coming. While the development team is heads down busy building the product and delivering to the plan, the Product Manager must work closely with Product Marketing on Go to Market planning.
The key questions to answer in the Go to Market review checkpoint are about communicating value (positioning & messaging, marketing collateral), capturing value (pricing, and price book updates), launch plan (do we need to do a big splashy launch, and how), sales enablement plan (sales and channel partner readiness).
In the context of our road trip analogy, while we are on the last leg of the journey, best to start planning proactively what we are going to do once we reach the destination.
Meanwhile, more important work is at hand, ‘cause just because we built it, no one ain’t coming. While the development team is heads down busy building the product and delivering to the plan, the Product Manager must work closely with Product Marketing on Go to Market planning.
The key questions to answer in the Go to Market review checkpoint are about communicating value (positioning & messaging, marketing collateral), capturing value (pricing, and price book updates), launch plan (do we need to do a big splashy launch, and how), sales enablement plan (sales and channel partner readiness).
In the context of our road trip analogy, while we are on the last leg of the journey, best to start planning proactively what we are going to do once we reach the destination.
Checkpoint #5: Business Review
The product is released, it is launched, champagne is popped to savor and celebrate the long journey, a job well done. Now the real fun begins. Winning in the market. Winning customers. Beating the competition.
Most companies have a quarterly business review (QBR) with the executive team. The purpose of these reviews is to assess and make decisions to improve business performance (geo revenue, segment revenue, profitability), marketing effectiveness (demand generation programs), sales effectiveness (pipeline analysis, channel performance), competitive wins and losses, discounting trends, market and industry trends, product strategy (market opportunity, build/buy/partner), and product roadmap.
The business unit GM leads the business review, supported by the product management, engineering and product marketing leaders.
In the context of our road trip analogy, a Business Review is akin to tracking the metrics and performance of our journey so far (miles/day, miles/gallon, fun memories built), and validating the plan for the rest of the journey.
In Summary
So the 5 checkpoints on a product roadmap are:
● Concept Review — where do we want to go, and why
● Plan Review — when will we get there, how, and what do we need
● Execution Review — how are things coming along, is any course correction needed
● Go to Market Review — how will we communicate, capture and deliver value to the market
●Business Review — assessing progress and planning ahead
These 5 reviews constitute Product Governance. Again, how these reviews take place, how formal they are, etc., can differ if you are in a startup or a large company.
● Concept Review — where do we want to go, and why
● Plan Review — when will we get there, how, and what do we need
● Execution Review — how are things coming along, is any course correction needed
● Go to Market Review — how will we communicate, capture and deliver value to the market
●Business Review — assessing progress and planning ahead
These 5 reviews constitute Product Governance. Again, how these reviews take place, how formal they are, etc., can differ if you are in a startup or a large company.
Back to the Product Roadmap
So at the end of every journey, the next question is — where do we go next?
How do these checkpoints and the process of product governance work in your organization? What do you think?
How do these checkpoints and the process of product governance work in your organization? What do you think?
Facebook
Twitter
LinkedIn
