The Product Career framework is a good start for a PM to think about how to drive their own development, but how it should be applied requires nuance. I am writing here my perspective on the career framework and the role, sourcing inspiration and advice from my own experience so far. I recognise that what I need out of PMs in my group will be different from other GPMs, so my goal is to show my perspective and expectations to make our teamwork as smooth as possible. My thesis is to have impact and recognition will follow, but experience helps impact unfold. I hope with this a PM can set themselves up for success, drive their own development, and set us up for success to have great impact together.
In the coming three posts, I have taken the three pillars of a Product Career Framework, broken them down and mapped out my interpretation for how I apply them for Platform Product Management. Together, a PM I work with and I can then use this breakdown to discuss development areas and set goals. Depending on the context, certain parts of this framework and breakdown may be more relevant than others at a given time. When there is overlap between a PMs interest, ambitions, and business need, we should set an explicit goal together.
Vision and Strategy
Deciding and aligning on what we should do AND what we should NOT do
Learning
Quite often we are responsible for driving impact in a nebulous problem space. There are various approaches which can be used to find clarity in the nebula. When we need to learn, a PM should understand enough of the current state to choose what they believe is the right tool for the learning necessary. For example:
Learn about the Tech
We are building technical platform products, which means in order for us to be successful we must understand the tech we are suggesting to build. Armed with this understanding, we can partner with engineering and suggest solutions that are both feasible and present a viable solution to the problem at hand. Then this understanding helps us empower our engineering teams to build it. We aren’t expected to get to the same level of understanding as the tech experts we partner with, but the more we understand the more we can contribute.
Learn about the Users
Platform products have users which are just like consumer facing products, but with key differences and benefits. It’s easy to operate as though we have a captive audience since we are providing the platform that users SHOULD use to solve their problem, but if we misunderstand the user’s motivations, goals, and jobs they will find other solutions and ignore our product. We can use quantitative and/or qualitative insights to better understand our users and try to solve for their needs in a way which is a win-win for our goals as a platform, and their own motivations.
Learn about the Strategic Context
Another tool to better understand the problem space is to focus on why it matters to our company. How does this problem space fit into the big picture? What business objectives is it connected to and how? The context which surrounds a problem is a very important tool to use for influencing others to collaborate with us when solving a problem, and also specifically to understand if we should be instead solving a different problem.
Learn about trends and competitors in the industry
The problems we have may feel very company specific, but when we take a step back and understand the business needs we solve for it is obvious that they are common across most large consumer tech companies. Platform products are unique in the sense that generally the aspects which make them successful are not secret, and are generally a source of branding for engineering excellence. There are public blog posts, conference talks which we can find form our peer companies and use for inspiration, and we can also set up knowledge sharing sessions to get into more details. Competitor trends in this case is not referring to business competitors, but instead other alternatives that others in the industry use to solve the same problems as us, like for example Kafka and Pub/Sub.
This list of approaches is definitely not exhaustive, and depending on the experience of the PM it may not be easy to determine when to use each approach. We should also be mindful of when we have learned enough. The more ambiguity in a problem space the more time we need to spend learning. It is also from experience that we determine when it is time to pivot from learning to strategising and doing.
Forming an Opinion
Armed with a thorough understanding of the problem space, it’s time to form an opinion on how to approach it.
Vision
The Product Vision paints the picture of the perfect world when we have completely solved the problem space. Having a vision for the problem space is a critical communication and alignment tool for the squad(s), users and stakeholders. It also places much needed constraints on the set of viable solutions which the team should consider. And while this is a product vision for us as a Platform PMs, if it is to be impactful it will also represent a critical component of the company's technical strategy for the technical domain. The Product Vision for a platform product will be tech. It must be done in partnership with the domain experts for that tech at our company or it won’t get the traction needed to be impactful.
Strategy
Once the grand vision is in place, we need to be opinionated on how to do it. Good Strategy should present three things:
A Diagnosis of the problem space, which we formed in the learning phase
Guiding Principles which we want to follow, which are constraints we abide by en route to the vision
A set of Coherent Actions that represent the “next steps” we believe we should take.
With the ambiguity in a problem space, there are likely a variety of approaches we could take, each with their own tradeoffs. That is why this way forward is an opinion as opposed to a provable “best” approach most of the time. It is also built on a mix of facts and assumptions, so it is unlikely that we map out each and every of the steps needed towards eventually achieving the vision.
Instead we map out only the steps that will be required to learn more, and then reassess what comes next. Because of these assumptions, it is important to strive for iterative impact. We will be learning and validating our assumptions as we go, which implies we might realise we were wrong and decide to change course. If the strategy only is impactful at the end and is based on wrong assumptions, we will face either a huge sunk cost, or risk moving towards a vision which is no longer a good idea. With iterative impact, we can easily pivot based on our learnings while still having achieved something useful.
Lastly, an incredibly important and often overlooked part of strategy is being opinionated on what NOT to do and why. We can only do so much, and if we try to move on all the possible approaches to solving the problem it is likely we fail on all of them. Strategy must be opinionated on the approach which we believe we should take, and provide the focus to our squad(s) to empower them to do it well and quickly.
Influencing
Once we have a strategy, we need to use it to align our team, our users, our stakeholders and our management structure around the approach that we will be taking and why.
Write it Down
This might sound obvious, but driving strategy with conversations, verbal presentations, and shared context will likely not succeed. Since the strategy has built in assumptions and opinions, it is very likely that those we need to align the strategy with may have different assumptions and disagree with our opinions. This implies that strategy is ripe for misinterpretation. By producing a shareable artefact of the strategy, it makes explicit the assumptions and tradeoffs considered in the opinion. And by making these explicit it invites conversation from counter arguments and those who made different assumptions. This is valuable for eliminating misunderstanding, achieving alignment AND triggering the conversations which could spark other creative solutions that are worth exploring.
Speak to the right Audience
The artefacts of our strategy are alignment tools. We are seeking to align across several levels of individuals, from the most technical engineers on the team, to VPs who will only understand the high level aspects and won’t give it more than 10 minutes of thought. We need to be concise where necessary, and detailed where necessary. This probably means that we require multiple different approaches and artefacts to achieve this alignment, depending on the need. These artefacts also unlock the ability for asynchronous collaboration, which is especially important in a team which is distributed across time zones.
For example, for a single strategy I may have the following artefacts:
Main Strategy Document
Executive Summary
Detailed Diagnosis
Roadmap
Slide Deck
Presentation I am ready to give
Video (Recorded Presentation)
This might sound like overkill, but lots of them link together, like for example the slide deck, presentation and video. The trick is to make sure they also produce sharable artefacts.
Repeat it Over and Over (and over) again
People will engage with our communication differently. Some will understand right away, others will take some time to get onboard to our thinking, others will ignore it completely. In order to effectively achieve alignment around our strategy, we may need to unapologetically repeat it more often that feels reasonable.
All three of these aspects of the Strategy pillar are collaborative. It is not expected for any individual to do everything for each step. In some cases they should be done in a partnership with tech or insights, in some cases we should form allies and delegate in our org or other parts of the organisation in order to scale ourselves. But as the Product Manager we will be evaluated on the result, so we need to ensure that it happens. These aspects of scaling ourselves and developing trust I will touch on in the next section about leadership.
Leadership
It’s all about developing, keeping, and leveraging trust
Impact
Get Shit Done
New to PM? Check out this post with some learnings from the early days, or this Podcast episode about strategy and roadmaps