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.

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

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.

There are some absolutes, which may be self-evident, but I'll still mention them for the record: disrespect, discrimination, excessive stress, unreasonable and unhealthy workload, workplace toxicity in all it's forms, the company is unethical or is visibly tanking...and many more. 

Otherwise, I suspect the most common reason to leave might be simply put as: a better opportunity elsewhere. Now, this is a very personal calculus that becomes harder if things are not exactly terrible. Perhaps you are holding out for the promotion and it is taking longer. Perhaps the economy is too "risky" at the time. Perhaps you feel like you have something more to learn in the current role that you want to then leverage in the next job search. On some level, any reason is a fine reason to stay, as long as you know that you are consiously making the choice and it is a choice that in your best estimate takes you to where you want to be in the long-run. Most importantly, you don't want someone else to be making that choice for you. It is easier to get a job while in a job vs. when out of a job. And how do you ever know what is a better opportunity elsewhere? So network, look passively, field exploratory calls. From that perspective, it is never a bad time to be passively looking and neither is it necessarily time to leave. 

In my own career, I've had situations where I started looking into a new role within a few months, due to some of my "absolutes" above being violated. In practice, I stayed on for many years, despite getting viable offers roughly every 6 months, i.e. it wasn't innertia, but a consious choice taking into account an ever-evolving org, company, and economic backdrop. 

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.

Even when feedback seems completely unfair, there may be some small nugget to pay attention to. So, in general don't dismiss the feedback without some introspection. Giving objective feedback is actually hard to do; most people can't distinguish between whether it is their own pet peeves that are driving them to provide feedback or if they are reflecting some broader consensus on true weaknesses that need correction. Who should seek to change: the person who got annoyed or the person who is generating the annoyance?

A lot here depends on your manager's maturity, true intentions behind the feedback, their desire to level with you, and ultimately ability to hear feedback about themselves.

If you are sure you are not dealing with a narcissist, try to have a dialog to get clarity on the actual triggers, what does success look like to them instead? Ask them what they see is the impact to the business or the team of you not act on the feedback. Ask other observers if they would have the same feedback. Lastly, consider that even if the feedback is subjective, making some change to meet your manager halfway is a way to build the partnership.

Sustainable Competitive Advantage.

1. Product attributes are insufficient and can be replicated by competitors with enough investment and determination

2. Pricing models and all their nuances can be undercut. Customers' willingness to pay may be negated by the next recession or evaporate when a new shinier, cooler competitor product arrives

3. Human capital, though harder to build up and retain, can still be hired away from you. Everybody has a price.

So, what makes for sustainable competitive advantage? Leveraging economics of scale but more so economies of scope, driving flywheel type effects (positive network externalities), preferred access to resources or markets, etc

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.