Milena Krasteva

This reminds me of an interview question I got a very long time ago: "Is it better to have a bad team or a bad manager". In both cases, you'd rather not find yourself in either extreme. In both cases, there is no right or wrong answer and a lot depends on additional circumstances and assumptions. The answer will also depend on your value system and the experiences which have shaped your core beliefs about human aptitude and potential. For the sake of argument, if I had to pick, I would first apply the same framework: which suboptimal option is more mitigatable. I believe that most people have the capacity to learn the facts of the domain, the technical aspects, I.e. the hard skills, with sufficient effort and time. On some level, I see acquiring the hard skills in this contrived case akin to suceeding in a college course you know nothing about but are highly motivated to ace. The soft skills can also be learned, but these are much more entangled with personality, self-awareness, communication style, etc., all of which develop and become ingrained over the years. They are harder to inculcate artificially or to undo as bad habits. Poor soft skills can burn bridges and set the course of nascent relationships on the wrong trajectory, impacting your ability drive results far into the future. No amount of hard skills may be able to offset that. Good soft skills can even buy you time to get up to speed on the hard skills, and can get you critical early support from the team to actively help you get there. This is why if I had to, I would pick the soft skills option.

It seems all too easy to NOT get roadmap buy-in. Sometimes, it can feel like the default answer is always "No" at first, and despite all the work you have done, you are getting sent back to the drawing board. Some things that help, not in any particular order: * Go as wide as possible early on as pre-work to understand stakeholders' motivations and identify any possible opposition * Dig deep to identify the true source of the opposition. Listen a lot, ask questions. Treat this exercise as part of requirements gathering. * Identify dependencies early * Tie roadmap item to financial impact upside * Is the impact estimate credible and defensible * Is the level of effort astronomical, or disproportionate to value * Is there a downside, beyond the lost oportunity of not doing the feature * Tie roadmap to broader strategy * Are you potentially missing technical or other considerations? * Have you been transparent and collaborative? Is anybody going to oppose the roadmap because they were excluded from discussions and decisions * Get exec buy-in in smaller forums, early, even at the conceptual level * Build a coalition of active supporters - there is safety in numbers * Assume positive intent * Seek to educate not sell * Seek common ground * Consider earlier conversations as setting the stage and foundation for later decisions. Aim to first not get a "no", rather than pushing for an immediate "yes" * Give yourself enough time to work iteratively through to buy-in.

In my experience, the learning curve happens in the current role, as a prerequisite to transitioning into the next. You have to be operating at the next level already and there really isn't an easing of the transition beyond that. For example, managing wider scope, solving harder problems, navigating trickier interpersonal dynamics, connecting more "dots", communicating with more clarity on more complex matters, and influencing more people and outcomes, are among some of the skills needed at every PM level, but to different degrees. As you showcase these skills you are already solidifying the foundation for the next level. One of the biggest learning challenges can however come at later levels - when transitioning from IC to manager (irrespective of the accompanying title), partially because it is a binary situation. You are either a manager of people or you are not; there is not much preparing or gradual transition. Relatedly, many PMs are seeking that check-list, that when done, spells promotion. Consequently, one of the most frustrating and non-actionable things that managers can say is "you are not ready yet", perpetuating a bit of the feeling that there is some transition or steep learning that one must overcome. Often it means the manager is not ready to do that for you but is uncomfortable giving you specifics. Or it is not possible in the current org strucure. Sometimes, they just don't know themselves, but they'll know it when they see it. Perhaps, that is a big hint. Observe how others at the next level are operating as preparation. How big are their projects? How much more do you have to know or do? The criteria can be very different by company, that's why it's important to know any published leveling criteria. But generally, even then, there aren't a lot of clear-cut check boxes. Sometime the criteria are only in your managers head. I once had a manager tell me that if I grew my product to $50M or $100M in revenue it would get me promoted. (My answer was to remind them that we were working on 5-year incubation, hence low likelihood of multimillion dollar outcomes on any reasonable timelines, and that this criteria should have been articulated a lot earlier in the job decription. Plus there were plenty of examples of promotions without that criteria - so the aforementioned criteria disappeared from our conversations.) In all cases, cross-reference everything official with what you actually see happens day-to-day and what behaviors or results are rewarded at the next level. Perhaps, the steepest learning curve is learning what specifically gets you promoted at your particular company and with your particular management chain.

Many promotions happen because the person was already performing and showing up as being at the next level. Depending on the company, the Director role marks a clearer line between individual contributor roles and management roles. However, unless the promotion is accompanied by a significant change in scope or new formal reporting lines into the role, perhaps the most surprising thing is that much else remains the same. You might now be on some additional distribution lists for Directors and above, but most of that is also related to people-management. 

The two disciplines are very different, despite some intersections on go-to-market, outbound communications, and occasional blurred lines between the roles in some companies regarding strategy and customer requirements. Early on in my career I had the opportunity to simultaneously work in both functions and experience them. Product Management has very broad scope and deals directly with technology. Ultimately, for me, building (or fixing) products felt most rewarding. :)

