4 ways to level-up your product strategy

Developing your product strategy and communicating your product roadmap is a continual improvement process. Over my time as a product manager I have learned from some incredible product teammates on how to level up your product strategy to ensure it is as informed as possible, and communicated to your organisation’s stakeholders and customers in the most effective way.

Break your roadmap into focus areas

Focus on the problems you are trying to solve, not the features you are going to build. Thinking of your roadmap in terms of features is an easy option, as people are likely to be opinionated on specific features and keen to discuss implementation details. But this can cause difficulty when trying to create alignment of the higher-level picture — people are tempted to get into the nitty gritty of the feature and how it should be executed, rather than concentrating on solving the right problems for the next 6 to 12 months.

Remove features from the conversation, and instead bring focus areas or user problems to the conversation. For example, if you are a travel app, a focus area or user story could be “As a user I want to easily save my travel search criteria.”

The focus areas should be clear and straightforward, and could be used throughout the company as a common reference.

Watch this AMA on Perfecting product roadmaps with Janna Bastow.

Create product principles for what is important to your team

Product principles are a set of beliefs and intentions that reflect your team’s values and vision for the product. Deciding on what these values should be as a team will create alignment within your product design function. As your product design grows, it can be difficult to maintain consistency with product decisions being made at different times and with varying agendas between product managers.

Creating product principles provides direction and keeps the team grounded. Once the team agrees on these principles, they can be used to inspire product improvements, which can be linked back to the problems you are trying to solve. It is best to limit your product principles to around 5, to make sure they are memorable! Here is an example of one of Buzzfeed’s product design principles:

Design for scale. Design with an eye toward the future of our products. Value flexible, scalable designs that can quickly evolve alongside our content.

The product design team should be the main driver for setting these product principles with a facilitator. The DACI framework can be useful to keep you on track. Once there is a first draft, gather feedback from key stakeholders, especially your engineering teams. Doing so can give you clarity as to why certain product decisions are being made. You can also incorporate your product principles into your product design reviews and product specifications, where possible. This can be a handy tool to prompt you to make sure you are asking the right questions!

Understand why you win, and why you lose

What does your product excel at? What are your biggest feature ‘moats’ (features that the competition will struggle to catch up with)? This is important to understand through the lens of competitive analysis and continual user feedback. But, arguably, understanding your weak spots is of more importance.

Especially for B2B products, it is impactful to create strong relationships with your go-to-market teammates and to invest time in understanding why certain deals were lost. Win-loss interviews remove the guesswork out of what is working in your product and what is not. These interviews can help you gain clarity on your product gaps, the most important part of your product, your product-market fit, and insights into your competition.

The product team can take ownership of documenting the outcomes of these sync-ups in a centralized place, so they can understand the trends that emerge over time. This can be a really powerful tool for quarterly lookbacks, and when planning where next to invest in the product.

Read Only losers average losers

Formalize the process for gathering feature requests

As your product team grows, you and your colleagues will be attending different customer meetings and gathering different research. This is excellent, but you can easily fall into the trap of many different documents and notes floating around, and different feature requests with varying degrees of information tied to each of them.

Creating a formalized process for documenting feature requests in a centralized place can be really impactful. Over time, this aggregated data leads to easier decision-making, particularly in the context of creating stakeholder alignment. For example, it is useful to document each feature request with the same level of detail, such as:

• Monetary value of the customer
• Which focus area this feature request belongs
• Their business use case for the feature
• Whether this is a competitive gap

You can also gain more insights by documenting these with a many-to-one mapping against your backlog. For example, mapping 10 feature requests to 1 backlog item allows you to gain an insight as to what is really important to your users, rather than just documenting the feature request one time. Airtable or a simple Google sheet are useful tools to get you started for this process. Over time, this process provides the product team with more context and data to bring to prioritization conversations.

No matter what techniques or methods you use, don’t forget that levelling-up your product strategy is a continual process as your product and product team grows. I would love to hear from other product managers on what techniques they have used, and what you’ve found success with.

Originally published on Mind the Product