While project management and product management require similar soft skills (communication, negotiation, structured approach etc.) there are some fundamental differences. For instance, project managers need to be risk averse because their job is to make sure projects are delivered as promised. Whereas, product managers must have a higher risk appetite as their job is to maximize outcome for the business and must explore unconventional paths get to the outcome. So it's important to recognize that these are fundamentally different jobs and approach product management career with a sense of curiosity. Other than, the approach to getting into product management is the same for people transitioning from any other craft. The easiest way is to find product management opportunities within your current team / organization, rather than job hunting in the open market, because they already know you and your work.

Prioritise with respect to the key goal that is important to the org -- but balance with your estimation of what you think can land. That sounds simple, but in large matrixed organisations, that can get hard quickly. * Sometimes it's not clear what advances the org's goal -- is there a key metric? Can you forecast a project's impact on that metric, and is that forecast credible? * If shipping a particular project needs alignment from lots of teams, do all of them share the same incentives you do? If not, can they support your goals, or will they deprioritise?

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?"

A great product manager starts not by convincing people of value, but by listening and exploring problems faced by their customers and team members. So, start with understanding what challenges your partners are facing - they can range from engineering-specific issues to business performance. Pick a few of these problems that seem approachable and explore them deeply, partnering closely with the people on the team responsible for them. Then deliver an improvement. It does not have to be a complete solution - but a measurable improvement that you were able to design and implement with your partners. Getting points on the board together and celebrating a shared win is the best way I see product managers that are new on the team quickly establish their value and build reputation as a strong team member.

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.

1. Executive sponsors – if your org leaders don’t think PLG is a priority, it’s not happening. Period. 2. Effective structure – Every growth PM on the team needs to have the right balance of focus (depth) and scope (breadth) 3. Functioning ecosystem – The more intuitive the AB testing and analytics platforms are, the more seamless the operations of your growth team is. The more you invest in the squad – engineers, data science, design, PMs, operations – the more effective the outcome/impact is.

There are two ways to think about what the right KPIs are for your product and product team. One is to use a general model of customer lifecycle and the other is to align closely with your company’s overall goals and north star metrics. For the general customer lifecycle framework, a good place to start is defining metrics for each lifecycle category: discovery, acquisition, activation, engagement, retention, revenue (if applicable). Now not every product has every category, but this will get you a good place to start. This framework works for internal and platform teams as well - I know since I use it with our platform teams at BILL. While you can start with this lifecycle framework, you will want to make sure to align to the company’s core KPIs. You will want to make sure any metrics that you select within the customer lifecycle framework roll up well to the overall metrics the company is trying to move. This will help ensure that all of the metrics you are monitoring are aligned with the company direction. I will also call out that defining the right KPIs to understand and monitor day-to-day is not the same as setting goals. KPIs are intended to help you understand how your product is performing overall. Goals / OKRs are your commitments to specific ones that you want to move or change. So defining KPIs are a very important first step to get visibility into product performance, then you can get a clearer picture of where you want to focus your roadmap to make meaningful changes. 

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.

Effective communication - this is extremely hard because you have to communicate with so many different kinds of people to build clarity and alignment. It is not a one size fits all approach and the only way to get great at this is experience, soliciting feedback and intentional iteration. When I have a product manager on my team who can communicate with sales, engineering, design, leadership, customers across written, visual and verbal mediums - they're worth their weight in gold.