5 Critical Checkpoints on the Product Roadmap
Drivers & Law Enforcement
Checkpoint #1: Concept Review
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 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
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
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
● 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
How do these checkpoints and the process of product governance work in your organization? What do you think?