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.

PMs should define the success conditions in the strategy (e.g. 20% market share, or $20M attributable revenue in H1 etc). Those success conditions should: * Ladder clearly up to the needs of the org or company * Define a realistic stretch goal, ideally validated through customer discussions or other qualitative or quantitative research -- including timelines * Cover direct and indirect effects as needed * Include countermetrics or contraindications that define changes to be avoided

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.

The following stand out to me for what I've witnessed: * The team is acting like the product they're creating is going to be successful. I'm amazed at how many successful companies try to build new products like they do for their existing successful ones: same processes, same success metrics, etc. They don't have the urgency, move too slowly, learn too little, are complacent. The market is a graveyard of failed products and businesses: the most likely outcome, when creating a product, is that it will fail. As a result we shouldn't assume success but instead focus on doing everything we can to de-risk, test and validate - and make sure we don't over-invest too early. I recently was interviewed in Lenny's podcast to talk about that: if you're working on 0-to-1 in a bigger company I think it's worth your time. * The team built a solution to their own problem and they assumed that many more people would face it in the same way. We hear a lot of success stories that started like that, and while it's true that some successes began like this, it's also where a lot of failures came from. You're not the customer of your product: work with real customers! Or it's only going to work for a small population, and that may not make it a viable business. Mehdi, the founder of Cycle, shared openly a great example of this for how they changed their approach to user onboarding. * The product manager tries to get a big team from day 1. Honestly a small team can move 10x faster than a big one. You need a team of people you can trust who can move mountains on their own and continents together. For the first year of creating Jira Product Discovery we only had 5 engineers, and we moved really fast. It forced us to focus on the most important things, to be nimble and creative when testing solutions, and we could do this with very few meetings (it's very easy to get everyone on the same page at that scale). Once you've proven you have a solution that solves real problems for a small number of users - you can then go back and ask for a (slightly) bigger team. Resist that urge to grow too fast! * The team is fighting too many battles at once. This happened to us at Atlassian when we tried to rebuild Hipchat into another product called Stride. We were trying to launch a new product built on top of a new platform that could be used for all other Atlassian products. We faced this tension product<>platform from day 1, and it was much slower to move on the product front. Like with any failure there's of course more than one reason this product didn't pan out, but this is definitely one of them. * The PM fails to get the right level of buy-in internally - if it's about creating a product inside a bigger company. It's very important to "build chips" in the company (gain trust from leadership) so you can spend them, gain more chips, etc. And it's key to communicate your learnings and progress in a way thatmake your team look like a high speed train - no one wants to get in front of a high speed train. This is one of the topic I cover in an interview on Lenny's podcast.

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.

When creating a product vision for a 0-1 product, the focus is primarily on finding the right product-market fit. This phase involves investing significant time in user research, deeply understanding the problem your users face, and identifying their pain points. The goal is to come up with an MVP (Minimum Viable Product) that is good enough to launch while also being flexible enough to evolve. Recruiting design partners and consistently iterating on the vision is key in this stage. It’s important not to get too attached to the original vision, as many pivots can happen during 0-1. Continuous learning and the ability to act quickly are crucial to success. While understanding the market potential and competitors is important, you may also be creating a new market, making it more challenging to predict trends and identify emerging competitors. As the product grows and matures, the product vision also matures. In this stage, the emphasis shifts to validating which features, functionalities, and packaging add the most value to users and the business. The focus is often on retention, expansion, and revenue growth. It becomes increasingly important to monitor market trends and user behavior to identify opportunities for value improvement. This is also the time to assess when to invest further in expanding a successful product or when to sunset features or technologies that are outdated or have limited user appeal. Maintaining old technology or underused features can hurt the business by diverting resources, so it’s essential to keep optimizing. At this stage, staying informed about competitors is key, ensuring you leverage any new competitive advantages. The goal for a mature product is to remain a cash cow, continuing to deliver value to users and impact the business positively. This requires continuously improving, growing the user base, and increasing revenue while keeping a close eye on market trends and evolving needs.

I've been working at fully (or practically) remote companies for ~5 years now and I believe they can certainly work. Tools like Zoom, Slack, and Miro can (mostly) handle the day to day activities of product teams. However, in person time is still critical for some activities and for building a product culture you want. Some rules I have: 1. I try to do a team offsite at least quarterly. This allows for free flowing discussions and brainstorming that don't translate well virtually. I plan a few days that include ample whiteboard time as well as dinners to do some bonding. 2. As a product leader, you need to be hyper aware of how team members perform in a virtual environment. You don't get as much signal from body language virtually. I always try to check in during 1:1s on how each team member feels about the culture, their role within the team and try to manage virtual meetings accordingly.

