Very relevant question for the times we live in. I'm going to focus on how PMs at Atlassian are using AI to augment their workflow, since that has been a huge focus for us. 1. Refining your writing - Atlassian has a very strong written culture, especially within the PM team. This how we communicate ideas, strategies and influence stakeholders. It's no surprise that we leverage Confluence very heavily and the AI features help PMs go from rough draft to a polished document pretty quickly. 2. Consuming written communication faster via AI summaries - the flip side of having a strong writing culture is that you now have to consume a lot of written documents very quickly. AI driven summaries integrated in Confluence, Rovo Search & Chat are time savers. 3. Creating prototypes from PRDs - most of the time a PM spends with their teams is to drive clarity on what needs to be built and why. AI Tools like Bolt, v0, Lovable and Replit enable PMs enable PMs to quickly convert their PRDs into a working prototype without having any design or coding skills. It's way more efficient to align your team using a prototype rather than a written document (PRD) 4. Rapid iteration - we all know that testing prototypes with customers is a great way to validate ideas before writing any code. But it still take significant effort and know-how to create prototypes and iterate on ideas. Changes are made between user testing sessions rather than during the session. Prototyping with AI significantly shortens the time and effort that it's possible to make changes to the prototype during the user testing session with just 1 or 2 prompts.

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

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.

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.

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

More often than not, an experiment fails. Failed experiments are the biggest sources of learning. Was your hypotheses proven wrong? Was the test design not pushing it far enough? Were there other data anomalies? Where there any positive signals in a subgroup? One needs to be careful in slicing the data by many cuts, as the validity of an AB test is largely dependent on its effect size. Cut it too much, and you might be cherry picking the data thereby losing its meaning for decision making, or worse you may lose yourself in a thousand cuts. I have found it best to align failed test reads directionally with a broader learning agenda and lean back on user testing and user research to come at the hypotheses in a few different ways. In fact, even if the test is a winner – I would still approach the hypotheses in different creative ways till you find paths that are optimal to users and the business. There is never an end to experimentation.

When transitioning from consulting to product management, focus on building these key skills: 1. Clarity of thought and communication 2. Problem-solving abilities 3. Comfort with ambiguity and change 4. Collaboration and influence Seek opportunities that allow you to develop deep product knowledge and context in a specific domain. This 'domino effect' of expertise can significantly boost your PM career. For the transition itself: 1. Client-side is often the quickest route, leveraging your existing relationships and industry knowledge. 2. Startup experience can be more valuable than a formal degree, especially given the rapidly evolving tech landscape with AI. 3. While an MBA can be helpful, it may not be necessary given the fast-paced changes in technology.

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.