Navin Ganeshan

First of all, we need to address Amazon's terminology for these roles. A technical product manager at Amazon is generally referred to as a Product-Manager-Technical (PM-T). Whereas 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. 

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.

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.

(Reposting this from a related question) 

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.

This is definitely a popular topic of discussion amongst PMs, and probably a heated one at times. This is a good post that covers the most common including RICE, KANO and story-maps. https://roadmunk.com/guides/product-prioritization-techniques-product-managers/

Personally, I'm less dogmatic about the specific methodology than the discipline in using some framework, even it's as basic as attaching value-to-effort. Most seasoned PMs will concede that they always have to make tweaks or compromises to a standard framework to suit their team or company. So, I would not suggest looking for the best one, but one that works best for your team. Attaching Value-to-Effort, or using story-points are always a great place to start. The Kano model or MosCow model are similar and allow for a more nuanced approach that lets you distinguish between must-haves and nice-to-haves, and help you calibrate how much to invest in back-end scaling which may not be as noticable.   

But always take into account what stage of evolution your product is in, and the extent of data that have to make prioritiation decisions. Your approach is necessarily diffrerent when launching a new product vs evolving one that is several generations old.  

A technical product manager has a more substantial role working with engineering teams on core architecture and component design related to a feature. If all product managers have allegiance to different dimensions - business/revenue, customer experience, product/tech strategy, marketing etc - the technical product manager indexes more heavily along the areas of technology design and integration. For most products, feature development usually happens on a longer cadence involving multiple iterations to build towards a fully formed capability. It is essential to have a core north-star blueprint in mind even as customer-facing iterative enhancements are rolled out. The technical product manager shares this vision with enginering managers and architects. While a technical PM may not own the design of the technology, they share this vision and the approach to achieve it.  

On a day to day basis, this translates to a technical PM working more closely on how multiple systems work together (integration) and in some cases, what APIs are utilized or need to be developed at a high level. The level of technical involvement may vary depending on company and product area - for example, a tech platform as product with engineers as customers may require the PM to be more in the weeds on API utilization or platform choices. In all cases, what differentiates a technical PM is the abilty to delve several layers into the technology utilized while still maintaining allegiance to other focus areas.  

To be blunt, I think they are critical. Data is the currency for any decision-making, and analytical competencies are exactly what empower product managers, technical or otherwise. For technical PMs, there is also an expectation of data self-sufficiency where they are not as dependent on BI or other engineers for extracting and analyzing data. While I wouldn't necessarily imply that SQL capabilities are absolutely critical, let's just say that analysis and visualization can be a substantial super-power. Whether it's being able to analyze feature-usage, page-flow dynamics, browser-metrics or build retention-matrices, using off-the-shelf dashboards can be limiting. Newly launched features may not always be accompanied by ready-to-reporting. In these cases, data competencies ca help a PM bridge that gap. Product managers who can access, analyze and visualize data also have a substantial speed and efficiency advantage over others.  

What skills are useful? Specifically basic data-modeling, simple SQL, analytical tools for performing historgrams, scatter-plots and simple visualization using tableau, PowerBI etc. Another benefit to this data self-sufficiency is that PMs can engage in higher quality story-telling around their product area. It frees them to express what's happening using a data-centric or visual language that can often make the difference between a good PM and an exceptional one.  

In a word, abstraction. A technical PM is usually NOT the most advanced technical person on a team. However, they are able to break through sufficient tech layers to be able to contextualize the tech in the overall product development. They are able to draw the bigger picture of how components fit together, what technology elements are critical. And how to think about investment in each technical area - sucvh as build/buy/partner. In this way, they're not competing with others on technical know-how, but using it as an essential area of overlap to allow easier communication and collaboration.   

A techical PM is simply able to engage in more meaningful planning, discussions and collaboration on technology areas with other counterparts. 

