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.

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. :)

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.

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.

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. 

A CEO once told me that he would only hire a person if he thought that he would enjoy the time spent with that person despite being stuck at an airport with them waiting to board an indefinitely delayed flight. Despite the exaggeration, I've always imagined the equivalent scenario as whether engineers would want to spend hours with a PM in a war room or a bug bash. Be an engaged partner. Be in the trenches with them. Work hard or harder. Follow-up and follow-through on your stuff. Be transparent about the real business context, the one they may not have heard. Tell them about what you are up against. Bounce ideas off of them, ask about options, be curious. Be their ally, advocate, or sounding board when needed but not blindly. Don't just toss a problem over the wall. Write a technical PRD vs a one-pager. If they are "not delivering" don't just report it as late in a status meeting. Meet proactively- ask what can you do to help them do their part. There could be a zillion other reasons- they are working on something else that's more important, or even less important but they didn't know otherwise, they don't know how to "fix it" yet, or they are dealing with personal issues, etc. Admit your mistakes and help them recover from any of theirs. This does not mean sweeping real issues under the rug. Address things that cause real damage head on privately or less privately as needed. By now you may have noticed that none of my answer contains anything about having more technical knowledge. It is also true that getting increasingly more technical will always help. But it won't impress or influence. Being real and human is more impressive these days; it will build trust, and trust paves the path to true influence, one that cannot be confused with coming from title or power.

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. 

1. Communication! Verbal, Written, and often forgotten but equally important: Non-verbal. Yes, even on Zoom. 2. Ability to read context and act accordingly 3. Strategic thinking. Know the difference between strategy and tactics. 4. Systems thinking vs Design thinking, be proficient in both, know when to apply each 5. Treat everyone as your customer. Sometimes it means the "right to refuse service". Make that exceedingly rare.

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.