Last week I started a three-part article about crafting a Product Strategy in the Developer Platform and Tooling space. This series is based on Good Strategy, Bad Strategy by Richard Rumelt, and it's divided into three key areas: diagnosing the problem, writing the guiding policies, and finally, a set of coherent actions.
If you haven't, I recommend you read the first part, so this will make more sense.
With that in mind, let's dig into part two.
The Guiding Policies
As a non-native English speaker, I always thought that the word policy implied something very official, pompous, and impractical. According to Cambridge Dictionary:
Policy = a set of ideas or a plan of what to do in particular situations that has been agreed to officially by a group of people, a business organization, a government, or a political party
That's what a policy is - a plan or a set of decisions we make to achieve a specific goal. As a Product Manager, this is where the foundations are critical: discovering the problem space, understanding the users, and understanding the company's end goals.
Your guiding policies, or plan to put it more simply, guide you to solve the problem(s) and achieve the end goals. To craft an effective plan, you should:
Focus on a handful of key goals critical to the end user and the company's success.
Be pragmatic and realistic - know what you can achieve within your capabilities and market conditions.
Define your success metrics - this is where your plan has to be tangible and measurable rather than a bunch of buzzwords and fluff collected on a PowerPoint.
Be flexible - things change, market changes, so you need to operate flexibly.
Leverage your superpowers and identify the areas where you can innovate or have a unique advantage.
Link the guiding policies back to the first phase: the diagnosis. That will ensure your guiding policies are relevant.
The steps above enable you to create a flexible plan aligned with the organisation's strategy.
For example, suppose your diagnosis showed that the Developer Platform lacks critical functionalities, which slows down the engineers. In that case, one of your guiding policies might be to focus on solving that problem.
Similarly, if you are a PM on Developer Tooling and your diagnosis shows that your competitors are doing a better job with the marketplace integrations or developer support, one of your guiding policies might be to focus on that.
In addition, a good plan takes into consideration the broader market landscape. An excellent example of that is what is currently happening with the rise of Machine Learning and AI.
For example, suppose leveraging AI or building LLMs is relevant for you and the organisation. In that case, one of the guiding policies might be to focus on investing in R&D or make 10% of your Engineering function concentrate on R&D.
From my own experience of working on Developer Platforms and Tooling, I know that crafting a winning strategy can be challenging. However, I do believe that if you master the foundations, it's doable.
One thing to bear in mind is that you must regularly revisit and adjust your strategy, as needed, to remain effective. Having a clear vision and a practical approach will help you win. As Richard W. Hamming highlighted:
In science, if you know what you are doing, you should not be doing it
In engineering, if you do not know what you are doing, you should not be doing it.
See ya next Friday for part three and a practical strategy example!