The question I love asking every candidate is "tell me the story of the most impactful thing you’ve ever worked on." I like this question for several reasons: * It works for every level of experience. For experienced PMs, I’m expecting to hear about a very important product they worked on. For someone with little to no experience, they can tell me a story about something they worked on that was incredibly hard, impactful and meaningful to them without it needing to be related to product work. * It allows me to get a sense of their storytelling ability. Are they able to structure a story effectively? Are they able to take me on a journey with a clear start, middle and end point? Are they able to do so succinctly? * Lastly, it’s a really helpful way of assessing what they consider impactful and whether they've done something impressive that suggests they'll be a fit for the role. I've heard so many great stories, but one that stands out was for an internship role at my last company: The candidate had not done any product work before, so he told me the story of how he volunteered to help out at a student tech conference. He felt he was bad at public speaking and wanted to watch people do it well. Within a couple of years he was in charge of the largest student conference in Canada and speaking on stage to thousands of people. He told an engaging story that showed me he'd achieved something truly impressive that we wouldn't have talked about if I would have just asked product questions.

Given that it’s such a nascent function, I think there’s a lot of flexibility – I see that as a good thing! But I know the flexibility can also be daunting, so here’s how I talk about it with my team. Once you’ve been a Product Operations Manager, I think there are four primary paths: 1) Stay in Product Operations – “level up” within Product Operations and find a way to increase the scope or complexity of what you’re working on. At Oscar we have 6 levels for Product Ops, from Associate to Director and we promoted someone this past performance cycle! If your company has only one Product Ops role or title, make the business case for expanding your scope and a title change. Or look externally – many companies are building Product Ops and prior experience can be a huge asset. 2) Transition into Product Management – a benefit of working closely with Product Managers is that you get exposure to what they work on day-to-day. There are overlapping skill sets between Product Ops and Product Management, including translating needs into actionable requirements, strong prioritization skills and a deep understanding of the product you work with. I’ve had folks on my team successfully transition from Associate Product Operations Manager to Associate Product Manager – they enjoy that they’re working earlier in the Product Development Lifecycle. Note: I would be cautious if you are planning to use Product Operations as a stepping stone into Product Management. It can be a very different role from being a Product Manager and you may not get an opportunity to demonstrate Product Management skills in your day-to-day. For most folks on my team, they’ve had to take on side projects or volunteer for work outside of their swimlane to build those PM skills. 3) Transition into another Operations role – if the thing that gets you out of bed in the morning is improving processes or how things function, you may want to consider another Operations role after Product Ops. This could be within Product and Engineering – large Product Design teams are starting to build out Design Ops and/or User Research Ops. Engineering teams can have Engineering or Tech Ops (distinct from DevOps), to focus on optimizing the Software Development Lifecycle, improving Engineering onboarding and/or evaluating tools to increase developer productivity. You may want to get more creative and look beyond the Product and Engineering – the skill sets of organizing chaos, making playbooks, putting structure around things that are ad hoc, etc. are invaluable and very transferable. 4) Transition into Program/Project Management – I believe there is a big distinction between Product Ops and Program Management (I answered another question about the differences!), but there are overlapping skill sets as well. In both roles, you need to make sure people are delivering on their commitments. If your company does not have a specific Program or Project Management function, it’s likely that these responsibilities are bundled with another role – maybe even Product Ops! If your favorite parts of Product Ops are when you are coordinating across teams, tracking dependencies or chasing follow-ups, you might want to consider transitioning into a Program Management role. This can take the flavor of Technical Program Management (which may require specific technical skills) working with engineering teams or more general Program Management, which can span across all lines of business. If this career path is exciting to you and Program Management doesn’t exist at your company, define the opportunity and make a business case for these new responsibilities. There may be an opportunity to incubate the role within Product Ops, maybe as a component of your day-to-day. In talking to other Product Operations leaders, some have had Program Management teams organically form within Product Ops and before spinning them out into their own team.

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.

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.

I love this question! It happens a lot and working through it is part of our role as PMs. There are a few layers to my approach here: First, start with building the relationship. (I hope this theme is clear by now ;-). While your goals may conflict, at a higher level you are playing for the same team, and having constructive, trusting relationships is a key for any team’s success. You don’t need to agree, but at least seek to understand and show empathy. Second, focus on higher level framing, rather than your own goals - You both want the company to succeed, and if you start double clicking into what success means, you will likely be in agreement for the first few clicks. As you go deeper, call out the framing e.g. “We want to grow revenue, but also want to ensure good customer satisfaction. We may disagree on the relative importance of those factors”. I specifically recall a leader I worked with with whom I philosophically disagreed on the overall direction of my product, but could still have very productive conversations about how to think about the space. We were not trying to persuade each other, but rather use those conversations to enrich both of our thinking. Third, As you lay the framework and get to the crux of the disagreement, try to think of the “what needs to be true” statement. If two reasonable, capable groups of people look at a problem and get to a different conclusion it may be because they put different “weights” on different considerations. You can then enumerate “A is better than B if X, Y and Z are true. Otherwise B is better than A”. Example: Driving revenue up by X is more important than driving customer satisfaction up by Y if we believe that the change in customer satisfaction will lower attrition by XX and drive increased spend fro existing customers of YY”. Then the discussion can be about the conditions, not the goals. Fourth, when the discussion does move to goals, look at counter metrics. “Grow metric X while keeping metric Y within certain guardrails”. I’ve seen this technique used a lot at Meta. Last - Escalate. I encourage my teams to escalate disagreements so we, as a leadership team, can unblock them. If the work above does not solve the challenge, at least it allows for a very structured discussion among the leaders of the conflicting parties.

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.