One area of frustration is when everybody wants to play the role of product manager informally but very few have any formal training or experience in product management. This manifests as all kinds of well-meaning (and sometime not so benign) solutioning, which actually attempts to bypass the product management function, then leads to really suboptimal business outcomes. Often this happens due to misaligned incentives in other orgs (We're innovating!?). Good ideas can come from anywhere and the PM function should help prioritize and evaluate, but chaos ensues when the main role of the PM becomes staving off the onslaught of point solutions. Other forms of encroachment are especially frustrating, when they are within the product teams themselves. Individual PMs can start defining new variants of feature/functionality that another PM already owns. They may do that under the guise of "GSDing" to advance their product area without coordinations and without dealing with any dependencies. It is the manager's responsibility to nip this in the bud immediately, especially if both PMs report into them. When the issue is cross-org, the political undercurrent may prevents managers from acting. Ultimately, strong leadership is enabled by a good company culture where there is no penalty for raising concerns when backed up by facts and evidence. A third frustration, comes from differences in PM experience and can be tricky to navigate. Most managers would love to delegate decisions to the lowest level possible. The benefits are many - PMs feel empowered, have a sense of ownership, the manager can focus on unblocking the teams as needed. In reality, if the solutions are coming back with incomplete thinking behind them, the PM manager now needs to step in and coach or outright re-direct. If this happens often enough there will be frustration for both the manager and the PM. The PM will feel like they have no say or that their manager is micromanaging, when the issue at the core is the current skillset relative to the expectation of the role. In my experience, managers who avoid dealing with this may over-delegate, and PMs who only focus on their feeling of frustration hold themselves back from learning and improving. Neither party will be able to progress when thinking cross-org, cross-functionally, cross-BU, and even internationally or globally is required with increasing levels of responsibility. 

I'd love to answer this in a slightly different way: The single most important skill, that cannot be rated highly enough is Communication. Many other soft skills are fundamentally still rooted in or are dependent on communication. Nuanced aspects of communication also matter: * adapting communication to the audience and situation * timing the communication * communication in all forms: written, verbal, non-verbal/body language.

Fairly easily potentially, compared to transitioning from other less-related fields. Product Management is as much art as it is discipline or science. Leveraging technical expertise related to the same or adjacent PM area helps. Some job descriptions will even require engineering experience or area of study. One major pitfall to avoid however, is remaining in "engineering mode" as a PM. As PMs, our focus should be on the WHAT, WHO, and the WHY, whereas Eng/Data Science's focus is more on the HOW. While some may disagree, for me all these still fall in the category of Hard skills for PMs. As an engineer transitioning to PM you would need to potentially learn more about setting product vision and strategy, go-to-market strategy, user requirements gathering, writing product requirements docs, and prioritization. You would also need to flex a lot more of you soft skills as a PM: communicating in writting and verbally, synthesizing info, influencing, managing stakehorders, driving collaboration and execution, prioritizing, negotiating, inspiring, etc. This can seem overwhelming. So "How do you eat an elephant? One bite at a time." Ideally, you have the technical experience in the same business domain, and can read up plenty on the discipline of Product Management. You've likely even experienced all this on the receiving end as an engineer. The rest is the art and the soft skills which will come with self-awareness, observation of your own and other's interactions, practice, and even formal training. While you may not be crafting product strategy on day 1, getting as much exposure to frameworks for strategy, and even just listening to others make strategic decisions and trade offs will help you start applying similar frameworks yourself.

1:10 is what has been used as a rule of thumb in my experience. A PM wears many hats. If you don't have a program manager (pgm/tpm) 30% - 40% of the PM's time may be going into project management activities and you may need an extra PM (or your first TPM) You may be supplementing other functions in the org: marketing, sales, solution consulting, BD. The point here is to assess what are the org needs and what role PM is playing or ought to be playing. It might not be a matter of how many PMs to Eng ratio. How would an extra PM accelerate the busines? If you were the CEO how would you best invest in the next available headcount - an engineer? a data scientist? Any other vs PM? Also worth thinking who else in your org is acting like a PM already - founders?

In general, the progression from any level to the next is a matter of demonstrating increasing levels of skill in product definition, technical or domain expertise, ability to navigate and project manage increasing levels of complexity, communication, and ability to influence amonst others. Another way to think about this is that you are increasingly moving from "learning the ropes" to "knowing the ropes" to eventually "having invented the ropes". Much depends also on how formally the company defines the boundaries between roles, how flat the org is or conversely, how much title inflation there is. Most large companies have formal definitions of what the expectations are for each level because that ensures a common set of criteria for promotion. The criteria may not be well- publicized but they are not meant to be secret, so you should ask for them either way. In a traditional PM hierarchy the PM and the Sr PM levels are typically early career levels. A PM typically receives a lot more prescriptive direction on tasks, they may cover one or more projects, and the scope is narrower. For example, running one experiment at a time, defining one feature as a subset of a much bigger system. While decisions are often made by more senior PMs and engineering partners, the PM is documenting the requirements, filing the tickets, and helping project manage. A Sr PM has shown good judgement and is both able and trusted to operate more autonomously. This holds true for a progression to Principle, Director etc. The Sr PM is still focused on a specific area but takes on more complex functionality, is more actively defining the features and driving the full product lifecycle. They know the processes and support systems, they are able to navigate the org and increasingly more complex converations. They are increasingly self-aware and aware of context. They know when to ask for help or to check-in that they are on the right track. Both roles are focused on execution. In some orgs there are additional gradations within a level: Sr PM I, Sr PM II etc. Unless defined somewhere, a good proxy for any level progression is as mentioned above: growth in scope, increasing ability to influence and drive projects of increasing complexity, ability to communicate effectively, which means both the ability to drive alignment but also to diffuse conflict.