AMA: Walmart Sr Director II, Product Management - Marketing Technology, Milena Krasteva on Developing Your Product Management Career

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. 

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. 

There is no substitute for being hands-on, although there is now also plenty of literature on PM-ing. Become more technical by learning from your engineering and data science partners. Don't worry too much about annoying people. Most will be kind enough to explain and it will make their job easier when you increasingly not only "speak their language but incorporate the knowledge on the job. Observation of how other successful PMs and even other stakeholders operate is also very useful, especially when it comes to soft skills. You may even come across PMs who ostensibly lack domain expertise or technical skill, but are fabulous at communication and synthesis. Be curious about how they do it even if you don't have an affinity for the person themselves - you will start to distill your own playbook.

Actually, no differently than managing the 1001 questions and tasks shot at you in a large company :) A PM wears many hats. If any one area takes over disproportionately, the risk is that you are no longer doing the job of a PM. Some common blurring of the boundaries is when PM is acting to fill gaps that are normally entirely different functions: - Project manager - QA - Technical Support - Technical Writer - Trainer - Solution Consultant - Marketer - Data Analyst, etc. Write down the CORE PM responsibilities, that should NOT be owned by another function. This is how in theory your PM role is meant to drive value. Write down how much time you are currently spending on each and what your total is on core PM activities. Next, list all the other things you do that should be owned by someone else. How much time do you spend there beyond a reasonable amount that PMs would normally have to dedicate there? The difference between time spent elsewhere vs core PM dilutes your role and masks gaps of equivalent or greater magnitude in other departments. Estimate, if resources were not a limitation, how many additional people would need to be in these stakeholder areas such that end-to-end things run smoothly without you filling the gaps. Articulate what would get done, if you were not filling this gap, but were instead focusing on product management. This is your recommendation and ask of your management chain to rebalance things such that you can do the best possible PM job. You may hear that resources are in fact a very big limitation and the status quo remains, but at least you now have a clear indication of the company's priorities - e.g. all hands on deck for new sales over new product development, bug fixes, or launches. That is OK, but then the decision is for you, if you want that for yourself. Chances are, however, that it will give leadership some pause and potentially drive some change. I've been through 3 companies (startups and large companies alike) who all swore up and down that they were philosophically opposed to having a project management function. That is until we repeatedly showed how 30%-40% of PM time was spent on project management and no product acceleration could be had unless we either added more PMs operating at partial capacity (expensive) vs getting 1 technical project manager (less expensive). I even had a startup founder snipe about how PM was tied up with eng in expensive meetings without asking what the meetings were about - they were about tickets, bugs, backlog grooming, and status reporting. We got new ticket/bug management tools and a TPM shortly thereafter :)

1. Communication 2. Execution 3. Domain expertise I'd add stakeholder management as an important one but I can only do the top 3 :)

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.

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. 

There is "not helping", or even not knowing that help is needed, and then there is actively blocking. I'm going to assume it is not the latter - actively blocking. There are remedies for that too, though much depends on the situation, the players, your determination, and some luck. Otherwise, step 1 would be to have a conversation with your manager dedicated to how you would like to get help. I good starting point is documenting an IDP (individual development plan). Think through what and how you aspire to be, then self-assess what is needed to get there and what stands in your way - experience, training, project exposure, technical knowledge? Or soft skills? Or something else? Pencil in how and who can help remove the obstacles and open doors. Step 2 is to go through the IDP with your manager. Check if they agree that the steps you outline lead to where you have articulated you want to be and how much they can help. Be prepared for the conversation to go in less comfortable territory around execution, soft skills, reputation, communication, and influence. Step 3 The IDP becomes a collaborative roadmap for you and your manager on how to get you from A to B in terms of growth with action items. Don't forget to add and agree clear metrics on how any item in the IDP will be deemed done.

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.