Mission, Vision, Strategy

I covered Roadmaps in a previous post, but product roadmaps cannot be created in isolation. Roadmaps must support your company or organization’s strategic direction captured in its Mission and Vision. I’ll outline these essential concepts and explain how they are connected to form a strategic planning framework. 

First, clarifying the terms Vision and Mission is necessary. I’m using the term Mission to mean “the organization or product’s reason for being.” Mission is often used synonymously with Purpose, which I will use interchangeably. Occasionally, Mission is sometimes used as a synonym for Vision, but I find this confusing and will avoid doing this.

I use the term Vision to mean the organization or product’s future state – i.e., where the strategy will take the organization or product.

Mission

Your organization’s Why” is its core purpose and reason for its existence. It defines the fundamental value your brand contributes to your customers and users, the market, or the world and the positive impact it strives for. Think of it as the North Star that guides your decisions. 

Your Mission should be captured and shared as a clear Mission Statement. Your Mission statement must be ambitious but also practical and achievable. It should also be durable and relatively static – it’s not uncommon for successful companies to have the same Mission for the organization’s lifetime. 

It’s not uncommon for organizations to have an undeveloped or unclear Why – If you’re interested in developing or improving your organization’s Why, you could do much worse than start with Simon Synek’s Why, How, and What.

Vision

Your Vision is your organization’s “where” or aspirational future state. It paints a vivid picture of the market landscape when everything goes according to plan, considering future trends, threats from your competition,  and opportunities. It serves as the guiding light for long-term investments and innovation efforts. Vision is about the future. Vision is aspirational and typically has a 3-5 year horizon. 

Strategy

Your strategy is the actionable plan to achieve the vision. It translates the broad aspirations of the vision into concrete steps, considering resource constraints, market realities, and technical feasibility. It should be adaptable and responsive to changing market conditions and emerging technologies. In a larger organization, you will likely have a refinement of the corporate vision specific to the business or product, but the connection should be clear.

I present the hierarchy like this to represent the organizational altitude because it’s much more natural in larger organizations with multiple business units or products. It also helps you to think of the duration of these terms. At the top of the pyramid is Mission or Purpose – this could and should not change significantly over several years, decades, or even the organization’s lifetime. Vision is more likely to have a 3-5 year horizon. Strategy and Goals are linked to annual planning, and the Roadmap gets down to specific months, quarters, and year halves. 

Likewise, Mission, Vision, and Strategy are typically defined at the company level and cascade down to business units or products, which will refine Strategy and Objectives to focus on the elements they can deliver or support.

Goals

I’m a big fan of OKRs (Objectives and Key Results) as a way to define and manage the execution of strategic goals, and I have successfully used OKRs in large and small organizations. Well-written OKRs help your team or organization achieve focus, accountability, engagement, transparency, and visibility. If you’re unfamiliar with the ORK framework – there’s no better place to start than John Doerr’s 2018 Ted Talk. There are many other goal management frameworks, and the advice below is general enough for any method. The important thing is that strategy alone is not enough – execution of the strategy needs to be monitored and managed. 

Objectives capture your strategic initiatives – i.e., what your business unit, team, or product must do to support the business strategy or higher-level Objectives. They need to be inspirational enough to motivate people but also attainable to some degree – i.e. successful attainment should be between 80 and 120%.  Well-written objectives clarify what the organization should be working on. Objectives shouldn’t be used to track an organization’s ordinary/mundane operations – you should have other ways to track those things. OKRs are better for monitoring ambitious goals- i.e. to help you achieve extraordinary results. 

“Without strategy, execution is aimless. Without execution, strategy is useless.”

― Morris Chang 

Each objective must have one or more Key Results – how you measure progress and ensure you stay on track to meet your objectives. Each objective should have between 2 and 5 Key Results at a given organizational level. 

OKRs should be part of your annual planning, with quarterly reviews and the potential to make changes at least biannually. 

In larger organizations, OKRs cascade down the organization. Depending on the nature of your OKRs, you could define supporting objectives at each level in the organization or have objectives that apply to all levels and Key Results defined at different levels so the results contribute to the level above. 

The Whole Picture

