In my opinion, building influence with your engineering team boils down to these 3 things 1. Understanding engineering complexity even if don't quite grasp all the details eg. do you understand the cost (experience implications, impact to future team velocity etc.) of having tech debt when you ask your engineering team take short cuts? 2. Being able to represent the engineering considerations in forums where your engineering team is not present eg. discussions with the sales team where they ask for specific delivery dates features on the roadmap. 3. Empowering the engineering team to understand the product context and take shared ownership for outcomes rather than just being a delivery team. A good litmus test for this is to assess how comfortable your engineering team feels about making product decisions and keep making progress when you are on leave. If you invest time and effort in doing these 3 things, you will build significant trust and influence with your engineering team.

1. Bring structured thinking to your communication and approach: Become effective at breaking down problems using structured thinking. For Behavioral questions, look into the STAR method. For other product sense questions, look at case study books such as Case in Point and PM interview practice. This is a critical skill set that will serve you well as you take on different types of PM challenges on the job - from developing a new PRD, doing a competitor analysis, to building an execution plan. 2. Have a good pulse on market, products, & design trends in the industries you are passionate about: Read, observe, podcast, leverage Gemini & ChatGPT to constantly stay up to date on trends in your relevant markets. Bonus if you can keep trying new products in your space and be able to articulate the user journeys and pain points. 3. Showcase your leadership in various aspects of your personal and professional; journey: Whether it was leading an effort in a nonprofit group, or in an extracurricular, or work - reflect on leadership journey and be able to articulate how you would bring that to the organization you are interviewing for. 4. Demonstrate your passion to learn & be open to feedback: With the fast changing technology and world landscape, hiring managers want candidates who will go above and beyond to learn. Demonstrate your approach to learning new skills and how you would continue incorporating learning in your day to day. 5. Get effective at using data & metrics: Critical in today’s PM role is leveraging data to augment key decisions. Be able to illustrate how you leveraged data in your past roles / projects. Think of building your data skillset just as you would build your technical and domain skill set - learn different tools for data analysis, dashboards, and best practices for metrics that matter in your domain.

You should think of it as: it should be ready to be shipped when it's the first shittiest version, and when it's the best version of itself. The question should not be not so much about readiness of the solution, but readiness for whom? I've witnessed teams who got too excited when creating a new product and opening the floodgates to let anyone try it too early. That usually doesn't end well... You don't want many people jumping on the solution when it's not ready for them: first impressions won't be good, they won’t stick around and you'll need to work hard to get them to try again. Here's the approach we take in my teams: basically, for anything we ship, whether that's big new features to Jira Product Discovery or new products (including Jira Product Discovery itself), we work with progressively more customers (10-100-1000) before making it generally available. It helps us test the solution very early with a handful of customers to get feedback and make sure the solution delivers on its promise for them, and ensures that everyone only gets the solution when it's ready for them - thereby increasing retention & minimizing churn. If you want to learn more you can watch this talk I gave about the process we went through when creating Jira Product Discovery. You can also read more about this topic in the Atlassian Product Discovery handbook, that we wrote to help with things like this. 0->10 customers (preview) In the first phase of early stage bets we only work with max 10 customers. We unpack the problem and test solutions and iterate fast, which is a process that’s best done with a small number of users/customers that feel the problem the most. And we get the solution right for them. It’s easier and much more focused to do it this way than “throw it out there and see what sticks”. Users who feel the pain the most will be happy to work with us, we can chat with them on Slack/Zoom/Email easily. They're happy to work with incomplete solutions (we can take a LOT of shortcuts) and we can remove the need to pile on untested assumptions. If the solution doesn't work we can throw it away, it's cheap, no harm done. To demonstrate progress to leadership we use metrics that best represent what we're trying to prove at each phase. We started with the following for the private preview of Jira Product Discovery: 10 active teams have been using the product for more than 3 months and plan to continue using it when we enter beta 10->100 customers (alpha) Then we progressively invite more customers to use the solution. At this stage we usually need to polish rough edges and address more scenarios based on what we learn from working with customers of varying needs, and maybe less willing to work with a rough prototype. It's also harder to collaborate with every customer 1-on-1 so we need to create better onboarding material, demo videos, etc. We move support to a community forum. Our success metric at that stage when creating Jira Product Discovery was still focused on problem-solution fit, but for more customers: Product market fit score of 40% or greater with 100 active teams (I highly recommend the Product market fit score survey, and you can read all about it here) 100->1000 customers (beta) At some point we become ready to share with more users, in our case for Jira Product Discovery it was when we reached 50% PMF score for more than 100 active teams. At that stage we needed to focus on making the solution fully self-service - we couldn't afford to have to talk to every customer once in their journey. So we focused on in-app onboarding, we improved usability, we polished the design, we scaled the technical implementation, we trained support and sales teams, etc. It's really about making it ready for prime time. It was also time to change how we measure success by introducing more metrics that represent the health of the funnel as more customers discover, try and adopt the solution on their own. That’s when we started adopting pirate metrics (AARRR), and here's a great read about them. In the early days of that stage we also focused on validating a pricing model, but that would be a topic for another post. Once we were done with all that, had high PMF score for 1000 customers, healthy conversion rates and retention, low churn, validated pricing - that's when we decided to make Jira Product Discovery generally available. These phases work for us - it doesn't mean they will work for you, but I believe that this general approach should apply to a lot of contexts. Basically: don't focus on "when the solution is ready to be shipped?" but "who should we be working with right now based on the state of readiness and validation of the solution?"

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?

