It's prevalant myth that PMs make all the decisions. They make some of the decisions but not all of the decisions. But, a PM is definitely responsible for making sure their team can make high quality decisions at a fast pace. They do this by making sure their teams have access to the right information at the right time. Some examples of how successful PMs do this are 1. Helping the team understand the company / department strategy - This is typically presented to the team as the business context driving the team's work + adjacent teams / departments and their strategies. 2. Bring the customer voice to the team - This is typically presented as the customer needs driving the product focus distilled from both qualitative (eg. customer feedback) and quantitative (usage data) 3. Helping the team understand the market landscape - This is presented as the market the team's product is targetting, competitive offerings in the market, strengths and weaknesses of the competitor compared to your product's strengths and weaknesses. 4. Mostost importantly, helping the team make decisions when they have incomplete information through rigorous logical reasoning and trade off analysis. Identifying the level of risk in the decision and getting buy-in from right level of leadership (higher risk requires a higher level leadership to sign off on the decision). 5. Finally, making sure the team is not revisiting a decision made in the past unless some new and compelling information surfaces that makes it a no-brainer to change the previous decision. This typically involves helping the team document decisions and clearly articulating the rationale for the decision. At Atlassian we use the DACI framework extensively for this purpose. As you can see, a PM can do a lot to influence decision making without actually being the person to make the decision. In the few instances where the PM has to be the one to make the decision, it's worth thinking through the worst thing that can happen if you got the decision wrong. You will realize that the stakes are not as high as we make ourselves believe. I like to remind myself that no one's life is at stake if I made a wrong decision, after all I'm building a collaboration software and not a critical medical equipment. It's also useful to remember that you make a lot of decisions in day to day life without breaking a sweat. Why should product decision making be any different?

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.

No-one can, or should ever be sure that they have a 100% right product strategy. But you can do a lot to de-risk your approach, and your tactics should vary depending on how much time you have to plan. * Is your strategy ultimately going to drive the change in behaviour you want? Find the key participants in your strategy -- e.g. the customers -- and talk, talk, talk to them. You'll learn a ton from the first 5-10 conversations, and suddenly you'll start to hear the same themes and be able to predict what they'll say. Then you can move on. * Read, and connect with people who are familiar with this situation in your industry or other industries. How did things work out? Is the current market / environment similar enough that you can draw conclusions? * The more experienced you are, the more confident you can be about relying on product intuition. A phrase I often use is "we've seen this movie before" and, it's surprising how many times the same situation gets repeated.

A super common question! Traditionally the term "product manager" can often mean different things depending on the size of the company, the product's stage, and sometimes the overall market segment. I often times bucket them into these core groups: 1. Technical Product Managers (TPM): These PMs work closely with engineering teams on more technical products, thinks like API driven products where the end "customer" is technical in nature. For these roles, you will need a deeper level of technical expertise and the ability to understand the technical aspects of your customers needs. 2. B2C (Business to Consumer) Product Managers: In a consumer-facing environment—like mobile apps, e-commerce platforms, media consumption products — I find that PMs often emphasize UX and product design (along with core PM responsibilities). One of the key areas that this group focuses on is leveraging a typically broader/larger customer base to do things like A/B testing, and quick iteration on product designs to validate assumptions and feature value. 3. B2B (Business to Business) Enterprise Product Managers: These enterprise PMs focus on delivering products that solve businesses' complex problems. I spent a lot of my career here and this type of PM spends a lot of time on sales enablement, strategic account engagement, and roadmap management. Given that most B2B solutions have a longer sales cycle, their relationship with sales is key to success. Depending on the size of the organization, this type of PM also focuses a lot on the financial side of the product. 4. Infrastructure Product Managers: These PMs (sometimes internally facing only) focus on building components that other teams and products rely on, oftentimes within an organization. For them, the GTM isn't as relevant but they need to understand and balance things like scale, interoperability, and business alignment. Figuring Out Your Best Fit: 1. What are your Interests: Consider things like Do you enjoy getting into the weeds on technical discussions? Do you more get energized by user research and design? Do you geek out over analytical data and love looking at usage metrics to drive feature development? Each type of role has a different focus, so find the things that excite you. 2. Consider the Environment Do you want to reach a huge market of customers and iterate on minor feature developments and enhancements? Or do you want to work closely with larger business customers and develop a deeper understanding of their problems and how your product can evolve to meet those specific needs? No right or wrong answer, just what gets you pumped up each day. Remember, it’s about aligning your career desires, your core strengths, and the types of challenges that get you fired up to solve each day. We are problem solvers, so what types of problems do you love solving and how do you like solving them? Many PMs start in one area and end up in another. All the roles share a common framework of ensuring we are delivering business value for our organization and delighting our customers with innovative and useful solutions to problems they either have or don't even realize they have yet.

Product and product marketing work best as partners—not folks talking at one another through a wall. PMMs bring market context, buyer insight, and positioning expertise that help shape what you build and why it matters. Involving them early makes the roadmap stronger and easier to launch. Here’s how that partnership usually works: * Co-create roadmap inputs: PMMs bring win/loss data, competitive intel, and market trends to help prioritize high-impact work. * Validate demand & urgency: They help answer, “Is this worth building now?” by tying features to real market signals. * Sharpen messaging early: Collaborate on the story behind a feature as it's being shaped, not after it's built. * Align on GTM plans: PMs and PMMs define launch tiers, enablement needs, and feedback loops together—not in silos. tl;dr Let PMMs into the kitchen early—roadmap reviews, sprint demos, etc. The earlier they’re in, the clearer and more impactful your launches become and the more successful you'll be.

