Generally, I am thinking of success in 3 dimensions: Vision, People and Execution. All three need to work well for a team to succeed over time. Early in your career Execution takes a bit of a higher focus. You can get your first 2-3 promotions by launching bigger and more complex projects. However, as you grow in your career the ability to offer broader, more ambitious vision and have others join you in the journey become more central for your success. Your already proven execution skills help in attracting people to work with you since they know you will deliver. It’s important to invest in all three dimensions throughout your career, since honing these skills takes time. When I joined Meta I was excited to find out that here we are formally aligning PMs expectations with similar axes: Impact (which includes Strategy and Execution) and Capacity Building (which includes healthy team and cross functional relationship as well as broader contributions to the organization). I believe this structured view creates the right incentive and culture.

"Assume I don't know anything. Teach me something in the next two minutes about a topic you are passionate about - can be anything". This questions helps me understand how a person thinks on their feet, does storytelling, and uncover more about their passions as a human, that may have some interesting overlap with product work. I have learned how to swing a gold club, calm down crying toddlers, and pick soil for any plant from asking this question.

In taking an end-to-end business leadership approach to this role, it opens up multiple career paths. For example- if your goal is to become a product GM, this is well aligned. If your ambition is to be a future COO, I think this is a great role to dig into. I think it's also a great extension to leadership roles in customer success and GTM as well. I definitely see it as a choose your own adventure skillset.

It could be a combination of any of these things - * Look at data (dashboards, customer feedback channels, internal partner team feedback) to check progress (on product success, platform performance) -Take any actions necessary (filing bugs, resolving a SEV) * Supporting your cross functional team to deliver on roadmap projects -Brainstorm product and technical solutions. -Sprints, design reviews, code reviews -Removing blockers * Look at data to proactively surface opportunities, hot spots, technical bottlenecks etc * 360 communications often tailored meticulously for the target audience * A lot of meetings (Product reviews, Roadmap planning, Decision making etc) * Ideating and planning for the future (Strategy) * Upkeep or morale and motivation for team. TPMs often act as the glue for the entire team. * And ideally they are having loads of fun doing all these

As you progress from PM to senior PM, competencies in these 3 areas should grow: Autonomy💪🏽, Scope 🌫️ and Leadership 🙋 . There are a few clear indications that someone is ready for the senior level, like increased scope, being a reliable partner and being results driven. Here are some less obvious ones: #1 You recommend initiatives based on your strategic evaluation, instead of waiting for them to be handed to you. You are influential in your field and feel confident putting forward these initiatives. #2 You leverage relationships across the org. You can drive results from partners outside of your immediate team. You are fully entrusted to tackle complex, multi-team problems with little necessary supervision. #3 You are seen as an available and trustworthy mentor and actively seek out opportunities to help others be their best. This is my favorite by far. What are the key stages that distinguish the different levels of PMs? I think a little bit of this depends on the problem space and company. In my mind, PMs are professional collaborators, strategic assassins and bring out the best in their peers. If you can look yourself in the mirror and say you’re doing these things at scale, well, I’d say you're on the right track.

Objectives and Key Results are meant to encourage cross-functional alignment and collaboration. In product management, it is essential to think of OKRs as a method for prioritizing scope that will help drive the top business KPIs, so that your product roadmap has a built-in mechanism for considering how to help the business succeed. The below example is one I have seen work well: * Top Level Business Objective: Increase enterprise ARR by 20% * Product Key Result: Deliver paid feature X to help compete and close 3 sales pipeline deals * Product Key Result: Implement use case documentation for paid features to support Field Team

I’ll skip the obvious things - pay well, set a vision, growing company, skill building, career pathing - and highlight some under-rated ones: * Hire well and have high talent density. Most people who choose a career in Product Management are motivated by self improvement - being around other talented PMs who they admire and who push their thinking is motivating. * Stay lean. This may seem counterintuitive - isn’t it good to have enough PMs? Honestly, no. If you hire well you want to give people room to grow and stretch. The worst thing you can do is to staff up too quickly, only to have frustrate your stars who are ready for more in a year (or worse yet, sudden shift in the business which requires you to scale back projects). Having too many PMs will also lead to more work being generated, you then need to resource. It’s far better to have PMs that have 20% too much to do than 20% too little. My rule of thumb is: everyone should be just uncomfortable enough with their scope that they drop a few things, but not so uncomfortable that they burn out. * Autonomy. People choose a career in product management because they want to make or be at the center of product decisions. Allowing them to do so is one of the most important things you can do to keep them motivated. As a people leader your jobs is to set goals, give context, guide, and identify blindspots. It’s not to operate the product for the PMs on your team. At Netflix we have a value, “Context over control” - leaders should focus first & foremost on setting context so others can make decisions vs. making decisions for them. * Actually care about them. When I think about the best managers I’ve had they have one intangible thing in common - I felt on a deep level that they actually, genuinely cared about me. This had a ripple effect on every part of my job because I felt supported, was calmer, and did better work. Caring looks like regularly thinking about the growth & success of another person without being asked to. It looks like advocating for or elevating behind the scenes, especially if they are in a disadvantaged position. It’s something that you can’t fake.

