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.

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.

Reality these days is that we mostly work in remote settings, and even when we do go to the office, some people will be dialing in. As a result, I believe 80% of the strategies have to do with focusing on the fact that we are all people, 20% are tactics and adjustments for remote settings. General alignment strategies: * Build trust ahead of time. This is fundamental and driving collaboration without it is hard * Focus on common goals. There’s typically a higher goal that teams can easily align on (e.g. Revenue, Engagement, Better experience), and the differences show up as you start double clicking into the “how”. Starting the discussion with a longer term view can also help in skipping tactical disagreements and alignments * Frame, rather than take a position. With common goals in mind, center the discussion on what the characteristics of a good solution are, rather than starting with comparing options. This helps setting a more objective ground before jumping into the solutions * Call out your biases (easier to do when you have trust). In an environment where there is trust, I expect my teams to be able to call out other considerations that may cause them to pull in a certain direction, those can be different stakeholders that push in other directions, past experience and others. Some of those reasons may be valid, some may not be valid. Calling them out can help the entire team work through them. A few remote specific tactics: * Set the right structure, if possible. This includes minimizing the number of time zones each team has to work across (In my organization we are trying to limit ourselves to 2 time zones per team, when possible). If you can, hire senior enough people in the right locations to be able to run autonomously. * Invest in getting to a clear strategic direction. Having an upfront debate on the direction is time consuming, but can then help in setting the guardrails for autonomous decisions that can happen within the teams, locally. * If you do have the opportunity to meet in person, do so. Especially when working across time zones with little overlap, a good relationship would allow you to accomplish more offline, and can dedicate the overlapping time for working more effectively through the tougher topics. While I still mostly work from home I prioritize going to the office when team members from other offices are coming to town (and I am writing this note from the airport, while waiting for a flight - going to visit my team in Austin!)

In my mind, it's not an either-or. By growing existing talent, you retain organizational knowledge and build a shared culture, while bringing in external hires inject fresh perspectives and sometimes specialized skills lacking within a PM team. When I am looking at my team structure and needs, I often consider the following: Things to Consider: 1. Internal Development Programs: Promote from within by offering training, mentorship, and rotational programs that broaden your team's exposure. This approach (in my experience) strengthens loyalty, develops institutional knowledge, and keeps your product strategy consistent. 2. Hire Externally: Often times PM teams get into stuck patterns and fresh perspectives are invaluable for a team's growth. When I need new capabilities, like a strong data analytics background, or experience in a specific market segment, hiring from outside will usually shorten the learning curve and bring proven experience to the team. This ultimately helps the broader team as their exposure to these new skills raises everybody's value and potential. 3. Do Both: We need to do both internal development and external talent acquisition to manage the best possible team. Keep growing your internal team by providing new opportunities and challenges, while selectively recruiting outside talent to fill knowledge gaps and bring in fresh eyes. This way, I keep our internal culture strong, ensure continuity / grow loyalty and still gain a fresh perspective when you need it.

One question I love to ask is: "Tell me about a time when a conversation with a customer made you realize that your product direction was wrong." I have heard so many great stories about dispelling assumptions by talking to customers. One of my favorite stories was when a PM did generative research about the biggest problems their users faced with their product. They found that the feature that they were planning to spend the greater part of their upcoming capacity on was not mentioned at all! When the PM brought up the feature idea, users communicated that this feature was by no means at the top of their list. This PM found a whole new set of problems to solve that would be of higher value. 

Perhaps a contrarian take, but technical skills aren't the most critical for the majority of PM roles out there, except for deeply technical products or platform positions. For the general PM role, it's much more important to demonstrate your ability to delve into customer problems, set strategy, execute, and drive impact that aligns with your organization's mission and vision. Technical skills matter, but they are secondary. They usually revolve around your ability to work with engineering counterparts and understand enough technical concepts to make trade-offs, and to work with data and perform analysis for decision-making. In my experience, both of these skills are often inquired about directly.

One way I like to prioritize problems is based on the level of risk these will pose to the final solution. Which are the riskiest assumptions or riskiest bets that will affect the success of your product? (Risk can be defined crudely in terms of Low, Medium, High or in some cases you might have a model with some sensitivity analysis built in). Regardless, if you can quantify the risk (and thus impact) of the problem to the final solution, you have a clear blueprint of where to begin. A related method is to consider one-way vs two-way decisions. One way decisions are challenging or impossible to reverse - these have multiple downstream effects on the solution. Two way decisions can be reversed easily or adjusted over time once you have more data. I prefer to focus my time and energy on one way decisions first, as these will build the pillars of the product. If there is considerable time or effort spent by your team on a two way decision, you can make the argument to come back to this once you have more information or once all the one way decisions have been made.

Ideas can come from many places. They include customer feedback calls, customer troubleshooting sessions, customer submitted ideas (at Splunk, we have an idea submission portal called ideas.splunk.com), conferences (at Splunk, we host .conf where we have the opportunity to meet many customers in person), ideas from your engineering team (they generate some of the best ideas), and ideas you dream up yourself. Once there’s a list of ideas, we typically do a full re-prioritization at annual planning. Throughout the year, we also slot in new ideas and do minor re-prioritization as things change. 

1. Ability to communicate well - Someone told me early in my career: The single most important PM skill he looks for when hiring a PM is communication. Communication is really a proxy for building trust, driving alignment, having healthy debates when there’s conflict and committing to a path forward. That’s all under the hood of good communication, and is instrumental in driving product teams forward. 2. Data driven mindset - relevant to qual as much as to quant. Ask yourself and teams the right questions. Become familiar with qualitative research tools, understand what your dashboards need to look like, and get your dashboards in place. Be empowered to make data-driven decisions. 3. Ruthlessly prioritize - every day you have more you want to do than you will have time to do it. That’s just the reality. Every human has 24 hours, and one can’t change that. Make sure you prioritize your team and the team's time and resources.