I would start by separating out measuring product health from goal setting. First, every PM needs to have a clear understanding of the key metrics for their product area. This is a baseline set of KPIs so a PM knows how their product is currently performing and which specific KPIs are under or over performing. A good place to start when building a baseline is to use a general lifecycle model and define metrics for each 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. Once you have a baseline set of the overall key performance indicators you want to monitor day-to-day, you can get a more holistic view of how your product is performing. From there, you can decide on which KPIs you would like to set goals around. Whether you use an OKR framework or some other framework, you should make sure the goals that you set are not only aligned with where you can make improvements in the product life cycle, but also what the CEO and company is looking to drive. Once you create this visibility into current performance - it becomes much easier to align the CEO to the goals you would like to set - and in turn it also gives the CEO visibility into how you are going to measure impact and a way to for the team to have accountability to move a specific set of metrics vs. accountability to move all of them at once. 

For early career IC product managers, success is measured consistently with how you manage the product lifecycle, pace of delivery, the value of features you deliver to users, and how they contribute to growing the overall business. For me, I added 2 unique criteria to evaluating my success as a PM: GSD-ness and Catalyst. * GSD-ness is your 'getting sh*t done' meter. When executives have a complex project that needs to be done on an aggressive timeline, do they think of you as the person who can get it done despite the difficulty? Being the person who can consistently deliver things, no matter how complex, across the finish line in a high-quality way, was what helped me a lot early in my career. * Catalyst is another qualitative measure for whether you're someone who people want to work with because the work you do accelerates their professional and career growth. The way I like to think about this is whether engineers and designers go out of their way to request to be on your project/team. For clarity, this is not a measure of likability, but more a measure of leading things to success which attracts and inspires others around you. Basically, take on complex projects and deliver them at a high-velocity while having fun through the process! As the scope of my role has grown, the success criteria have shifted from tactical delivery towards business impact. More specifically: * Product Innovation: Constantly re-assessing our market and thinking about new product opportunities for expanding our TAM and increasing value for users. What new things can we launch to extend the platform? * Strategic Alignment: This involves aligning with cross-functional leaders from Marketing and Revenue to make sure that we're all working towards the same company goals and that they're aware of the work my team's doing to contribute towards them. Specifically, the tradeoffs we're making and why. * Organizational Health: Evaluating the heartbeat across teams to understand the biggest points of friction that decelerate development, getting a sense of the morale of the team, and soliciting feedback to identify opportunities for improvement. I do an introspective exercise with my manager every 6 months by asking the question - "What if I vanished off the face of the earth tomorrow? Would the business/company be ok?". If the answer is "yes", you need to expand the scope of your responsibilities or find a role where you can have more impact.

Firstly, thank you for your question, and it’s one that I believe any aspiring or seasoned product manager should be asking. The fact is that regardless of your domain, both business and technical landscapes continue to change, and as a product management leader I try to stay at the forefront of changes. In terms of where to look, it really comes down to where you are in your career, and what you’re looking to get out of the training. Also, remember that not all training needs to be classroom-based. Experience from working the job itself accounts for most of the learning in the field (and typically aligns to the way your organization views and conducts product management). That said, a few thoughts depending on what you may be looking to achieve: 1. Learning the Basics. This can be helpful if you’re not new to product management or have been away for a while. A couple of good areas to look at: * University or College Courses: Universities including Kellogg, Capella, Cornell and more offer certificates in Product Management, or you might choose to take a more formal degree in an adjacent field like business, marketing, or computer science. * Online Courses and Bootcamps: Platforms like Coursera, LinkedIn, the Product Institute, Product School, and Udemy offer courses focused on Product Management. 2. Advancing your skills. We’re often asking ourselves if there is a better way to do product management. For these I’d recommend looking at: * Online Courses, especially where you can select courses covering the areas you want to brush up on, like with the Product Institute and LinkedIn. * Blogs and Podcasts. Personally, I like to try to keep up with the latest updates in the field, and to do so I read blogs or listening to podcasts from individuals I respect in the industry, like Melissa Perri (see her site with links to all her content and classes at https://melissaperri.com) and Lenny Rachitsky (see Lenny’s Podcast at https://www.youtube.com/@LennysPodcast). There are others out there but, in my opinion, those are two great leaders in the space. * Books. There are many good ones out there, but a few ones that I've read more recently include, "Working Backwards" by Colin Bryar and Bill Carr, "Escaping the Build Trap" by Melissa Perri, "Continuous Discovery Habits" by Teresa Torres, "Hacking Growth" by Sean Ellis and Morgan Brown, and both "Inspired" and "Empowered" by Marty Cagan. * Local Groups and Communities. ATX Product Happy Hour is an example of a group that gets together in Austin periodically, and you should look to your region for similar examples. Lastly, a caveat about online training and personas. There are a lot of folks out on social media, on the internet, and on professional sites like LinkedIn professing to be able to teach you product management. I would be cautious and recommend that you do your research. It doesn’t matter if they’ve worked at Microsoft, or Amazon, or have taken an online course with Harvard or similar (note a new habit where people drop a top-tier university into their profile as if they have a full degree from there, and when you look further you find they’ve only taken an online course). Net is, look at their experience or credentials, or even reviews from others, and see if they have the ‘right stuff’ for you to invest your time or even monies in.