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.

If you know that customers are not willing to adopt your solution, that's a bad spot to be in. 1. Re-evaluate what led you to the decision to build & when to do it. Was there a gap in your methodology, or a piece of research that led you down this path? How can you avoid this for the next piece of strategy planning? 2. Don't hope for better adoption -- test and prove this out. Can you get a high quality signal that customers will adopt, e.g. customers will pay you now for access to it? 3. Is there a wider org that will bear the cost of holding this solution, and values it for reasons other than direct revenue?

At every level, the core PM competencies of driving clarity and alignment through clear communication, delivering measurable outcomes for the business and influencing without authority remain the same. But the ambiguity within you are required to clarity, the impact of the outcomes you drive and the seniority of the stakeholders you influence increase as you become more senior. If your are a people manager, the size of the PM team, and the diversity of PM roles within the team, increases as you become more senior and you will need to start thinking about strategies to grow and retain talent at scale. In a nutshell, it's the same core competencies, but you are expected to operate with greater ambiguity, deliver greater impact and have broader influence commensurate to your seniority.

Great question. In my personal career journey as well as several hires I’ve made I’ve always found it helpful to try the new role before you go all in. When I was at a startup where we didn’t have well defined programs like Google’s 20% program or PM rotations, I asked to work with the PM team for 6 months on the side where I took on some of the PM responsibilities for a non-critical product. By doing so, I personally got conviction if the role was right for me and the PM team also got to see me in action. This made my transition much easier and also helped me come in at a more senior role. Similarly I’ve made hires who had a similar path - they often either did a 20% project or a full time rotation - and this helped make a case for their PM transition. If your organization doesn’t have formal programs to try the PM career path I’d encourage you to network with PM leads you are close to and see if such a project could be developed.

* 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.

I don't think there is a typical product career path! Many of the PMs I have worked with or hired have changed careers and moved around in different roles. I see people enter from college with software engineering backgrounds, or experienced senior people moving from other software crafts such as design, engineering and project management into product management. For example, I have former startup founders and former DevOps engineers on my current PM team. If there is something typical about all paths - it is that PMs are people who have interest and experience in technology and truly want to improve customer and user experiences with technology.

You should try to split your stakeholders into two categories: * Primary Stakeholders - The ones which will be directly benefit or impacted by your work. These should not just be your customers who will use the product, but also the teams who will help get this work to the finish line, upper management who need to report this work to higher above. Primary stakeholders can be of various functions - PMs, eng partners, user researchers, design, PMM, leadership * Secondary Stakeholders - These are the ones who will be indirectly impacted by your product. The teams who are at the tailend of the consumption pipeline of your product. How to decide if something should land on the roadmap - There are a few factors you should consider while building a roadmap: 1. Business impact - How much value it is delivering to the business. How does it map to the top level business objectives and key results 2. Level of effort - Sometime the feasibility and level of effort can help you make a decision 3. Tactical Vs Strategic - Sometimes tactical work is throwaway work in the long term, sometime it's not. You need to gauge that and decide accordingly If you want to use a framework for prioritization, I would recommend RICE - reach, impact, confidence and effort.

I am not an expert in ecom, will suggest below * Compare historical and watch out for trajectory * Analyze your data for pattern 1. specific time, geo, day, specific step in transaction, specific payment method) 2. Translate error rate to business impact ( Big $$ cart v/s small one item) * Customer Impact ( Attrition, NPS) * Compare with industry peer trend if available. All above and your business strategy goal should answer for ROI in improving this rate or focus efforts elsewhere.

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.