Develop a product mindset: For early career PMs from a skillset perspective, choose whether consumer, enterprise, or developer products appeal to you the most. Do a side project and build your own! Pick a few products with that persona (e.g, pick three of your favorite consumer tech products) and understand how users interact with the product, the pain points they face, what could be improved, industry trends driving that product. Your goal is to start developing some understanding on market trends and how user experiences could be improved. Look for established PM programs: For early career PMs from a recruitment perspective, look for established PM or APM programs with good career development programs & mentors. PM can be different in every company you go to and learning the art of PM at a larger company first and then applying it at earlier stage companies later in your career can serve you well. From an interview perspective, great resources exist online for PM interviews, developing a PM oriented mindset etc. I personally feel product management is a better suited career after a few years of experience in a domain building role (e.g, software engineer, PMM etc). As a PM if you can bring a point of view on the domain you will be operating in and some experience of the market, user, tools and GTM motion it will enable you to be a more empowered PM.

* PM interviewing tools like tryexponent, Igotanoffer, product alliance, etc have a good breadth of various PM interviews, especially for popular companies like Meta who have focus rounds for Product Design, Product Sense, etc. * Mock Interviews: Similar to above, there are various services that offer both paid and unpaid mock interviews, usually done in a real-life interview setting with time dedicated towards the end for feedback. You can also rope in friends and your PM network to help with conducting these mocks * Building a story bank: Usually a number of PM interviews start with a specific question that leans on an example from your career. I recommend creating a story bank from your experience that addresses some of the most common cases. * What was a product/feature you are most proud of? * Tell me about a time when you worked on a project with a cross-functional partner (engineer or designer are the most common ones). What were some of the challenges in collaboration? How did you overcome them? * What is a hardware/non-tech product that you like? Why? How will you improve it? How will you monetize it? * Tell me a time when you relied on your intuition vs data? Why?

The “soft skills” are often what separate the good from great product managers. In particular: * Curiosity - An insatiable curiosity about your customers, partners, fellow team members, technology and just about anything that comes your way helps add arrows in your quiver you can use when tackling the wide range of daily challenges product manager takes on. * Story Telling - Central to a product manager’s success is the ability to influence key parties to deliver an outcome. Whether its influencing the customer to use your feature, the engineering team to build something, the product manager ultimately has to craft and deliver a clear, energy-infusing narrative that touches on logic and emotion to compel the party to deliver the desired behavior. * Hustler Mentality - Great product managers consistently deliver results even in the most constrained environments. They do this by being scrappy, resourceful and opportunistic - using great judgement to figure out where they should spend their energy, thinking creatively about how to marshall the resources they have, and steely resolve when tackling blocking issues. They do not resort to victim mentality. This is not to say that specific technical or writing skills are not important. However there are many flavors of PM where “hard” skills required vary. But the above needed soft skills tend to remain consistent.

* in product reviews, when an exec/lead asks you something about your product decision, don’t table it and say “idk, we’ll assess and circle back with you in xx days”, rather just say what you think ought/should happen. You could state that these are assumptions and you could/should validate later. But as a PM, you’re paid to have an opinion on the spot, and oftentimes we don’t have all the data/research at our fingertips. At least the exec could course correct you on the spot in case you need misdirection, so you don’t fall into a rabbit hole * in presos to execs, lead with the spicy thing first (the solution, the recommendation, etc..) and have the justification/rationale/analysis follow it. for non-exec presos, it’s generally recommended to reverse the order. This may be obvious, but I’ve seen it overlooked sometimes. * expose a healthy dose of skepticism, call out product/market risks/assumptions - but do it in the latter half of the preso, If you only present positive info, folks naturally get suspicious around what are you hiding (this was inspired by Mihika Kapoor's talk at Lenny's Summit earlier this year, but it's principles I've adhered to and shared with my PMs for the past couple years)

Let me assume you are staying within your software (or hardware) realm, as switching from software to hardware product management (or vice versa) could be way steeper hill than entering a new domain like AR/VR. Here is something that would made me seriously consider a candidate without a specialized AR/VR experience - for an AR/VR position: * Stellar track record in non AR/VR product management. You rock as a product manager - many will consider this more valuable than hands-on with the domain. This is table stakes. You are already at disadvantage, so first of all demonstrate you are a rock star PM. * Story telling - if at all possible, find and demonstrate how aspects of your prior work can be applicable to AR/VR. Was there a project where you came up and succeeded with an unconventional UX solution? Tell a story how AR/VR is evolving quickly to find new UX patterns - and how you can apply your past experiences to that. * Domain knowledge: yes, you didn’t work as an AR/VR PM. But you surely invested a lot of time in understanding this domain. You know the market, the players, the product, the technologies. You’ve been to industry events and meet ups to hear inside stories first-hand. You talked to AR/VR customers about their experiences, yays and nays. You can speak the same language with your hiring team. * Passion - lack of hands-on experience is your disadvantage. Make your genuine passion offset that one. Show it’s not “just a job” for you. With all other things equal, this will tip the scale in your favor.