Let’s say that a product team and an executive team are aligned on the goal of improving customer satisfaction with the product (measured by a CSAT survey). The product team will then do research and perform experiments to validate the best way to impact customer satisfaction. Including executives in the research process via stakeholder interviews is a great way to get input early - executives are viewing things from a much different perspective than team ICs and often have great ideas. When the team prioritizes opportunities to pursue, the framework they use for prioritization can also be used to convey their point of view on the best way to impact customer satisfaction. If an exec suggests making an adjustment to the roadmap during the team’s roadmap review, seek to understand why and dig into their thought process. Then, seek the truth. Is there a quick way to validate or invalidate the feedback? What does the objective evidence point towards as the best opportunity to impact the goals? For more on this topic, I recommend “Cracking the PM Career” by Jackie Bavaro which has a chapter on working with executives.

Becoming more KPI driven is a matter of desire and taste. No person, team, or organization attempts to change without believing that behaving differently will result in an improved outcome they care about. It's only possible when leaders buy into how it would improve the success of their teams and business (e.g. profitability, valuation growth, employee engagement, talent retention, positive social impact, etc.) Some companies are steadfast that the use of KPIs should not equate to being data driven everywhere in the company. They prefer to have data informed teams that reserve room for intuition and qualitative insights. There is no right answer here. If we find ourselves with a company that's bought into a shift towards being KPI driven, but is trying to figure out how at the team, group, or division levels, then I'd recommend the following: 1. Have the leaders of the team/group/division define their strategy for a period of time through written outcomes, assumptions, and principles that are most critical to their success. 2. Gather all the data already available and audit it for quality and trustworthiness, then see if you can model your product or business (i.e. in a spreadsheet) to see if the assumptions you've made and outcomes you've articulated can be explained by your data. If not, note what's missing and how you could gather it (and be comprehensive at this stage). 3. Work with your engineering and/or data team to instrument the metrics you need, backfilling where possible. Remember that you'll need continuous energy to ensure your data remains audited and accurate, as data corruption can severely disrupt your KPI-driven organization. 4. Develop a process for regularly collecting, analyzing, and reporting on the chosen KPIs. Without this ritual, your efforts will be for not. Being KPI-driven means knowing and using the data to make decisions. In my experience, to get the flywheel spinning, you need to have weekly rituals that can morph to monthly rituals. These can be augmented with quarterly business reviews. 5. Make sure that the chosen KPIs are easily accessible and understandable to all members of the teams. This may involve creating dashboards or other visualizations to help team members quickly see how the product or organization is performing. Repeat your KPIs at kick-offs, all-hands, town halls, business reviews, and anywhere else you gather. It's only when you think you're over communicating them that you've probably approached a baseline level of understanding of the KPIs, and how they inform decision making, across your company. 6. Provide regular training and support to team members to help them understand the importance of the chosen KPIs and how to use them effectively to improve the org. If you have a wiki, put your tutorials there. Make it mandatory to consume these during onboarding. Offer self-serve tooling. The more people can be involved with the data, the more you'll make this cultural shift. 7. Regularly review and adjust the chosen KPIs to ensure that they are still relevant and useful. Account for any changes in your outcomes, assumptions, and principles. Assess suitability annually. Set targets annually and adjust mid-year. Some companies do this more often, and your culture should dictate what's best. 8. Lastly, make sure that all KPIs have their lower level metrics clearly mapped for the company to see. Teams influence these input metrics more quickly, and the mapping brings clarity to decision making.

I transitioned from journalism to product management earlier in my career, and although it’s not a straightforward path, it’s actually pretty common for PMs to join tech from other sectors. An Asana PM teammate of mine, Ari Janover, actually has the best articulation of how to make the transition that I’ve ever heard. He says there are three common paths: * The Ninja: Join a small startup as another role and push to own PM work until you become a PM. * The Expert: Apply for roles where the value of your specific knowledge trumps your lack of PM credentials. Think Engineers for technical products or a real estate agent for a real estate tool. * The Hail Mary: Follow the few PM Apprenticeships that don’t require previous experience (learn more about AsanaUp here). I followed the Expert path when starting out, and I’ve seen it work quite well in early-stage companies. One of the biggest challenges in starting in an early-stage company, though, is that you’re often the first or only PM, so although you have lots of things to learn, you may have fewer people to learn from. I spent a lot of time observing and learning from PMs at other companies and building up a group of folks I could exchange ideas and challenges with, and this is a practice I still find incredibly useful today.