Guest Post by: Sharon Allpress (Mentee, Session 10, The Product Mentor) [Paired with Mentor, Patrick Hoffman]
As product managers, we need to be skilled in a variety of areas from defining features and requirements to understanding customers, analyzing usage metrics, prioritizing features, managing releases, and the list goes on. One of the most important skills for a product manager, and for the product itself, is developing a product vision and strategy.
The reason strategy is so important is that it provides the compass that helps to focus the team, organization and users in the same direction toward the north star. This context and focus helps to drive everything from technical decisions to design to prioritizing features.
As depicted in the diagram below, as we work toward a goal we are all expending energy. The strategy is the document that directs the mass of energy in the same direction significantly moving the needle versus a lot of activity moving in different directions not getting very far.
As product managers, we need to be skilled in a variety of areas from defining features and requirements to understanding customers, analyzing usage metrics, prioritizing features, managing releases, and the list goes on. One of the most important skills for a product manager, and for the product itself, is developing a product vision and strategy.
The reason strategy is so important is that it provides the compass that helps to focus the team, organization and users in the same direction toward the north star. This context and focus helps to drive everything from technical decisions to design to prioritizing features.
As depicted in the diagram below, as we work toward a goal we are all expending energy. The strategy is the document that directs the mass of energy in the same direction significantly moving the needle versus a lot of activity moving in different directions not getting very far.
The scene in Alice in Wonderland where Alice asks the Cheshire Cat which way to go summarizes the quagmire product managers can find themselves in without a well thought out strategy. That is, we can keep busy building stuff but is it the right thing to build and does it help us get to the north star? And does everyone know which way we are going or is the team moving in opposite directions with misaligned goals.
- “Alice: Would you tell me, please, which way I ought to go from here?”
- “Chesire Cat: That depends a good deal on where you want to get to.”
- “Alice: I don’t much care where –”
- “Chesire Cat: Then it doesn’t matter which way you go.”
- “Alice: …So long as I get somewhere.”
- “Chesire Cat: Oh, you’re sure to do that, if only you walk long enough.”
- ― Lewis Carroll, Alice in Wonderland
In my experience as a product manager, strategy has been one of the toughest skills to develop. I can easily strategize in the comfort of my head, then find I am unable to land it out in the world. The reasons are partly feeling like its never finished, fear of criticism, fear of being wrong, and a feeling that the strategy is obvious to everyone else that documenting it is a waste of time.
On more reflection, the most challenging part for me is that I get lost in figuring out how to articulate, package and share the strategy. I started to think that if I had a more tactical process available to me, I could more easily move beyond these struggles and get it out of my head and into the world.
Over the course of the product manager mentor program I set out to decompose what strategy is about and develop an approach to “doing” strategy. I’m still evolving the approach and learning a lot as I put it into practice. Along this journey I have uncovered some key learnings about roadmaps and why they are important to product strategy development I would like to share.
- A gantt chart – or timeline – of features with release dates is a release plan, not a roadmap
If you are asked to develop a ‘roadmap’ of features with the date that each will be completed, this is a release plan – not a roadmap. There is a misconception in the industry that any feature list using a gantt style chart is a roadmap. That is not necessarily the case and can often lead to missed understanding, ineffective understanding of problems to solve, and staying the course when the data is telling you otherwise.
When the features on a ‘roadmap’ are defined such that you and the engineering team can commit to the dates when they will be completed then this is really more of a release plan. Release plans are important visuals to share and communicate to the business about when they can expect a feature. The risk of calling them a roadmap is it will often preclude a valuable conversation about strategy and the problem that should be solved.
The movement in the industry has been away from specific dates to time horizons such as Now, Next, and Later — where, Now are things that are in progress, Next are things that have been defined and planned to work on next, and Future are things we want to work on but little is understood at this moment. A benefit for this approach is to provide transparency about what is known and unknown. I have found that moving to the Now, Next, Later time horizon approach has helped to elevate the conversation to discuss larger initiative and goals and how they align to the vision.
- A roadmap tells the story of value
“Roadmaps are evidence of strategy, not a list of features”
Following on from the above idea about using time horizons, the items in the roadmap should be at a higher level than features where the focus is instead on value and problems to solve. This is also known as thematic roadmaps and there is a lot written on this topic. My aha moment with thematic mapping came when I realized that a theme is differentiated from a feature in that the value locked up in a theme can be unlocked multiple times over the life of the product.
For example, as part of the IIOT analytics solution I manage, a business goal is to respond to an emergency field condition within 10 minutes of it occurring. We have called this theme Decrease Response Time. Our first iteration entails a basic push notification sent when a set threshold value has been exceeded for a defined period of time. We plan to unlock additional value for this theme with a self-service subscription based notification feature. In the near future we will release predictive notifications that will notify our users when something is about to happen. All three features unlock the value of decreasing response times, the last being to eliminate the emergency condition altogether.
- The roadmap is a living document and should be shared
The roadmap should be a living document that is revisited and updated on a regular basis. I typically update the roadmap monthly with minor updates as new learnings are uncovered. And quarterly I reassess the roadmap with shared input from stakeholders and users as well as using what we have learned and completed from feature released over the last quarter.
I like keeping the roadmap in a location that is accessible by everyone in the organization. That is why I prefer hosted roadmap solutions where everyone in the organization has access to the most recent version at any time. When a roadmap solution isn’t an option, I like to keep the most recent version on a share drive that is accessible by everyone in the organization. Whatever you choose, be sure that everyone in your organization has access to the most recent version AND clearly identify whether the roadmap is for internal use only. You want to avoid someone sharing an outdated, internal only roadmap with your external customers.
- Every roadmap should have an accompanying strategy document
The roadmap is a high level path of where you are going, and in order to truly enable a deep understanding of how you plan to get there, supporting information is needed to help develop context among stakeholders and the team. I have found it is also helpful as a reference document for the team, especially when you are not available to answer questions.
A discussion on what to include in the strategy document deserves its own article. Following are the highlights of the main points of what I typically include in a strategy document:
- State of the Industry/Market – describe the industry or market and why there is a need for your product. Think of this as your pitch.
- Vision – define the north star in one or two sentences. As an example I use the approach of comparing my product to one that is universally understood, Waze. My vision statement is “Waze for Midstream”.
- Background – describe the problem to solve, add supporting statistics, visuals and detail here.
- What is Possible – describe what is possible and provide evidence that the goal is possible to achieve. In my case, I use Waze as evidence of the possible.
- Goals (Expected Outcome) – Describe the problem the product will solve. How will it benefit your users.
- Measure of Success – Describe what metrics you will track to measure success.
- Reach – What is the potential reach of the product. For this I like to use the Total Addressable Market (TAM) 3 tiered model.
- Value – Describe and quantify the value it will bring both your users and to your company.
- Input from stakeholders and customers is vital
As product managers, even though we are ultimately responsible for all aspects of the product lifecycle, its success is dependent on the input and participation of the broader cross-functional team. The same holds true for the strategy and roadmap, it requires input and development together with the team including stakeholders and customers. It will be tough to unlock business value at the right time if the roadmap is developed in a silo.Early and often share the roadmap with your stakeholders, customers and business and ask for feedback. This approach has two major benefits. First, you will realize a shared understanding of where the product is headed. And second, you will receive valuable feedback on priorities and gain understanding on any gaps that might existing to unlocking value.
In order to have a productive meeting, come to the conversation with a roadmap, even if it is as a draft version and feels basic and simple to you. It is far easier for people to react to something rather than start ideating from a blank canvas. You will increase your speed to completion and show you have thought through the problem set.
- Strategy is best learned by doing
Lastly — and certainly not least — developing your strategy and roadmap skills is best accomplished by doing it. It is a difficult skill to hone and it takes time to develop. Be patient with yourself along the journey.
Reading about strategy and thinking about it will get you 10% of the way there. You will find that for every great article you read, there will be just as many approaches and principles espoused. My recommendation based on experience is to certainly do your homework and gather your learnings, then choose an approach that resonates with you at that moment, lean in, and start strategizing. Be comfortable with being uncomfortable while you learn, iterate, and establish your approach to strategy and developing roadmaps.
In summary, the most important key learnings I discovered during my journey in The Product Mentor program are, a release plan is not a roadmap, the former is tactical and the latter is strategic. Roadmaps should be theme focused and a theme can be unlocked at multiple points of a products evolution. Strategy is hard and requires practice. Mastering the art of strategy will set you apart throughout your career.
Sharon is a product manager at an energy company in Denver where she specializes in bringing to life an analytics product that makes sense of 7B streaming data points per day to transform how people makes decisions. She is a former technologist who prefers to live at the intersection of technology, big data, and humans.
More About The Product Mentor
The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…
Better Decisions. Better Products. Better Product People.
Each Session of the program runs for 6 months with paired individuals…
- Conducting regular 1-on-1 mentor-mentee chats
- Sharing experiences with the larger Product community
- Participating in live-streamed product management lessons and Q&A
- Mentors and Mentees sharing their product management knowledge with the broader community
Sign up to be a Mentor today & join an elite group of product management leaders!
Check out the Mentors & Enjoy!
Jeremy Horn
The Product Guy
The Product Guy 