Growth Part 1: Building a Strategy and Connecting it to a Roadmap
Creating a product that delivers value and can be built by an engineering organization at scale.
Introduction
Once a product has been successfully launched, the product manager’s job shifts to focusing aligning the team to a vision and set of objectives to achieve value for the end user. This article walks through going from a product with a bare minimum set of features to creating a strategy guide, building a roadmap, and leveraging tools to scale a product manager’s capacity for delivery.
Generating Long-Term Value
It’s been two months since you began work on the routing optimization solution at Transportation Perfect Software. As work continues to get done, you excitedly receive the chance to present what has been completed and while also receiving a surprise from your boss.
The End of the Beginning
You begin walking to the conference room where your first demo of the tool is going to take place. After staying up late working late working the night before the meeting, you walk in confidently. You created an outline of the features developed and delivered by the engineering team, and tested all of them yourself this morning. With a sense of pride and excitement, you open the massive glass door and walk into the room. You place your laptop down on the cool table and smile at your engineering manager, boss, and routing teammates displayed on screen from their Idaho headquarters. You start the meeting and begin diving through the various features that are due to be released into production next week. You take strategic pauses to answer any questions that may arise, and begin to align everyone to the incredible first set of features. Though the optimization algorithm is still highly experimental, you show off auto-generated routes that meet constraints and are 70% accurate according to routing analysts. Within 15 minutes, your demo concludes and you thank everyone for joining. As you shut your laptop, your boss comes and sits next to you. They mention how great of a job that you are doing and mention once again how great the product is. They then hit you with some surprising but amazing news: Transportation Perfect Software is about to offer your solution to a large bus company! While you had not been made aware initially, you suddenly realize that your user base is about to get a lot bigger.
Building the Map
The following day, your boss facilitates a meeting with the bus company’s project lead, Veronica. She introduces herself, and you get to work listening to her needs and feverishly write down her pain points and needs. After the meeting concludes, your boss asks how you think your roadmap aligns to their needs. You stop for a second and realize you don’t have an answer. In the chaos of the last two months, you had been so focused on getting the MVP out the door you had forgotten to triage development requirements for future iterations and make a roadmap! When you don’t answer right away, your boss smiles a bit and assures that everything is just fine. They now how hard you have been working, and sends you a link to the tool that your team is leveraging for roadmap development. You thank your boss and head out for the day, pondering what the future for your amazing tool will look like.
Becoming Strategic
The very next day, you sit down at your desk with your warm coffee in-hand thinking about the future of the Transportation Perfect Software Routing solution that you have been asked to scale. As you log into the roadmap tool, and begin trying to create a roadmap skeleton based on your notes from Veronica, you realize that you’re missing something: a strategy. You realize that you could pick features that you and Veronica may find valuable, but wonder how that would fit into a longer-term vision for your product. Thinking back to your business school days, you remember a marketing project that you did related to creating a product strategy. As you pull up the old document, you remember back the group project where you made the product strategy guide! While the product that you created it for in school was fake, you recycle the outline from the paper for your product. Within a few hours, you have your first draft of the product strategy guide:
Product Vision
Create and scale an AI-guided routing optimization tool that helps transportation companies to run their operations most efficiently and accurately.
Measurements of Success:
Reduce time spent performing routing operations by at least 12% for any company
Design an automated routing algorithm with at least 85% accuracy compared to manual routes
SWOT Analysis
Strengths
In-house subject matter experts who can provide insights on features and routing capabilities.
Strong data analytics team leveraging cutting-edge AI development tools.
Fast-moving development that can deliver quality software quickly.
Weaknesses
New platform that only has an MVP feature set, and has long backlog of features.
Competing requirements from internal and external stakeholders.
Opportunities
All existing platforms are dated and not being well maintained.
Four potential strategic alliance companies are interested in a new solution leveraging AI.
Threats
AI-based routing model is less accurate than human routes.
Low software adoption due to missing features.
Objectives and Key Results
Objective #1: Deliver usable routing tool for internal Transportation Perfect Routing Team
Key Result #1: Raise internal user satisfaction score to 90% by end of Q4
Key Result #2: Respond to 100% requests within one week of submission consistently per quarter
Key Result #3: Measure feature effectiveness in feature tracking framework by end of Q3.
Objective #2: Decrease manual routing creation time by 35%
Key Result #1: Deploy at least one AI-infused routing creation feature by end of Q3.
Key Result #2: Create details for route recommendation feature with feedback from at least 4 internal users by end of Q3.
Key Result #3: Reduce manual routing creation time by 20% by end of Q4.
Objective #3: Expand to ride sharing and school transportation verticals by end of Q2 2024.
Key Result #1: Provide baseline features requested by Veronica by end of Q3 2023.
Key Result #2: Identify rideshare development partner by end of Q4 2023.
Key Result #3: Deliver at least 2 new features to support both verticals by the end of Q1 2024.
Once you complete this initial strategy guide, you review it your manager, and they approve excitedly. You then take it to the different teams impacted by the goals and begin reviewing the objectives with each of them. You continue to socialize your vision for the tool, especially with the marketing team, so that they can help you refine your message and positioning of your high-end product.
Hitting the Road(map)
With your strategic plan in place, you begin comparing your notes and feature backlog to your strategic plan. You start by placing your objectives into a table, and begin to think about each one as a “theme” for abilities your users will want to have within your tool. Using the outcome-based roadmap template provided to you by your VP, you organize and align your features to your objectives in the table shown below:
After organizing your roadmap, you get to work on creating requirements for the features within the “current” section of your roadmap. This focus helps you to spend your time and effort on executing business analysis techniques for each feature listed on your roadmap. As you begin your analysis, you realize that the abilities described in each bullet points a large buckets of work that need to be broken down into smaller chunks for your engineering team.
Operating for Success
With a roadmap in hand, you align all of your different cross-functional teams to the direction and vision of your routing platform. With the help of the marketing team, you come up with a name that can be used externally: The Riveting Routing Platform.
As engineering gets underway developing the next set of features, you begin to realize that your time is being split across a number of different departments, and you don’t have ask time to explain your product in detail to everyone. The problem however, is that you need everyone to have access to the same level of details about product features, so that they can understand the incredible work that you are doing for your product.
You decide to leverage the tool that you boss added you to a few days ago, and setup some important processes to maintain the cohesiveness of your product across the organization. You create three important processes within the tool:
Process 1: Requirements Development
You decide to upgrade your requirements process, and begin entering them into an online collaboration tool, rather in word documents you have been saving on your personal devices. In addition, you setup templates within the new system that provide you with headers and boilerplate fields that the engineering team expects you to provide on each requirement set. You then setup a a synchronization process between your tool and the engineering team’s ticketing system. In doing so, you ensure that any change within one system affects the other. With this new setup, you quickly add your product requirements, and share them with your user experience and engineering teams. This helps them to stay aligned to your requirements, and gives them a single, central place to find requirements, while still ensuring that the most accurate information lives in both systems.
Process 2: Roadmap and Long-Term Views
As you get to know your marketing and sales team members better, you begin to realize how important timing of features is to them. They are incredible at making even the simplest of features sound like the biggest innovation in the whole world. The problem however, is they often promote features to early, and you fear that this will lead to disappointment with your prospective clients. To alleviate this, you create a slightly different roadmap within your tool aimed at release timing and share it with the product marketing team. The roadmap shows anticipated delivery dates along with features and their benefits listed as part of your requirements. You highlight to them that they don’t even need to wait for a monthly software review to ask if the feature is done, as the statuses on the features are updated directly from the engineering system! You notice immediately that this view saves you many hours of questions about your product, and helps everyone to understand the exact state of your product.
Process 3: Feedback Gathering
As your product gets further into development, Veronica calls you and asks if your tool has a certain set of features. While the features she mentions are similar to ones in development, there are some nuances you would like to capture. You decide to use the portal offered for your product, and provide Veronica with a link. You ask her to add as much detail as she can, and she happily says she will. Once you receive her request, you tie it to some product requirements and an engineering ticket. You let her know that the submission has been added, and that she can track the progress in the portal any time she likes. She thanks you for helping her and you decide to share this link to some other internal stakeholders as well, so that they can add their ideas. You immediately see a number of requests come in, and soon have a great pulse on what customers are asking for.
By leveraging these new processes, you have been able to successfully maximize your time, and you continue to work on making your product the greatest transportation solution ever invented. As the first checkpoint for your goals draws near, you are eager to meet with each team to track their progress and see what adjustments need to be made. Right before your meeting, you get word that the bus company has signed the contract, and they will be your first external customer leveraging the Riveting Routing platform.
Want to know what happens next? Subscribe to get notified when the next article drops!
Exploration and Discovery Topics
The growth phase of a product is challenging due to the time management and communication complexities that a product manager faces. It requires the ability to ensure alignment of multiple departments at scale, while also trying to deliver timely, valuable features. This phase is also very fluid and requires a lot of experimentation with different methodologies to get every department aligned perfectly. The tips and techniques discussed below are starting points in a product manager’s journey of creating a strong pipeline for their own product.
Development Review Meetings
The development review meeting is a pivotal moment in the development of any new feature, and is an exciting moment for a product manager. This meeting showcases new features completed by the engineering team, and provides stakeholders (and potentially early adopters) with the chance to provide initial feedback on the feature. Ideally, these meetings should provide the following outcomes:
Alignment - Align stakeholders to the completed feature, and provide them with a chance to ask questions.
Adjust - Provide a forum for stakeholders to see the delivered product and ask for future enhancements. This is an extremely important part of the meeting, because it helps everyone to visualize what the tool actually does, and better verbalize how requirements can chance.
Action Items - Take the alignments and adjustments suggested in the meeting, and apply them to the product roadmap as incremental updates to be made to the product.
There are countless ways to run the meeting, however, it is important to remember to be brief and to the point during the meeting, especially if more senior members of the organization join the call. Keeping an agenda for the call (i.e. a document or something of that nature) to help others see what was discussed is also highly recommended. As a best practice, the agenda should provide the following descriptions per feature:
Description - talk about what the feature does
Business Value - describe how the feature provides value to the target persona
Comments - provide a place for someone on the product team to document suggestions and product requests on the call
The audience of the meeting should be determined by the Product Manager based on the audience that they believe would benefit most from the content of it. Here are some recommended audience members to consider:
Engineering Leadership
Subject Matter Experts (SMEs)
Executive Leadership
Other Product Managers.
By hosting this meeting, a Product Manager can more effectively everyone with an oral (and potentially visual) understanding of the new features within their product.
Product Strategy Guide
Thew product strategy guide is a dynamic form of communication that helps a product manager to describe their long-term product vision and the objectives for achieving it. The goal of the strategy guide is to communicate how the product aligns to broader corporate goals (such as improving customer experience or gaining market share), the vision for the product for a given period of time (i.e. a year), and the objectives and key results for the product. These objectives can also be used to form the framework and basis for the features developed against the product, as well as align work items to common themes. Each section of the document discussed in the example is explained in more detail below.
Product Visions
The product vision is a high-level description of what the product will become over the next year (or longer). It should rally business and engineering stakeholders around a common theme that they can anchor themselves to. The product vision is supposed to be vague but directional, where it does not lock in certain features, but instead guides a team to develop features that align to the statement. Product visions are inspirational and should not change too often. These vision statements can be tricky to write, and if more help is needed writing one, read this article on product vision from the 280 Group.
SWOT Analysis
The goal of the product strategy guide is to align a product’s vision and feature set to to specific vision. Before more low-level and specific metrics can be added into the guide, a SWOT analysis should be done to deeply think through the vision and “poke holes” as needed. This SWOT analysis can also be used to justify the long-term vision of a product to executives, since it demonstrates a deep level of understanding about the product and its' direction. For more information on writing a SWOT analysis, please read this article from Investopedia.
OKR Methodology
There are many different methodologies for creating and measuring objectives. The one discussed in this article is the objectives and key results (OKR) methodology developed by John Doer, as it is easy to describe and is very easy to connect to corporate goals and a product vision. The “What Matters” website provides an excellent overview of the framework, if you desire further reading on it. The OKRs discussed in the product strategy guide, should provide three important directional pieces of information for a product:
Clear Objectives and Themes - It defines clear and concise objectives for the product over a given period of time, and value themes for features.
Time - It provides high-level timelines to achieve these goals. The timelines can be updated later, but it’s aligns goals to a measurable period of time.
Goal Measurement - The most important part of the OKRs in the strategy guide is that they highlight measurable outcomes to achieve objectives. Providing this information will help objectively track if a product is on track. As a best practice, these measurements need to be easily accessible and updated, otherwise they often get neglected until someone asks about them.
Product Roadmaps
A simple glance at any product manager job description shows that a product manager must own and maintain a product roadmap. Roadmaps sounds wonderful in theory, but in practice they are often highly disparate and fail to achieve the outcome that they need to drive: when will new features be delivered and what value do they deliver. A roadmap can be a product manager’s ultimate tool to keep all parts of their organization focused on what is coming up, or become an impossibly to-do list that shows no value for the end user. There are often different types of roadmaps used by product managers to convey different messages to each audience, and each one is discussed in detail below.
Feature Roadmaps
Feature roadmaps (often referred to as “traditional” roadmaps) are visualized as Gantt charts, where a product manager adds in features at a certain level of detail in the order that they want features developed. This simple visualization helps to communicate what features need to be developed when, and the product manager’s general vision for delivery for new features. It is generally shared with all stakeholders within an organization as a “one-size-fits-all” timeline view of features, since it is very easily understood with little need for explanation. While this visualization can be helpful, it’s often lends itself to a “feature factory” or “build trap” approach to product management, where features are built and delivered for sake of building software in a time-based order. There are many reasons for this unfortunate result, with the common reason being that the roadmap communicates features over values/product abilities.
Outcome Based Roadmaps
A newer type of product roadmap is an outcome-based roadmap. This roadmap focuses on connecting a product’s vision/strategy (i.e. key themes and OKRs) to its features, and mapping value between the two. This approach to building roadmaps provides a powerful way for a product manager to effectively track and map their features to their goals without needing to spend time filling in data points along the way. It also helps to frame features in a value-based, action-oriented way, where a each feature is listed as an ability or new action that a user can take in the app as opposed to “add new page”. A outcome-based roadmap can be shared with all stakeholders, but is often most valuable for sharing with customers, sales managers, and product marketing, since they are all trying to understand the value provided within a solution. For more details on this type of roadmap, please review this presentation from Denver Startup Week.
Release Roadmap
Once features are in the development pipeline, they will eventually be assigned a release date. A release roadmap helps to highlight when exactly certain features are slated for release. This roadmap is most often used by the engineering and marketing organizations to communicate about new features internally and externally. In addition, this roadmap can be used to determine when a feature was released when understanding the impact that it had on an objective. There are also some technical usages of the roadmap such as a record of releases when evaluating bugs and issues in complex software solutions.
These are only some of the many types of product roadmaps, as there are many more designed for different types of communication. The most important criteria to consider when selecting a roadmap however, is the audience that is intended for, as well as the long-term maintainability of it. A roadmap can be a powerful communication tool, so long as it is maintainable and used by the audience consuming it.
Roadmap Prioritization
A product manager also has the responsibility for determining the priority of features within the backlog of work. There are countless techniques for labeling a priority (i.e. low to high, MoSCoW, RICE), but prioritization itself is an art form. The goal of prioritization of features is to decide to order of development that can provide the most value for users in the shortest span of time. While there are always dependencies (and those need to be identified!) a product manager needs to work with users and understand their domain enough to make that judgment call. Prioritization should also be re-visited regularly, since business and user needs will change frequently. When these needs change, the relative value and priority of a feature will also change.
Digital Roadmap Integration
There is often a big disconnect between a product manager’s visionary roadmap, and the actual work being executed on by the engineering team. To help alleviate this problem, a best practice is to find a way to either build the roadmap within the task management/execution tool that the engineering team is using, or connect the roadmap to the engineering tool. There are many different tools/integration combos that make this process incredibly easy, but it needs to be setup and continually managed properly to work well. In the long term view of product however, having an integration to the engineering execution tool is critical for keeping the roadmap up to date. Manually updating the roadmap every so often is incredibly cumbersome and leaves room for error.
The best tool to use is the one that the most stakeholders can have access to. Stakeholders from around the organization all need the same thing: information. To get this information, they need somewhere where they can look for documents and artifacts from the product manager. Setting up this integration point is very important as misalignments between different departments will cause unnecessary friction that is alleviated with simple strategic communication lines.
Product Tool Evaluation
The goal of this article is not recommend specific tools, but instead provide insights on the different types of tools, and what to consider when looking for a product management tool/toolset.
Features to Consider
Evaluating product management tools can often be a daunting task. Below is a list of features that are good to examine when looking at tools:
Roadmap Creation and Management - As discussed in the previous section, roadmaps are an important piece of information that a PM must maintain. Tools that inherently provide functionality for easy roadmaps should receive strong consideration.
Ease of Integration - If the product tool is not going to be in the same one as the engineering work, then it is highly recommended that the standalone product tool integrate easily with the engineering tool. The main reason for doing this because the product and engineering teams need to stay in close sync with one another all throughout the development process. If the two systems are not connected, the PM will spend more time trying to do simple alignment tasks, than valuable activities such as drafting requirements for new features.
Accessibility - One of the major barriers for product managers using any form of SaaS (Software as a Service) tool today to manage their work is users around an organization having access to a roadmap and its content. Many tools will force anyone who wants to see the information to pay for a license. A good product tool will have some form of good limited way to present information in a view-only format, but surprisingly many of them don’t. If the tool doesn’t make accessing the information added to the roadmap easy, than its value should be very carefully considered.
Collaboration - Product organizations interested in scaling their product teams will need a tool for them to collaborate and scale together. A good product management tool will make this easy and seamless, but often times it is a convoluted, individualized process that ends up spilling over into another tool.
Feedback Gathering - The best products are the ones that address the problems of their customers. Therefore, a good product tool should make it easy for external feedback to be saved and managed in the same place as its roadmap and requirements. This makes it easier to act on ideas, since product managers don’t need to look somewhere else for ideas. A bonus item to consider is tracking of completion of a feature, so that the tool can notify users when something is complete, thereby streamlining the communication for the product manager.
Thanks for taking the time to read this article! Please share or subscribe to this sub stack article, as either one greatly helps me share this information!