There is plenty of literature on crafting Vision Missions and strategy. I’m not going to go into any more detail in this post – but as a Product Manager – it’s essential to understand how the concepts are connected. More importantly – Visions, Strategy, Goals, and Roadmap must be clearly and unambiguously connected.

Summary 

To summarize, the mission is about the present, the vision is about the future, the strategy is the plan to achieve the vision, and the goals are the objectives that capture your strategic initiatives. OKRs are a great way to define and manage the execution of these strategic goals.

A well-defined Mission, Vision, and Strategy with clearly aligned Objectives will ensure your organization has focus, clarity, and the inspiration to succeed. 

Product Roadmaps

We don’t need stinkin’ roadmaps! Yes, you do, except in some rare circumstances, which I’ll outline below. 

For clarity – let’s define the term:

A product roadmap is a visual summary that maps out your offering’s features and capabilities over time and helps your customers and stakeholders understand your direction and progress toward fulfilling the product’s goals.

There are many reasons you need a product roadmap.

  • If for no other reason, you need a roadmap for your medium-term (e.g., quarterly) planning. In this case, your roadmap is nothing more than a wish list of features with some form of prioritization. If you don’t have this – you can’t plan. 
  • Your engineers and other downstream collaborators need to be able to see further than the next 2 or 3 sprints. Knowing what’s over the short-term planning horizon will help them make more informed design decisions, optimize hiring and training, and support better resource allocation.
  • If you are a B2B product company – your salesforce needs a roadmap to understand how the product will close a competitive gap or when you will deliver a capability required by a particular customer segment. Your roadmap helps sales plan their engagements more efficiently and effectively. 
  • Enterprise (B2B) customers need a roadmap – it helps them determine whether you are progressing toward your stated product vision, and it helps them plan upgrades, expansions, or migrations. More practically, it allows them to understand where you are vs the competition in addressing their needs. 
  • Most B2B sales combine what you have in the product today and what your roadmap and vision tell the customer about where you are heading. 
  • If you are in a larger company – your leadership needs to know that you are investing the company’s finite resources in the way that gives the best return and helps attain the company’s objectives. 
  • If you are a startup, your investors/board will take an even keener interest in your investments – in many cases – it’s their money. Expect to defend your investments and the roadmap. 

If your management or investors aren’t interested in your roadmap, you may have more significant problems. I’ve experienced this when revenue and growth are the only indicators of product success. Unfortunately, revenue and growth are trailing indicators – they only expose mistakes already made in the last quarter or year. Product roadmaps (and justification and prioritization behind them) can give organizations better insights before resources are committed and potentially wasted on the wrong things. 

There are situations where you don’t need to share a roadmap beyond the immediate product team, and the roadmap is primarily a planning tool and a way to demonstrate progress to your management or investors.

  • If you’re releasing a barebones MVP to assess Product Market Fit – you don’t need a roadmap.
  • If you are a B2C product company – your customers don’t need to see a roadmap – have you ever seen a roadmap for your favorite smartphone or video game?
  • If you have a very stable product in a very stable market – your customers probably value stability over change – a roadmap is not going to be a priority and will be limited to ‘features’ that show customers that they can depend on your product to keep working the way it does (e.g., support for newer hardware or operating systems)

In short, if you’re a product company, your product roadmap is your product strategy manifest, how you plan to make the proper steps towards your goals. Everything on your roadmap should align with your goals in support of your vision and objectives.

If you think visually, this diagram may help tie vision, strategy, and roadmap together.

Who owns the Roadmap?

Product Management is ultimately responsible for maintaining the roadmap, but creating the roadmap is a collaborative effort. Your stakeholders in sales and marketing need to be aligned with your roadmap and understand the next level of detail behind the roadmap. Your stakeholders need to be sure that the roadmap is aligned with and fulfilling your vision and strategy – there needs to be a direct line between the roadmap and the strategy – if your stakeholders understand the strategy, then there should be no surprises on the roadmap because they will be fully aligned. 

Tools

