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.

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.

Part of the fun of building something 0-1 is that you have a green field in front of you — you can build anything! (Or that's what we wish as PMS....) As much fun as it would be to the world is your product oyster, constraints help provide focus and a direction. I see the first step is making sure that you and stakeholders are aligned on what a goal or success looks like. And usually, that comes in the form of a metric that you're trying to move. If you work for an ecommerce company, you'll make very different decisions around what to build if your metric is increasing ASP versus unlocking a new vertical or segment. If your metric was the former, you might start doing user research on customer willingness to pay, or what they're thinking about when they're in the check-out flow. And if it's the latter, you'd probably start with user research into people who aren't yet your customers. Without that first constraint — what metric do we want to move, what does success look like — there's no way to focus your research and problem defintion phase. Once you have that north star to work toward, you can enter user research with your specific goal in mind. 

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.

There's a lot written about basic PM competencies (https://a16z.com/2012/06/15/good-product-managerbad-product-manager/), and for any PM on my team, they should be able to do all these things you'd expect from a PM (write specs, understand the customer, communicate upwards and outwards, GSD). I'll focus my answer on a few attributes that I think are really "make-or-break" for me: * Good communication skills, both written and verbal, are an absolute must-have for any PM on my team. Whether it's through writing specs, influencing stakeholders, or pitching product ideas, PMs have to be able to communicate effectively across mediums (written, verbal), forums (large groups vs. small groups vs 1:1) and audiences (to developers, marketers, sales, executives). In particular, they need to be able to tell good stories (e.g.,, can they get their team inspired about an idea?), structure their communication effectively (e.g., can break down ambiguous problems using a framework?) and make technical concepts easy to understand for non-technical folks (e.g., can they explain how routers work to someone without a CS background?) * Great PMs "own" the problem. They're not afraid the step outside the boundaries of their function to do what it takes to get the product out the door. They rarely ever use phrases like "that's not my job" or "this was the designer/developers responsibility". Their strong sense of ownership of the problem leads them to passionately debate about the right solution, speak truth to power when necessary, but also be open to other points of view (because it's not about "them", it's about solving the problem).

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.

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.

In my previous answer, re: finding the right opportunities + making decisions - I mentioned four lenses (Customer, Business, Market, and Technology) as key components of coming up with ideas and making decisions. The best advice I have to offer is to be intentional about spending time developing your muscles in those areas. It can be as simple as picking a product or service in your day-to-day life and thinking through what inputs might have contributed to the experience you’re having as a user. Additionally, a lot of product strategy is about being able to identify the opportunity that will maximize impact. How will you hone in on the right problem and arrive at an excellent solution? I’ve found that strong problem-solving intrinsics and the ability to make effective decisions are very valuable. Here are two frameworks I’ve always found helpful: * McKinsey’s Seven Steps of Problem Solving - Helps abstract underlying problems/issues * Playing to Win - Strategy book by the former Procter & Gamble CEO A.G. Lafley Lastly, communication is essential for being able to get buy-in and execute product strategy. Work on simple, effective communication.

Let's cover this in two ways: (1) how to think about KPIs, (2) examples of poor ones and how they can be better. I'll also approach the question a little more broadly than Product Managers alone. Remember that Key Performance Indicators (KPIs) are used at all levels of a company (e.g. project, team, group, division, exec team) with different levels of fidelity and lag (e.g. daily active user vs. quarterly revenue). The appropriateness of standard KPIs will also differ by industry (e.g. commerce software will not rely on daily active users the way social networks do). Finally, many people use the term KPI when they actually just mean metrics (whether input, output, health, or otherwise). As the name suggests, only the metrics that are key to success should be elevated to KPIs, and there should be as few of them as possible. When I see more than 1 from a team, 3 from a group, or 5 from a division/exec team, there are good odds that some can be cut, amalgamated, or otherwise improved. KPIs are, after all, meant to drive decision making and accountability. So what are the criteria of KPIs that stand to be improved, and examples of them? 1. Vanity metrics: these look impressive but doesn't actually measure the success of a product. Examples include the amount of traffic to a website, the number of sign-ups a product has, daily active users for marketplaces that monetize through purchases, or the number of likes across posts on a social network. 2. Poorly instrumented metrics: these are not reliably measured, which can lead to incorrect or misleading conclusions about the effectiveness of a product. For example, if the first step of a conversion funnel (e.g. checkout) has many ingress pathways, and the user can transition in and out of that step before proceeding down funnel, how well your instrumentation deduplicates that first step is critical to your conversion calculations. 3. Lack of attribution to effort: any metric who's fluctuations cannot be explained by the combination of efforts from the team/group using it as a KPI, plus seasonal and random variability, is going to be ineffective. For example, if a common funnel in the company has multiple teams trying to improve its conversion, each team needs to define a KPI that does not overlap the others or they won't know if their efforts resulted in an outcome versus another team's efforts. Note that if all those teams are in the same group (e.g. a growth org), then that group could effectively use the conversion rate as their KPI. When in doubt, or if you're unable to isolate your efforts with lower level metrics, run an A/B test against every major change by each team to get a better (but imperfect) indication of relative contribution. This criteria covers many grey areas as well. Revenue is a prototypically difficult KPI for individual teams to use because of attribution. However, you can find relatively small teams or groups that build add-on products that are directly monetized and expansion revenue can be an excellent KPI for them (e.g. a payroll add-on to an accounting system). 4. Unclear tie to next level's KPI: companies are concentric circles of strategy, with each division, group, and team needing to fit its plans and focus into that of the prior. This includes KPIs, where you'd expect a well modeled connection between lower level KPIs driving higher level ones. For example, say a SaaS invoicing platforms sets an X in Y goal as an activiation hurdle to predict long term retained users (i.e. 2 invoices sent in first 30 days). It would be reasonable to assume that onboarding will heavily influence this. But what about onboarding, specifically, will matter? If a team concots a metric around how many settings are altered in the first 7 days (e.g. chose a template, added a logo, set automatic payment reminders) and wants to use that as their KPI, they'd need to have analyzed and modeled whether that matters at all to new users sending their first 2 invoices. 5. Lagging metrics at low levels: the closer you get down to a team level, the more you want to see KPIs defined by metrics that are leading indicators of success and can be measured without long time delays. Bad KPIs are ones that just can't be measured fast enough for a team to learn and take action. For example, many teams will work to increase retention in a company. But larger customers in SaaS may be on annual contracts. If features are being built to influence retention, it's better to find leading activity and usage metrics at the team level to drive behaviour and measure them weekly or monthly. These can tie into a higher level retention KPI for a group or division, and keep teams from getting nasty delayed surprises if their efforts weren't destined to be fruitful. The only caveat for this criteria is how platform and infrastructure teams measure themselves. Their KPIs are typically more lagging and this topic is deserving of its own write-up. 6. Compound or aggregate metrics: these are made up of multiple individual metrics that are combined using a formula in order to provide a more comprehensive view of the success of a product without needing to analyze many individual numbers. Examples include effectiveness scores, likelihood indicators, and satisfaction measures. Arguably, many high level KPIs behave this way, such as revenue and active users, which is why (3) above is important to keep in mind. However, its formulas that are particularly worrisome. They inject bias through how they're defined, which is hard for stakeholders to remember over time. You find yourself looking at a score that's gone down 5% QoQ and asking a series of questions to understand why. Then you realize it would have been simpler to look at individual metrics to begin with. In my experience, these KPIs lead to more harm than good. 7. Lacking health metrics or tripwires: having a KPI is important, but having it in isolation is dangerous. It's rare for lower level metrics to be improved without the possibility of doing harm elsewhere. For example, in commerce, we can make UX changes that increase the likelihood of conversion but decrease average order value or propensity for repeat purchases. Therefore, a KPI that does not consider tripwires or does not get paired with health metrics is waving a caution flag.