Owning the Product Direction as a Product Leader
16 February 2020 ‧ 16 min read
One of the crucial areas of responsibility for product leaders is owning the product direction. For an overview, read my high-level article on product leadership responsibilities, or continue reading for a deep dive on product direction.
Owning the product direction can be broken down into seven aspects:
- Product Vision
- Product Strategy
- Product Roadmap Themes
- Goal Setting
- Product (Design) Principles
- Evangelism of the Product Direction
- Guidance and Feedback
Owning the product direction means ensuring that all of the above aspects are taken care of, although product leaders do not necessarily have to do something about them at all times. For example, in single product companies, the product vision is often the same as the company vision and hardly changes, so there isn't much ongoing work for product leaders on the product vision (except evangelizing it).
In the following, I will go in more depth on each of these aspects.
Product Vision
While there isn't a broadly accepted definition of what a product vision should look like, I think that a product vision is best defined as the purpose of the product, expressed in terms of the aspirational customer benefits the product aims to achieve.
The product vision should be written in a way that enables it to remain stable for years, serving as the north star of the product even as the exact offering and even the business model evolves. It is therefore best if the vision is formulated in a way that is independent of the actual product and business implementation. Think something along the lines of the original Google mission "to organize the world's information and make it universally accessible and useful". This statement describes a benefit (information being accessible and useful), is independent of the product and business model (Google could be operating libraries under this mission), and highly aspirational and thereby able to remain stable for a long time (it's hard to imagine ever achieving a state where all the world's information has been organized, made accessible and useful).
In single product companies, there is not much benefit to having a separate business vision/mission and product vision, so it is often best if the company vision is formulated in such a way that it can also serve as the product vision. In multi-product companies, having individual visions for each product makes sense, although they should of course relate to or ladder up to the company mission. As an example, consider the product vision for Yammer, Microsoft’s enterprise social network, “Empower and connect every person across an organization to maximize their impact”, which is related to but different from the overall Microsoft mission statement “to empower every person and every organization on the planet to achieve more”.
In addition to being independent from the actual product and focusing on aspirational benefits, a product vision benefits from being simple and memorable. You want this vision to guide people's actions and decisions, and for that to happen, they have to first remember it. The vision should be distilled to its core idea—everything else can be added on at the level of strategy. Another benefit of reducing the vision to its core is that it more likely to remain stable for a long time, making it more likely that people will use it in their decision making process. If the vision has to change every few months, then soon people will simply disregard it as too noisy an input to use in decision making.
Since the vision should stay stable for such a long time, I don't think there is a tried and true process to develop one. In the end, setting the vision is really a leadership decision, perhaps even taken by a single person (like the founder or CEO). A big participatory process is more likely to lead to a vision that is a compromise trying to appeal to more stakeholders. A good vision is motivational but also sharp and differentiated.
Product Strategy
In contrast to the vision, which is by nature lofty and ambitious, the product strategy needs to be concrete in terms of defining “how we will win”. The product strategy identifies and prioritizes challenges that the company must tackle in order to realize the vision, and provides guidance how these challenges should be addressed.
The product strategy should first define the target customer segment and how value is delivered to them. This value creation is at the heart of the product strategy: if no value is created for customers, then there is no sustainable business. In order for value to be extracted by the business in the form of revenue, it first needs to be created for customers and users.
The second aspect that needs to be covered, accordingly, is how some of the created value is extracted for the company, in other words: the business model. For stable companies, there might not always be the need to talk that much about the business model in the strategy if there are no plans to adjust the business model, but for startups, this might be a crucial aspect of the product strategy.
The last aspect to be covered is that of competition: how is the product differentiated from competitors, and what are “moats” that the product is aiming to build (sustainable competitive advantages)? In general, startups or new products should focus more on product-market-fit (the first two aspects) than on the competition, and certainly should avoid trying to play four-dimensional chess (trying to predict and preempt every move of the competition), but having some thesis for the unique selling points of the product is necessary.
A good strategy should be valid for a time frame of multiple months to several years. While some adjustments are natural and healthy over time, it is best if the core direction can stay stable. One way of codifying this change over time is by describing how the target audience and the value delivered is going to evolve over time—in other words, describing a series of product market fits.
It's important to understand that a product strategy is not a detailed plan of how the product should evolve. Instead, it should be seen as a framework to make decisions. Defining your value to customers, your business model, and your differentiation from competitors should be done in a way that doesn't too narrowly define what you will build. There still needs to be room to discover the actual customer needs and deliver solutions for them. As an example, "build import filters for files produced by tools X, Y, Z" is not a strategy, that's a feature list. "Integration with existing workflows and tools of our customers" might be a better strategy covering the same idea, but more open to discovering the real customer needs.
A strategy is much more involved and extensive than a product vision. Typically, it would be documented in a presentation or written document. However, a strategy should still have a high-level story or summary that is easy for everyone in the organization to grasp and remember. While the product vision serves as the north star and inspiration, the product strategy makes it concrete where the product is headed. In order for people to take the strategy into account in their decision making, they have to be able to remember it.
As an example, let's consider two eras of product strategy at Yammer. When I was working in the Yammer product team, the strategy was to build a great collaboration tool for teams working together in Yammer groups, monetized as a freemium model. As you can imagine, there was more to the strategy than just this one sentence, but it nicely summarizes it. It includes a target audience (teams) and a way that value is being delivered to them (collaboration tool), as well as a business model. The current product strategy (gathered from publicly available sources only) is to focus on leadership engagement, knowledge sharing, and building communities, integrated as part of the Microsoft 365 suite. Again, this (implicitly) includes a target audience and value proposition, along with a business model. As before, I am certain that there is a lot more depth to this strategy than this one sentence, but it can be neatly summarized in a way that everyone on the team can remember.
A good starting point for thinking about the strategy is the following product positioning template from Geoffrey Moore's book “Crossing the Chasm”.
For (the target customers)
Who (have a certain need),
Our product is a (product category)
That provides (compelling reason to buy).
Unlike (the product alternative),
Our product (has these key differentiators).
As mentioned above, there needs to be more depth to the strategy than this one sentence, but the template provides a good starting point for considering some of the most critical aspects.
The product strategy is owned and needs to be defined by product leaders. However, in contrast to the vision, it needs a lot of input and feedback from individual product teams. Firstly, they are (should be) the domain experts: they know their part of the product, they know the customers and their needs, and they have explored potential problems and solutions. Secondly, gathering input broadly helps achieve alignment: regardless of what strategy product leadership will decide on, members of the individual product teams will be far more likely to buy into the strategy if their concerns and viewpoints have been listened to in the process. A typical strategy setting process will therefore be initiated by product leadership, gather input from individual teams, consolidate and make high-level decisions at leadership level, get feedback from individual teams on the integrated strategic plan, and then refine at leadership level.
Product Roadmap Themes
In 2020, a product roadmap should not be a list of features and dates that product leadership has decided on. Therefore, the product roadmap isn't really a single artifact, but rather a hierarchy of documents and decisions made at multiple levels—some made by product leadership, some by individual product teams.
I've written a dedicated article about an idealized process to create product roadmaps which has a lot more details. The role of product leadership is predominantly to define and prioritize roadmap themes. A theme is a focus area like “Improve new user onboarding”. It is akin to an objective in the OKR model, but since themes may be worked on for more than one goal-setting period, they might be slightly higher level. Of course, you can also use the same definition as both the theme name and the objective. However, since the exact phrasing of objectives tends to be heavily negotiated, I prefer themes that are a little more vague, and you can leave the exact scoping and definition to the goal-setting process (see below).
This high-level, theme based roadmap should not be assigned precise dates. Rather, it is the responsibility of product leaders to put these themes on rough time horizons: what are we doing now? What is being prepared to be worked on next? What themes will have to wait until later?
Like with the product strategy, the prioritization of themes on the high-level product roadmap should be based on input collected from product teams, but in the end, it is a product leadership decision.
Goal Setting
In most tech companies, goal setting is how ownership is passed from product leadership to individual product teams. Cross-functional product teams (typically consisting at least of product management, product design, and engineering) are assigned to each of the prioritized roadmap themes, and goals are defined for each theme and team.
Typically, it makes sense for product development goals to be set as part of a larger company-wide goal setting process. Many tech companies use the Objectives and Key Results (OKR) framework for goal-setting, often done on a quarterly basis. This has the benefit of being able to prioritize (or re-scope) product goals against all other goals of the company, and also that the involvement of other stakeholders in product goals can be clarified. For example, if there is a product goal that requires involvement from marketing to be achieved, then it helps if that goal is not defined as specific to the product organization but rather as a company level goal. The same holds true the other way round, of course: marketing goals that require product work need to be taken into account when planning product goals, so that the product organization doesn't have to scramble to fulfill their own goals while also supporting other teams' goals.
If the organization uses quarterly OKRs, it's generally a good practice to start with one objective with 3-5 key results per roadmap theme and team. Spreading objectives across teams dilutes ownership, and once you have more than one objective with a manageable number of key results, the teams lose focus. Key results should ideally be defined as outcomes: business or user metrics that are proxies for value that has been created or extracted. Example of outcome metrics are revenue (business metric, value extracted) or user activation, engagement, retention, and satisfaction (user metrics, proxies for value created). Less preferable, but sometimes necessary, are delivery goals (“ship feature X”) or process goals for learning (“user test Y prototypes”).
Since goal setting is how the responsibility for the product roadmap gets handed over from leadership to individual product teams, it needs to be a joint process. Often, product leadership will set the "drum beat" and initiate the process by drafting objectives and potential key results, but individual product teams will contribute and need to agree on the goals set for them as well.
In addition, goal setting is often a scoping exercise. For example, a roadmap theme might be “Improve new user onboarding”. However, there are likely many parts of the new user journey that might be in or out of scope. Are we talking about the signup flow or the in-app experience? What are we trying to improve: activation, engagement, retention, conversion to premium? Should we focus on a specific user segment? All of these questions require answers and potentially some research before decisions can be made. It is often best if the product team that will tackle the theme is conducting this scoping research, since it contributes to building an understanding of the problem space and will lead to greater alignment on the goals that are agreed on.
One issue that I have not yet seen solved in a completely satisfactory way is that of timing. In a theoretically ideal world, you close one quarter before you start the next one. In a practical world, however, that doesn't work: the impact of last quarter's work on metrics will often take more time to materialize. A/B tests might still be running, lagging indicators such as retention might need more time to be measured and so on. In addition, the scoping work mentioned above needs time as well, so if you start that only at the beginning of the quarter, you lose time. I therefore think that the goal setting for the following quarter needs to start several weeks before the end of the current quarter. That means, of course, that you can't fully take stock yet of what you did and didn't achieve this quarter while planning the next one. You will often have a rough idea how you are tracking toward the goals, but not full certainty. It also means that for product teams, some time needs to be spent where work for one quarter is being wrapped up while the next quarter is being scoped. However, that is preferable to organizational paralysis happening between goal-setting periods.
Product Principles
Whereas the concepts discussed so far are pretty much mandatory for effective product development work, product principles are less wide spread. Product principles, sometimes also called product design principles, are fundamental values and beliefs that guide product decisions. These principles should not be general best practices (like “our product should be easy to use”—no one would argue against that), but rather explicitly prioritize, be specific to the product and company, and be differentiated from similar companies. This ProductPlan blog post has many good examples.
Product principles should align with company values, but they are more specific to product decisions, whereas company values are more about behavior. Also, company values should be relatable for all employees, whereas product principles are focused on the product organization. That said, since product principles can and should be used to justify product decisions, they should be written in a way that is understandable also by stakeholders outside of the product organization.
While not all product teams have explicitly defined principles, it is worth noting that often they still exist implicitly. For example, Yammer did not have explicit principles, but there were still some underlying values and beliefs in how we developed the product: for example, making decisions in a data-informed way, which included A/B testing most features, or prioritizing the end user experience over the customer to focus on viral adoption of the freemium product.
Product principles are so fundamental to how the team operates that they should be defined in a similar way to company values: ideally, they are defined very early on by the company founders, and then revisited only when something substantial changes. If product principles are defined at a later stage, it is best to solicit input from the broader team. A great prompt for this is to identify tough product decisions and tradeoffs and recall why the decision was taken the way it was. Can underlying principles be distilled from the decision?
Product principles, like company values, only make sense if they are consistently used in decision making. Especially when product principles are first introduced, product leadership needs to evangelize the principles and refer to them frequently in feedback and guidance. After a while, referring to the principles will become a habit and will it have to be encouraged as much by product leadership anymore.
Evangelism of the Product Direction
Coming up with the product vision, strategy, principles and prioritizing the high-level roadmap themes is not enough. A lot of the work of product leaders is evangelizing them. Evangelism here means communicating the product direction in a way that achieves understanding, buy-in, and ownership. Evangelism is required within the product development team, but also to stakeholders across the organization, and perhaps even outside the organization to customers and partners.
Communicating the product direction requires focus, consistency, and persistence.
Focus means distilling the ideas down to their essence and cutting out any excess information. It also means picking and choosing when to communicate what part of the product direction—if you dump too much information on an audience at a particular point in time, they will retain none of it.
Consistency firstly means that the message shouldn't change over time, or at least, that change over time should be minimized. This means that the process to develop and communicate the direction needs to be carefully managed to decide when feedback is still being collected and when the direction is "final" for broader consumption. Of course, this doesn't mean that the organization should avoid changing course when that is required, but in the absence of a need to change direction, the communication about it should stay consistent. Consistency also means that the direction and therefore the communication about it has to be internally consistent, in other words, the parts of the product direction shouldn't contradict each other. If there is a product principle that X should be prioritized over Y, but the roadmap prioritized Y over X, it causes confusion and people will not buy into the direction.
Persistence means communicating the direction again and again, more often than the product leader feels is necessary. Product leaders are intimately familiar with the direction and think about it every day. The same is not true for anyone else in the organization—even product managers spend much more of their time thinking about more tactical decisions. If they hear the product direction once, twice, a few times, they might nod and think it makes sense, but for it to really be remembered, product leaders will likely have to communicate the direction more often than feels comfortable.
The most effective communicators also use stories and appeal to emotions to make the audience remember their messages. For more tips about this, I recommend checking out the excellent book “Made to Stick” as well as “Unleash the Power of Storytelling”.
Guidance and Feedback
Once the product direction has been handed over to individual product teams through prioritization of high-level roadmap themes and setting goals for each team, product leadership shouldn't disappear into a hole until the end of the quarter. As product teams work through the discovery, design, and development processes, product leaders should help them with guidance and feedback.
There are several critical aspects to this guidance. The first is about the product development craft itself, helping the teams get better at discovering customer needs, developing options to address them, validating those options, and delivering the most promising one. This aspect is not related directly to the product direction, and I will cover it more in a future article.
The second aspect is about alignment across teams. Of course, goals should be set up in a way that avoids conflicts between teams, and individual teams should also feel empowered to directly collaborate with other teams without having to go through leadership. However, product leaders are still the ones owning the overall direction and interfacing with all the product teams, so they are the most likely to notice any need for additional coordination. This coordination might come in the form of knowledge sharing, meetings to resolve interdependencies or conflicting assumptions, or setting up joint task forces.
The last aspect is the one that requires the most delicate balance: while individual product teams are empowered to make decisions how to achieve the goals they were assigned, product leaders are entitled to their own opinion regarding the future of the product as well. Often product leaders have a lot more context and experience than people on the individual product teams, so it is only natural that product leaders want to share their own opinions. However, if product leadership jumps in too often and makes decisions for the team, it feels disempowering to the team (at Yammer, we called this "swoop and poop", the leader swoops in like a seagull, dropping some wisdom that the team has to deal with).
The key to achieving this balance is establishing a healthy debate culture and clear allocation of decision power. A healthy debate culture is one in which people aren't holding back their opinions and ideas, regardless of their hierarchy level. In this kind of culture, it will be naturally accepted that product leaders share their thoughts without necessarily considering them instructions. It helps to frame meetings where such feedback is exchanged as debates and separate the decision making from it, so that when all arguments have been heard, there is no need to keep discussing until a conclusion is reached. For more tips on creating a healthy culture of feedback and debate, I recommend reading the book “Radical Candor” by former Google exec Kim Scott.
In terms of the decision power, it is crucial for the empowerment of the product team that the vast majority of decisions remain with the team. It is also critical though to be unambiguous when feedback is to be understood as binding. A good framework to use is “Do, Try, Consider”: do feedback is mandatory (and used rarely), try means the team is given an additional option or idea to explore or research, where the exploration itself is mandatory but the decision how to act on it is the team's, and consider is completely non-mandatory “food for thought” feedback.
In order to provide this feedback, the right forums also have to be established. There are mostly three types of product feedback forums: one-on-ones, critiques, and executive reviews.
One-on-ones should be happening on a regular basis anyway between product leaders and their direct reports, and one of the objectives of 1:1s is coaching of the report by the leader. Providing feedback on the work is of course one of the ways to do this. In order to not undermine the team dynamic, it is often advisable to severely restrict the amount of mandatory (“do”) feedback in one-on-ones—otherwise the report keeps having to be the “bearer of bad news” to the team and having to defend a decision they didn't necessarily agree with.
Critiques are peer feedback sessions, in which a team or team member presents their work to their peers (e.g., a designer to other designers, a PM+designer to other PMs and designers, etc.) in order to receive feedback. Feedback on critiques can come from peers, but of course also from product leaders. Critiques are not decision meetings, and mandatory (“do”) feedback should almost never be given. I would consider having critique meetings a best practice, but the setup may differ from organization to organization. For more tips, I recommend the GV guide to design critique.
Executive reviews are meetings in which a product team presents its solution to leadership, often before entering the full implementation phase. These meetings are most appropriate for any mandatory (“do”) feedback to be delivered, but as mentioned above, that should still be used extremely sparingly to avoid a feeling of disempowerment in the team. Executive reviews should ideally happen with the cross-functional product team in attendance in order to deliver the feedback directly to the whole team. Not all organizations have executive reviews, or at least not for all product work. The fact of the matter is that even though most feedback given might not be mandatory, the fact that the work needs to “pass” through this leadership “stage gate” might feel disempowering to the team and also might lead to a less lean, iterative process: if nothing can be built before the executive review has happened, then product teams might feel the need to build solutions out more “in theory” before they dare discuss them with leadership.
Ownership of the product direction, including evangelism and guiding product teams along that direction, is one of the crucial responsibilities of product leadership. The more mature the company, the less ongoing work is required to set the direction, but evangelism and guidance will still be required. Also, in very small startups, some of the layers of the direction “pyramid” might not be as formalized, since shared understanding is generally easier to achieve in a smaller team than a larger one. However, clarity of direction and continuous alignment of the team—through evangelism, guidance, and feedback—is required in all stages of a company and a product.
Without a clear product direction, it is still possible for product teams to continue optimizing an existing product for quite a while, just by looking at generally applicable product success metrics (like retention and revenue, for example). However, over time, evolving a product in that way is going to make it become non-differentiated and “shapeless” after a while. Metric-based optimization without a vision leads to a product that doesn't tell a story and tries to appeal to everyone, which means it will eventually fall behind competitors who know what their value proposition and their target audience is and more strongly cater toward that target audience. Shaping the product direction is therefore a highly critical part of product leadership for the product to be sustainable in the long term.
I hope this article was helpful. If it was, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.