Not sure I would call them hacks, but I have various things I do to manage both my workload, product execution and overall team management. 1. ToDo List Goes without saying. Be organized and find a system that works for you. Pen and paper? Go for it. Trello board? Do it. Adoption Notion? Fire away. For me, it's been about finding what system works for me and being relentless with it. My memory is generally solid, but our roles as PMs mean we shift a lot ,and keeping track of things is the only way to be successful. You don't want to be known as the PM that people have to remind about asks over and over again. 2. Manage Your Calendar with Precision I manage my calendar carefully. I block the time that I need for things like responding to interruptions and checking in with various projects each day/week. Unless it's critical, I won't move those slots and that allows me to stay organized and on top of things. 3. Kanban for the Win I have been using a Kanban-style prioritization process for over a decade. Allows me to easily see what's in flight, what I need to keep an eye on, and at any given time, what is top of the pile to focus on. Lots of great tools for this, like Trello. I try and keep it simple with a backlog of items, what's in flight, and then what's done. 4. Automate to Success So many of our daily tools have automation capabilities that we can leverage to help with the simple things. The more "little things" I can take off my plate the better off I am to focus on the value-added things in my workload. Don't fall into the trap of "it's just easier for me to do it this time". If there is a way to invest a small amount of time to automate repetitive tasks or items.....do it.

Using a clear, published framework that aligns to the organizations broader goals or strategy is important to prioritizing any set of work. Without this, it will be difficult to build confidence with your team that decisions will hold up and they won’t have the context required to make sound decisions in their execution of the tasks they are assigned. A prioritization framework doesn’t need to be complicated - in fact its often better if its so simple that it can be committed to memory. In many cases the best discussions I’ve had with my leaders focus on aligning on the prioritization framework over a whiteboard, with the output often being a simple bullet list or table calling out the characteristics of projects that will fall into each bucket. It’s also advisable to test your prioritization framework by running a few examples of actual work items and seeing if the team leads align on how the framework is applied and the priority outcomes for each. Setting the framework is usually simplistic when running a small team with clear goals or OKRs, as those can easily map directly to the priority framework you define for the team. As you take on more strategic roles where there are difficult calls to make balancing resources across competing priorities, I’ve found that the “Core Context” model by Geoffrey Moore helps me form my first cut at a priority framework for delivering on that strategy. 

I honestly don't think there is a right ratio. Team makeup should not be decided by arbitrary industry averages, but rather based on the nature and complexity of the problem (or problem space) that the team is working on. I've seen a PM work with 10+ engineers and I've seen a PM work with 3 engineers. Both teams were successful because they were sized to the problems at hand.

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.

Balancing this is a delicate act that requires constant reassessment and a strategic approach. It's essential to recognize that both competitive differentiation and customer retention are critical to a product's success. Differentiation makes you stand out in the market, attracting new customers, while retention ensures that your existing customers stay satisfied and loyal. One approach I use is a cyclical evaluation process. Every month, I reassess priorities to see if anything has shifted. This means regularly checking if new information or changes in market conditions should alter our focus. It also means checking in with strategic customers to ensure that their priorities are still the same. For less mature products, it can be difficult to differentiate when there are table-stakes features that aren't implemented. Definitely not impossible, but difficult. In these situations, it's important to focus on features that deliver the highest ROI and have the broadest appeal. These features might not always be differentiators, but they are essential to build a solid foundation. However, even at this stage, I believe that you should allocate some resources to developing innovative features that set you apart in the market. In more mature products, the balance might shift. A significant portion of your development efforts can then focus on differentiation. These could be features that only apply to a small number of current customers, but grow your ability to reach new customers. Still, customer retention should never be neglected. For the more mature products, here’s a practical breakdown (the actual numbers are going to be different for everyone): if 15% of your sprint is dedicated to maintenance and tech debt, and 20% to bugs, you have 65% left for new feature work. How you split this remaining time between retention and differentiation depends on your current priorities and business needs. For example, if you have a groundbreaking new feature that could dramatically increase your ARR by expanding your total addressable market, it might be worth dedicating 50% (or more) of your sprint to it, leaving 15% for retention-focused features. On the other hand, if customer satisfaction is slipping because you haven’t delivered on requested features, you might flip those numbers to ensure you keep your current users happy. However, it's important to always keep some capacity for innovation. Make sure part of your iteration is dedicated to differentiating your product. Plan for this in your sprints, even if it’s just at the proof-of-concept or validation stages. Think of this balance like balancing spinning plates while standing on a board balanced on a pipe—it's a constant struggle, with the ground always shifting beneath you. But with careful planning and continuous reassessment, you can maintain that balance. It might shift one way one month and a different way the next month, but you can do it. Keep evaluating your strategy regularly. Align your feature development with your company's vision and current needs. By balancing short-term customer retention with long-term differentiation, you can ensure your product not only stays relevant but also leads the market. And remember, never get too comfortable—flexibility and constant reassessment are your best tools in maintaining this balance.

As a PM, you should know the architecture of your product's tech-stack, so that you could have meaningful conversations with your engineers about tradeoffs, capabilities, limitations, and estimates. You don't necessarily need to know how to code, unless your product is code (ie PM for Swift at Apple).