All related (4)
Navin Ganeshan
Head of Driver Products, Amazon Relay, AmazonMay 30

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.  

Vasanth Arunachalam
Director, Technical Program Management, Meta | Formerly Microsoft
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 fo...
Navin Ganeshan
Head of Driver Products, Amazon Relay, Amazon
(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 document...
Devika Nair
Director of Product, Oracle Cloud Infrastructure, Oracle
In my opinion, you can be successful in any role by not having the expertise if you recognize it and are willing to learn. The product manager is generally not the most technically advanced person on the team, but they bring in other expertise and experience to the team (e.g., customer data, market insights, etc). What has helped me is identifying key experts in the organization and leaning into them. I've usually not found a single technically "advanced" person on any of my teams. Different members of the team might have expertise in different areas. PMs with the expertise to identify the...