My current product team has about 40 PMs (And we are hiring!). I would not dive into what each of the team does, but maybe talk about how we went about structuring it, which may be a more transferable skill. When I first joined Meta my VP asked me if the current team structure is the right one. Naturally, I did not know the answer. Frankly, I don’t think it was the right question for me to answer at the time. Instead, I engaged with the team on setting a 3 year plan - Write down what our strategy is, at a high level, and what are the key milestones that such a strategy would hit, if successful. This happened both at the org level and for the individual teams in the org. As the team presented the strategy to the stakeholders we started seeing some gaps in our org structure and the team leads started to raise a desire to organize differently. We recently re-organized the team accordingly. Setting a direction was a critical prerequisite before talking about team alignment. As for measuring success, it goes a bit to the first question I answered - I expect each team to define their own strategy, then set the milestones of that strategy. Our discussion can then be focused on the three elements I highlighted: * Strategy: Was the team able to set a good strategy? * Execution: Is the team hitting the milestone? If not, is it because the execution is not tight, or because the milestones are not achievable and we should pivot? This is a very important distinctions that some people are missing - A team can be executing really well and proving that the strategy is the wrong strategy. Being able to prove that point and move on without wasting years of struggles is a big win! * Org health: Are we hiring well? Growing talent? Retaining talent? How is the cross functional relationships going?

Design a product for drivers driving in rush hour. I am betting every human stuck in traffic has once thought... “Dang this traffic sucks, I wish I could [insert idea].” The best answer I’ve heard is a tablet-sized visual, that is connected to the internet with key apps such as email, song playlist, podcasts, call functionality; along with the capability for partial self-driving in traffic. Once in rush-hour it kicks in, frees your attention to do other things, improves health of the driver by reducing both physical and psychological strain of commuting in rush hours and is highly scalable to autonomous-capable vehicles. I liked the answer because I’d buy this product 🤪 but also because the answer was (1) optimized for reducing real pain points (2) accounted for the future of driving (3) was a little wild, but not too out there. When I heard this answer I could tell the PM was both imaginative but grounded in solving real problems.

A technical product manager at Amazon is generally referred to as a Product-Manager-Technical (PM-T). A PMT can have ownership over a product, a functional area or even a program, but their primary focus is on formulating the vision, the strategy and roadmap for that area. They are also ultimately responsible for the end metrics of adoption, quality and effectiveness of the features they deliver. They are also the primary customer champions synthesizing their current pain-points, as well as anticipating future needs. They develop concept documents (PRFAQs), Business Requirements, and Product Definitions. These are not exclusive to PMTs since Amazonian culture drives the notion of ownership, customer obsession and invention into everyone, but these are responsibilities that are more core to PM/PMTs. A Product Manager (PM) shares all of these same qualities and responsibilities with a lower bar on technical expertise which may be more suited for specific roles involving less-technical products or less-technical functional areas within a larger portfolio. A Technical Program Manager (TPM) is a distinct role that sits at the intersection of product, engineering and program management. An Amazon TPM is a unique role that combines business ownership over delivery with high-level technical architecture. They are usually the program glue - that brings together PMTs, engineering teams and business stakeholders on all aspects of an initiative. To address a common misperception, TPMs are not project managers, but have far more involvement in business outcome, product decisions and typically posess engineering and architcture skills that allow them to coordinate efforts across product areas. However, note that this AMA is focused on the technical product-manager role or PM-T. So please make that translation whenever you see "TPM" in these questions.

Customer feedback is critical to how we build, and we incorporate it at every step of the product development process. We get customer feedback from a variety of places. When building new products we proactively reach out to customers to learn about their needs and make sure we’re creating the right solutions for them. We have a User Research team that regularly speaks to customers via a variety of methods - everything from interviews and surveys to card sorting and field studies. Along our product development process, we have specific touchpoints where we make sure to utilize user research to get deep insight into the pain points our customers face, and the best solutions to help them. Our customer-facing teams, like sales and customer success, are also talking to customers constantly as part of their daily jobs. These teams rigorously record all of the feedback they hear and compile it into a ranked Voice of the Customer (VOC) list, all managed within Asana. Asana’s VOC program is a critical input into our roadmap process, and helps us prioritize the most pressing needs brought up by customers.

I think the best way to break into the industry as a PM is to get after building tech products yourself. Personally, I left a well-paying job in the energy sector to work on a start-up with no reliable paycheck. Thinking back on that experience, it was crazy beneficial to learn how to work with designers & engineers to build a great product or feature. The act of building a product or feature is the best teacher. I’m not advocating that you should quit your job and not get paid to build stuff like I did! There was a lot that wasn’t so awesome about that. 😅 But I definitely WOULD encourage everyone here to think about how you could do that in your spare time. What problems are you passionate about solving? What kind of product or feature could help you solve that problem? How could you bring that solution to life? How can you talk to prospective customers about it? Even PM candidates that make wireframes or prototypes to show a product that solves a real problem have a leg up over most of the other candidates. I’ll take someone with drive, initiative and passion for the work 10 times out of 10.