I generally prefer to present roadmaps from the tool I use to create roadmaps – ProductBoard is my current favorite, but tools like Monday, Ignition, Jira Product Discovery, etc., all allow you to manage and prioritize features, align with goals and strategic objectives and pull together an interactive and professional roadmap. There are a few occasions when you may need to pull a roadmap presentation into a slide deck (board meeting, strategic customers), but your PM planning tool should be your only source of truth for the roadmap. I find using a specific roadmap/planning tool gives you more credibility – everyone knows you can throw together a roadmap slide five minutes before the meeting – using the tool that drives your planning is a different level of commitment.

Scope, detail, and uncertainty

For a fast-moving product company in a fast-moving market – a 2-3 quarter roadmap is sufficient, and anything beyond that is highly speculative. I prefer to be very explicit about that – there’s a bucket of features over the planning horizon – these things are still worth sharing – your audience (internal or external) can help you prioritize those features. Different markets and products will have different dynamics – a roadmap for a mature product in a mature market will have a much more static roadmap, and planning could extend into 6-8 quarters for major features or releases. These are generalizations, obviously – even mature products will occasionally have to be agile and quickly plan and release new features at the expense of roadmap stability. Likewise – if you are in a fast-moving segment, you will still have strategic roadmap items – like significant architectural changes or re-platforming, where the work takes longer. Hence, you need a longer planning horizon and roadmap. 

There will always be some uncertainty on a roadmap. The further out something is on the roadmap – the lower the certainty and detail. Beyond one year – my unplanned bucket is nothing more than curated feature ideas with little detail or commitment behind them. Conversely, in the near roadmap – this quarter, next quarter – many of these features should be committed, i.e., Planned – you likely have a level of detail that allows you to engage with design and engineering and may already have an execution plan (e.g. Start sprint and sizing/cost). You will have a lot more detail and may already share details such as wireframes and conceptual designs with customers and internal SMEs. My rule is that your next quarter’s roadmap should be 80-90% accurate, two to three quarters out – 50-60% accuracy, and beyond that 20-30% – ie. Largely speculation.

Finally – roadmaps are an honest attempt to share how you are executing against your stated strategy or vision. Still, the only thing certain about a roadmap is that nothing is certain about a roadmap. I always lead with the caveat that things can and will change, and many larger organizations I’ve worked with have legally-approved disclaimers on roadmaps to make it clear that they are not legally-binding commitments. Occasionally, there will be exceptions – some items on your roadmap are high-integrity obligations to customers, partners, and other internal dependent teams, but everything else can and will change depending on numerous internal and external factors – market dynamics, higher priorities, etc.

Themes and Objectives

In an ideal world – your product roadmap is your strategy manifest. It shows how you are delivering against your strategy and vision or short to medium-term progress towards your long-term goals. For any reasonably complex product or portfolio of products, your strategy will break down into themes or objectives, and your roadmap will align with those objectives. 

Roadmap Mistakes

Don’t be unrealistically specific about dates. The most accurate roadmap is the one with no dates at all – just “now,” “next,” and “later”. If you can’t get away with that (e.g., B2B), calendar quarters or halves for further out. Plans constantly change, and estimates are optimistic, so don’t delude yourself. 

If your roadmap doesn’t reflect or support your strategy or vision, then people will be inclined to think that your strategy isn’t real or you’re failing to deliver on your vision. 

If you have multiple versions of your roadmap in slide decks and documents dotted around your company intranet, they will all be out of date at some point. This will lead to confusion and busy work. You must have a single source of truth to which everyone has (at least read-only) access. 

List of disconnected features. Your roadmap is your strategy manifest, so if it’s just a scattershot of features with no apparent structure, what does that say about your strategy? Thematic roadmaps are critical for portfolio companies – the themes help your colleagues in marketing get behind a small set of impactful messages.

Conclusion

Except in some rare cases – your product needs a roadmap. Your roadmap is a tactical enforcement of your vision and strategy, and there must be obvious alignment. Organizing your roadmap under broader objectives or themes will help enforce the alignment. Product roadmaps are dynamic documents and should be reviewed constantly, and the dynamic nature of your roadmap should be clearly communicated. Given the dynamic nature – ensure there is a generally accessible single source of truth for your roadmap.  

If your Vision is the Why, and your strategy is the What, then your roadmap is the When.