When organizations are relatively small, it is possible to keep all parts of the company – execs, PM, sales, engineering, QA, operations, etc – in sync with the direction and with the vision of the company. Communication across the company can be seamless and everyone can remain aligned to what they are working on and understand how their work maps to the broader vision.
However, as companies scale up, it is very easy for this chain to be broken and for a hitherto finely tuned company to get out of sync. Examples of this happening:
- Deal-driven features: Sales promises a feature to a customer to close a deal and it gets added to a plan. After a few months, everyone forgets about it and it gets dropped. Eventually it blows up as an escalation when the customer is now upset that promises were not kept.
- Vision changes: The exec team makes changes to the vision as the markets changes. This requires a replan with new features coming in and some features in plan being dropped based on shifting needs. This does not get communicated down the chain and development remains marching to an older beat.
- “All Features Accepted”: Every few days a new feature request comes in and gets added to the plan. Nobody says “No” early enough, a commit gets communicated externally and in the end the product becomes a mish mash of features, with no clear vision and becomes impossible to use. Without a consistent plan that resonates to the vision, the product manager risks putting out a product that makes noone happy. The PM is the gatekeeper to avoid this from happening.
These are all examples of breakdowns in communication. It is the product manager’s responsibility that this does not happen. A product manager can use their product roadmap as a central part of a simple process to make sure that all parts of the company remain in sync. Changes will happen – that is a part of startup life – but the important thing is to make sure that the changes as they happen are clearly rationalized, communicated across all teams and all teams are kept in sync with where things are.
The best product roadmaps define the themes of the market that are relevant, the long term vision of the product (about 2-3 years out) as well as the shorter-term term features (quarterly breakdown over the next one year). While this is maintained by the product manager, this should be communicated regularly to the sales, dev and engineering teams. The product roadmap should be shareable externally to prospects, customers and other external stakeholders. Done right, the product roadmap becomes the central part of the process of keeping the various teams in sync.
Product Alignment Process
The process involves creating:
A vision document : Simple 1-2 pager describing where the company will be in the next 12-24 months. This is done in concert with the execs and aligns with the company’s overall strategy. This is shared with everyone in the company and externally as well. Normally this is part of the lead-in to a detailed roadmap but sometimes this can live separately (especially in multi-product companies where the vision is broader and maintained by execs). This is versioned and is available to everyone. I prefer the use of Google slides with read-only link shared across the organization. A well defined and strong vision ensures that any feature request that does not align with the long term vision can be dropped early. The product manager meets regularly with the execs and keeps this in sync.
An external “one-slide” roadmap : This is the product roadmap as it is traditionally defined. The deliverable here is a simple one-slide roadmap showing the quarterly deliverables of the marketable features for the next year. This can be shared externally. As above, Google slides with a shareable read-only link works great here. It is versioned to be consistent with the vision document.
Figure 1 : Example external roadmap for a fictional car ride share company. One Google Slide with the next 4 quarters of marketable features.
An internal / detailed roadmap: This builds on (2) and adds internal deliverables – like performance improvements, UX changes, engineering focused tasks, etc. This is the detailed, internal-facing roadmap. This version allows the team to make sure that the engineering focused improvements are not lost in the shuffle. This allows the team to make progress on reducing technical debt while continuing to execute to the market.
Figure 2 : Internal roadmap shareable with dev and QA managers. One google slide that builds on external roadmap.
The details from the internal roadmap are then mapped to a tool that allows for backlog tracking and planning. I prefer Trello for a Kanban-like tracking system but there are various other tools that work very well.
Figure 3: Using Trello to schedule the work outlined in the internal roadmap as a set of cards
Sprint planning: With the details from (3), PM works with dev management to build out the detailed plans for each sprint and map it to a tool to track this (I prefer Atlassian Jira) for this. At this level, this is really a detailed work plan that’s aimed at PM, dev and engineering teams
Figure 4: Using JIRA for sprint planning. See blog for more.
And thats it.
What we have done above is create a predictable system where all product planning deliverables are kept in sync with one another. There are three critical attributes to making this process work:
- Versioning: All the documents above should be synchronized. The latest versions of each should all relate to one another. Where a change is made, the older version should be versioned and there should be a clear indication for the reason for change. It should be possible for any stakeholder to review past documents to understand the reasons and the velocity of changes.
- Relevant Access: To avoid irrelevant information being communicated to the wrong audience, appropriate access should be given to the right stakeholders for the vision (everyone), external roadmap (sales, execs, PM), internal roadmap (PM, execs, support leads, dev leads, QA leads) and detailed sprint plans (all dev and QA)
- Single Owner: One owner should be responsible to make sure that they are in sync. The PM should own 1-3 above and work with engineering management to align it with (4)
Summary
Plans can and do change. The product alignment process defined above allows for the different planning documents across the product organization to remain in sync at all times so that as these changes happen, they can be rapidly and consistently communicated. This allows every employee to be confident that the work they are focused on is in sync with the vision of the company. And that will help the company move quicker and more efficiently as a result.
