One of the best books I've read recently it's The Art of Doing Science and Engineering - Learning to Learn by Richard W. Hamming. It's a brilliant book, at times technical, but brilliant nonetheless.
There is a particular quote that stood out for me and that I kept going back to:
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.
And I kept thinking back to my experience in Product Engineering and when I needed to figure out what we should focus on as a team. That usually overlapped with the need for a clear product strategy. And that's something you can quickly identify and course correct.
Product Strategy is one of the most talked about areas in Product Management, and there are a lot of frameworks, and how-to's out there.
My aim with this three-part series article is not to provide you with another framework but to build on the existing one - Good Strategy, Bad Strategy by Richard Rumelt. It's probably one of the best books on strategy out there—and easy to put into practice.
At the end of this series, I will develop a clear product strategy example focused on Developer Platforms and Tooling. Hurrah, I hear you say!
Context setting
Rumelt argues that many strategies developed in business, government, and other organisations nowadays are not strategies but rather a list of goals or tactics.
According to him, crafting a basic strategy involves creating a unique and sustainable competitive advantage that allows an organisation to achieve its goals. Pretty simple, right? In theory, yes, but in practice, not so much.
Rumelt outlines three components of a good strategy:
A diagnosis of the current situation. This includes an honest assessment of strengths and weaknesses, an understanding of the organisation's fundamental problems, and opportunities to solve those.
A guiding policy that outlines how the organisation will solve its problems and take advantage of its opportunities. This policy should be based on a deep understanding of the 1st point.
A set of coherent actions to implement the guiding policy. These actions should be tailored to the organisation's specific challenges and opportunities and should be designed to create a sustainable competitive advantage and growth.
There is the question of when you need a Product Strategy, and if there is already one at an organisational level, do you need another one? The answers are (in my view) the sooner, the better, and yes, you do.
This week, I want to go into more detail on how, as a Product Manager, you can work on diagnosing the problems and be very detailed and specific about it.
Key steps to take
Understand the needs of your partners: I would argue that this is probably the most important one. Work closely with your partners to understand their pain points, challenges, needs, and how they think about their tooling. Conduct interviews, design specific surveys, and create focus groups to gain insights into their thoughts and use of the tools. Ask if you can shadow them when they work on something. Don't do this alone, and make sure you involve the EM and another Engineer from your team. Or a Tech Lead.
Note that I use Partners instead of Customers or Users and that’s by choice, though you may have a different opinion. And that’s ok too.
Understand the current state of the market and what good looks like: Once you have a good understanding of needs and challenges with the current state, you have to look externally at the market. Research what are some of the best available Developer Tools and understand some of the trends (think about the rise of K8s or the growth of Rust, more recently). This analysis should include a deep understanding of the key players in the market, their strengths and weaknesses, and their product offerings. An easy way to do this is to read surveys, like the popular StackOverflow Developer Survey, Tech Radars, or two excellent newsletters that tackle this: The Pragmatic Engineer and ByteByteGo.
Know your organisation's strategy and objectives well: What I mean by this is that you need to have a good understanding of what the organisation is looking to achieve and where they currently stand in achieving those specific goals. It will enable you to identify areas where you can impact and innovate. A way to do this is to conduct stakeholder interviews, be very engaged and have a good overview of what the other Product teams are up to. Once you grasp that context, consider positioning the Platform or Developer Tooling area as an enabler for the overarching strategy.
This is the most challenging part, and you will sometimes struggle with it as a Product Manager. Or that's some of my experience, at least.
If you find it difficult to gain traction, find a champion or two, ideally at a senior level, a Head of Engineering, a VP of Engineering, or a CTO.
Finally, articulate the problems and diagnose: Based on your in-depth understanding of your partners, market analysis, and knowing your company's objectives well, you can clearly articulate the diagnosis and what problems you are facing in your area. This will form the product strategy's foundation and help you tackle the next phase, framing the guiding policies.
There are a few things to consider when articulating the diagnosis, and in my view, those are:
Be very specific and avoid lots of fluff, verbose, and buzzwords. Use bullet points and keep it short and impactful.
Make the problems quantifiable or have some qualitative data to back you up.
Framing matters, so you have to show that in diagnosing problems at an Engineering level, you understand the company's goals too.
Although it may seem daunting or complex, this is the fun part - because you speak with your partners, analyse data, and basically fall in love with the problem. I know it sounds cliche and corny, but you kind of have to :)
I will leave it here for now and pick this up again in Part 2 - The Guiding Policies.
See you next Friday!