From Mission to Product Strategy

As with mission and vision, we see a lot of confusion around what exactly a product strategy is. For some, strategy is the process of crafting a vision; for others, it is a detailed plan including all features on a roadmap. Instead, product strategy shall be considered as the link between high-level vision and the daily work of teams on the tactical level, where the strategy provides guidance without prescribing details:

Putting all of that together, we define product strategy by adjusting ProductPlan’s description:

While tactical details will be addressed later on the roadmap and feature level, the product strategy is crucial to ensure alignment across the entire organization:

• For teams often drowning in technical details, the strategy ensures an understanding of the long-term objectives — how pieces fit together beyond the immediate goals and features. This affects Engineering teams as well as Consulting, Sales, Marketing, or Customer Success.

• Across the company, product strategy serves as a framework for decision making guiding daily decisions around design, development, pricing, marketing, and distribution. Thus, the strategy helps to decide what to do and what not to do as well as with prioritization.

• When done well, the product strategy explicitly states what makes the product unique. No matter whether these are technical aspects, a top-notch user experience, or a different go-to-market — these provide guardrails for decision-making and ruling out bad ideas at an early stage.

On the way toward making the lives of customers easier, product strategy primarily means to decide about what to do and what not to do (now). A great litmus test to check the effectiveness of a strategy is to decompose it and, for each element, check whether aiming for the opposite would sound dumb:

• We want to build the best tool for… — well, who would aim for delivering the worst?

• We want to delight users… — well, who wants to frustrate them intentionally?

• We build stable tools for… — well, who would intentionally deliver software that falls apart?

To avoid such dumb statements, we suggest considering reasonable alternatives, checking what some competitors do, or what the current status quo is — and then describing how these aspects will be handled differently. Let us look at a few examples:

Think about such patterns; provide such explanations on demand when discussing the product strategy; use all these details to illustrate what is not part of your product strategy. But do not inflate your strategy statement by including all these details. Remember, the strategy needs to be memorable for the entire team. So, focus on the right part of the above table and formulate crisp statements around the relevant elements, which then become part of your product strategy.

The product strategy will typically consist of a handful of aspects, similar to the examples given in the above table. Sometimes referred to as strategic work streams, Melissa Perri uses the term strategic intents:

There should only be a few strategic intents at any time. Obviously, the total number heavily depends on the size of the company, but a single team should focus on a single strategic intent in most cases. Needless to say, of course, product strategy needs to be outcome-oriented and support the business objectives. If, for example, a ScaleUp company with a proven product market fit across small and medium businesses in Europe wants to grow, then the business could decide to focus on extending the leading position in its home market, to reach out into new geographies, to extend from SMBs to enterprise customers, and so on. The product strategy has to consider these and provide elements supporting these business goals.

While Purpose & Vision as well as product mission shall remain stable over a long period of time, maybe even decades, the product strategy will typically need to be adapted every few years:

• Hopefully, the team will achieve some strategic intents over time. Say a specific market entry will be successful or a new target segment has been unlocked. After completing such a significant milestone, it’s time to craft a new strategy to define where to go next.

• Likewise, markets change, and hence, external factors might force a change in strategy.

• While initially revolutionary, some technologies may become table stakes over time — so they are no longer unique and worth mentioning as part of the product strategy.

However, be careful: If you change your strategy every quarter, you probably don’t have a strategy at all.

In addition to the strategic goals the product shall address in the coming months and years, it may be helpful to define additional attributes that help teams make decisions while working on their projects, serving strategic intents. Examples include:

• aspects of technical architecture or non-functional requirements, such as a promise to always keep all services deeply integrated

• focus on top-notch usability, e.g., by constantly striving for the best user experience

• a selection of technical approaches for implementation, e.g., whether a product is entirely self-service or requires extensive service integration partners to be implemented

• design criteria to help with decisions, e.g., whether to favor the buyer or the seller in a marketplace in case of conflicting requirements.

Note that while these are called product attributes here, they are most likely relevant to the entire company, as they will also impact the Sales, Marketing, Consulting, or Customer Success teams.

In a later chapter, we will see how to transition From Strategy to Product Roadmap. For now, let us emphasize how a great strategy helps to structure teamwork: When there is alignment around a handful of strategic intents, as described above, each will probably be worked on for several months or even quarters and consist of multiple experiments, implementation projects, and technical approaches.

By grouping all these under the headline of the respective strategic intent they are serving, the roadmap can be organized in a way that provides a high-level overview and shows how pieces fit together, with the ability to narrow down on details when needed.