Collaborating with Product Marketing is a key part of any product's success. In smaller teams/companies, that role can fall on to the Product Manager directly, whereas at bigger organizations that is a more dedicated role. I am fortunate now at Cisco to have access to some of the best product marketing resources in the business. The work that we do together from product strategy, execution planning, and external marketing helps ensure our business objectives are met and made visible within our specific market. We work closely throughout the GTM process and fostering this relationship is one of the key components to a solid product launch.

FIRST OFF, TAKE A DEEP BREATH AND REMEMBER, CRUSHING THOSE OKRS IS GOING TO TAKE TIME AND EFFORT. NEXT, SET CLEAR GOALS FOR EACH MILESTONE AND BUILD A PLAN AROUND IT. JUST LIKE YOU WOULD WHEN DEFINING A PROJECT, IDENTIFY SUCCESS METRICS FOR YOURSELF AND CREATE A PLAN. HERE’S AN EXAMPLE: First 30 days: Learning and Absorbing * Establish good working relationships with stakeholders: the key to being effective is having open lines of communication with your coworkers. Take the time to get to know them and learn from their experience. * Immerse yourself in data: learn where to find pertinent information, which dashboard to follow and how to query data on your own (or work with a data scientist). * Familiarize yourself with your product’s users, their needs, pain points and Jobs to be Done (JTBD). * Spend time doing competitive analysis to better understand the product landscape. * Integrate into the team’s current work and process and identify ways in which you could be helpful. 30-60: Ownership and Leadership * Assume responsibility for a project: work with your team to define the project’s scope and add requirements. * Define success metrics for the project and work with your engineers and data scientists to ensure impact can be measured and tracked. * Identify cross-functional dependencies and reach out to relevant teams. * Give a demo and solicit early feedback. Continue to do so throughout the project. * Report on the project’s progress and impact to keep everyone involved and interested. Speak clearly about the business impact and how the project ladders up to the company’s goals. 60-90: Strategy and Vision * Leverage your understanding of the business and its users to craft a vision and strategy. * Translate the above into an actionable roadmap and work with your team to define success metrics for each. * Run brainstorming sessions with your team regularly to generate ideas and prioritize them. * Evangelize: this is where your storytelling skills will come into play—make your team’s mission known, its projects familiar and its rationale clear to everyone. Write posts, speak at company meetings and bring feedback back to your team. * Become an expert: be the go-to person for your focus area.

At the company level, there are a few different methods of communications to keep everyone abreast of updates: 1. Product Notification emails (Ad Hoc) - These emails have a set template and allow product teams from around the company to share updates to their areas in a digestable format as major features go out of the door. 2. Product Newsletter emails (Weekly) - The weekly newsletter summarized major product updates and initiatives to all product team members. 3. Quartery Business Review meetings (Quarterly) - These larger meetings gather key parts of the business to talk through major updates each quarter, including an opportunity for the C-Suite to interact with and pose questions to respective teams. 4. Quarterly Kick-off meetings (Quarterly) - These meetings are specific to our Product Area and include our stakeholders; each team in Fintech is able to share wins from the prior quarter and plans for the coming quarter. 5. Slack Updates (Ad Hoc) - For major releases, the PM will often post a message in our global product channels to notify the broader group of the change. This allows an opportunity for the team to be recognized, as well as others to be informed about the update. 

While there are different specific metrics that marketing and product teams track for product launches, what's critical is the alignment between the two and agreement on the metrics to track prior to the launch. Some examples of metrics tracked by each team: * Product team: Satisfaction, usage by users and individual accounts, full funnel from a user trying the feature to actually using it * Marketing team: % of reps enabled on the new product, leads generated, competitive win rate changes * Metrics that require deep partnership: Number of customer stories/references for the capability

This is certainly a tricky one! I like to think of a roadmap being made up of four sensing mechanisms: 1. External stakeholders - investors, board members 2. Market landscape - competitors, analyst reviews or reports, and prospects 3. Internal stakeholders - CEO, leadership, cross-functional teams 4. Customers - install base or existing paying and free users When you are able to attribute the sources of your roadmap features transparently, it becomes a trade-off conversation with executives - rather than a top-down mandate. Being able to show that certain bodies of work have been sourced from competitors or analyst reports which show that you may be lagging behind, for example, is a great dialogue to have when it comes to prioritizing the input from the executives. If the feature request should get done because you have applied a RICE score or some other type of validation, sequencing behind the most impactful items will be a great way to accommodate the request while delivering the most impact.