The process of starting with a vision for any product/feature is conceptually simple, but also eludes many product managers who may be more accustomed to being able to chart a path to "somewhere" rather than have to contemplate where that somewhere is. It helps to demysify and de-romanticize the notion of a vision and talk about exactly what mechanisms you can use to describe it.  

Amazon's famous approach involves using a PRFAQ as one mechanism to describe that vision. The process of developing that, especially the first page PR, forces really helpful thinking about the vision. It helps clarify thinking about what problem we're looking to solve, why that's important to the customer, and why that matters to our business. It also allows us to describe the overall goal, or end-state vision with clarity and purpose, without all the inevitable caveats, phases and ifs/buts that will ultimately follow (in the FAQ section). And most important, it defines who the customers and beneficieries are, and expresses the value proposition through their lens. We use illustrative testimonials from customers to express that in as direct a way as possible. A common challenge is where we have to balance a customer benefit (e.g. makes their work easier) with company benefit (e.g. improves efficiency or more sales) and this allows us to refine this vision taking both into account.  

We also utilize 3-Yr strategy docs as another mechanism that allows us to express a vision when it spans multiple product or functional areas. Not being constrained by near-term challenges allows us to compartmentalize and solve for each area separately and over time. And also be open to evolving that vision over time.  

The use of tenets helps us apply rules to ensure our efforts stay true to that vision. Our tenets go beyond stating the obvious (good UX, speed, reliability etc) and speak directly to what's important and what choices we have made (e.g. we will prioritize fast access to critical info rather than exhaustive access to all, we will prioritize safety over efficiency etc ).  

This is a universal challenge for all product owners - how to ensure your roadmaps don't get derailed. I take the perspective that you should expect and accept a certain combination of planned vs opportunistic initiatives. Being overly dogmatic in your roadmap against evolving circumstances is just as bad as not having a strategic roadmap.  

Amazon is known for moving quickly, but that doesn't necessarily mean that we don't have structured long-term roadmaps. However our culture and mechnisms ensure both a rigor for annual planning while accommodating, and even respecting, the need to change priorities quickly if needed. Our annual OP1 process, usually mid-year for the following year, ensures that we map out our north-star and strategic investments for the year tied to clear business goals. These "big-rock" initiatives may lack the detail of the "how" but they are explicit in the business outcomes we expect and how we measure them. A later OP2 process at the end of the year, does two things - it accommodates smaller tweaks to the original strategy if needs have evolved and also adds more substance to the "how" that will ultimately result in a roadmap. This one-two punch ensures that we maintain the rigor of strategic planning while allowing us to react as market, customer-base and other macro conditions change. Considering our peak-period is Thanksgiving-Christmas, this also allows us to absorb and react to new learnings without being beholden to an older roadmap. Furthermore, we have an ongoing process for conceptual thinking using PRFAQs - essential a concept proposal - that are continuously evaluated that still give us the opportunity for identifying a new opportunity, or addressing a dire need and making prioritization decisions as needed.  

In practice, this usually translates to a 2-3 initiatives that usually surface during the year that may not be in the original roadmap. This isn't a defect, it's a necessary balance between the rigor of planning and acting on opportunity. It's a popular adage in finance that you make most of your money on three critical days of the year. It's much the same with product development - feature value is often assymetrical to effort and planning and recongizing this balance is critical for product success.  

To be clear, I don't believe a technical-PM is always a better PM. It comes down to what attributes, passion and curiosity you posess and the direction you want to go. A good technical PM is strongly curious about technology and how it's used to solve the problem. They think of the problem, as well as the soluton, in terms of technology. They are better able to understand abstractions of technology - tech stack, componentization, APIs - etc in the context of product development. Other non-technical PMs may similarly be more focused and passionate about product economics, pricing and positioning and how it manifests to the customer. It doesn't make them any less capable. 

If you're contemplating whether being a techncial PM is right for you, ask yourself what drives your curiosity, how you think about problems and solutions and what you're passionate about.