When you’re working at an early-stage startup, I know it can feel like every conversation, Slack message, or email thread throws another item on your plate. It’s totally normal to feel overwhelmed because there is always more work than can be done by a PM. To help manage this, here are a few strategies and tips I use: 1. Define Clear Priorities and Communicate Them: Define the priorities for you and your team in terms of areas of focus. What are the most important things that will have the biggest impact on your product and your product success right now? For example, if you're at the design phase of a future release, you would prioritize things like user experience research, customer feedback, focus groups, etc. Be ruthless with your priorities, define them, and stick to them. Early in my career, I would get distracted by items that weren’t critical at that moment and later regret the distraction. The second part of defining priorities is communicating those. When your team and your stakeholders understand what your area is a focus is, it's easier to manage those incomings and set expectations. 2. Batch Your Interruptions: In a startup, the product manager is often the jack of all trades. This is a double-edged sword as being the focal point of many conversations allows you to drive the product strategy and execution with a greater degree of confidence and visibility, but it comes at a cost since everybody looks to us for every type of question. To help manage this, I typically carve out a block of time every day to respond to non-critical interruptions. Reserving a block of time either at the beginning or the end of the day allows me to defer those interruptions and knock them out without disrupting my flow. Context switching to handle incoming interruptions comes at a significant cost to your focus....so minimize that. 3. Empower the Team Around You and Defer: Typically with a small product management team, it's not possible to handle all of the incomings all of the time. Defer what you can to either other members of your team or a subject matter expert in another team. Don't be afraid to suggest speaking with somebody else to get the answer that they need. It's hard to let go sometimes, but protecting your focus is critical to being successful as a product manager. 4. Don't Be Afraid of No: Your time and capacity is valuable for your organization. Don't be afraid to say no to incoming interruptions in order to preserve your focus. It's not a black-and-white answer that applies to everything, but you need to use your best judgment and be comfortable, saying no to incoming asks and requests if it doesn't align with your priorities or won't help you drive product success. Be honest when you say no to something and be open to explaining why you are saying no. You never want to be the black hole of incoming requests where customers and stakeholders feel you don't respond....so always better to respond with a no vs ignoring and never responding.

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. 

I would say there is no substitute to real user data. User research is table-stakes. But in my experience, not always representative of "actual" usage, so don't overindex on specifics. Rather validate if the problem statement is indeed important for the user segments. Because if it is, then they might be more patient with your iterations towards solving their needs. Else they are very likely to abandon very early on and never return. A good way to test is whether they are willing to pay for the solution. Paper mocks UXR is helpful once you have narrowed themes and want to develop MVP scope. Then go build MVP and ship to a small user segment to learn and iterate. This step is the journey. Scale up only when you see hockey sticks for atleast one feature. Also retention loops should be naturally showing up by then.

Great question. It's really hard to prioritize small, iterative product improvements against large new features/bets. In my experience you need both, as well as a few other aspects. The way we do it in my teams is to think of it as balancing investment levels between different buckets, and to dedicate capacity to each of these buckets. Otherwise it's a constant struggle. We've tried to describe it in this section of the Atlassian product discovery handbook talking about ideas, and that one about prioritization. A couple of different types of buckets: * Boulders, rocks and pebbles * Boulders: large investments with potentially big payoff but high uncertainty, too. E.g. one or multiple teams over one or multiple quarters. * Rocks: medium sized investments with fewer risks, but potential for delighting users. E.g. one team for a month. * Pebbles: Small, typically straightforward change. E.g. one person for a week. * Don't underestimate the impact of rocks and pebbles! In my experience users LOVE to see the app they use get better every time, that's a great way to create fans. * RUF: Reliability + Usability improvements + new Features. Think of the RUF framework as a pyramid: * At the base of the pyramid there's Reliability. Reliability is about building trust. Trust takes a long time to build, but can be destroyed very quickly — a single event of data loss or security breach can be a serious source of churn, let alone repeat incidents. So you need to invest in your product's reliability first and foremost. * Usability Improvements comes second: a feature is rarely “done” — it’s part of a system and that system needs constant tuning. In your roadmap, it is important to allocate budget and resources to keep investing in improving your current feature set. * At the top of the pyramid is new features, both large and small. Then you decide how you want to invest in each: E.g. for a super early stage app you might be spending all your time on boulders and rocks, and little in reliability or usability improvements. For a more mature product you might spend 50% in the reliability bucket and only 10-20% on new features. Then how you actually implement that in your team can vary. In my teams we look at it at investment over time: we might be focusing on a boulder for a quarter, then go back and tackle a few rocks and pebbles. Some of the teams have a rotation where 1 engineer is focusing on pebbles each week. etc. But the important part is to have a strategy and make it a conscious choice, vs something that you react to every time you get a new request from a customer or stakeholder.