PM work life is a firehose of Slack/Teams message, customer emails, meeting requests and deadlines. Here is what I find helpful to make sense of the chaos and stay on top of the key things. * Capture, Organize, Get Shit Done. Resist the urge to jump on every message or email the same moment - you may find yourself exhausted while still behind on your goals. Instead, find a tool which lets you to quickly “capture” a thing which require your attention - and move on. Organize these to-dos thoughtfully - later, when you have time: what need to be done now, today, later this week? Some people find Eisenhower matrix framework helpful, though it may require much discipline and self-training to apply it to every day situations. My personal go-to solution for capturing and organizing PM to-dos is Trello. * Meetings. Look at your calendar and brutally question it. Which meetings you don’t have to be in? Which ones you’d be fine just reading a summary after? Sometimes you’ll have to say “no” to get your work done, even if it slightly annoys someone. * Async collaboration. A great way to reduce meetings load for me is Atlassian Loom: record a short video clip and share with your collaborators, let them responds or even with another video clip, async, at the time which works best for everyone! * Focus time. Every week you likely have a Big Rock - a bit of work which isn’t immediately urgent, yet have an outsize importance and require significant focus time to accomplish. * Plan your week. Apply everything above to your Friday routine - plan your next week ahead. Meetings you’ll decline? Focus time you’ll block on your calendar - to accomplish most important tasks? 3 things (maximum) you are looking to accomplish next week? * Plan your energy, not time. Lastly, recognize when you are at the peak of your productivity - late afternoon? mid-day? morning? Do your best to allocate this time to the most important things you are looking to accomplish. You are most productive on Fridays? Make it a no-meeting day to finish up that blog or product spec!

This one is fairly easy, add value. We as Product Managers need to ensure that we are adding value for our organization by understanding the market (and our customers) and guiding the strategy to be successful in that market. It's easy to be a product expert, but we need to focus on being market and strategy experts. In my career, some key examples of adding value are: 1. Knowing My Market Better Than Anybody Else. When I am the expert on what our market needs, both short and long-term, I add significant value in defining and driving our strategy. My product can't be successful without this. When we are proven right in terms of our strategy definition and market validation, we win. 2. Build and Foster Relationships I work hard at establishing relationships around the organization where I am working. These enable me to be effective in cross-team collaborations and makes driving alignment across the organization easier. My relationships add value to me and my team. 3. Be an Expert When you are viewed as an expert and continually show your expertise in an area that is needed within the organization, it's easy to be seen as somebody who deserves that promotion. Show that your expertise drives direct value for your organization with clear successes.

Love this question. User research is critical to incorporate throughout the funnel journey for a PM - from awareness, to consideration, to decision. * Awareness: During this phase we want to understand how prospects are learning about your product. For example, do they resonate with the messaging and positioning on your website, do they understand the market you play in, do they understand the problem you are looking to solve? This type of research can be conducted often at trade shows, through surveys, anonymous interviews, new generative AI tools to look at user review, and other marketing driven & community events. In the case of PLG products - data can play a critical role. For example what was the click through journey of your prospect, which pages did they spend the most time on etc. * Consideration: During this phase we want to understand what type of buying decisions a prospect is considering in the purchase of your product or new feature. This is often the most difficult to do direct research on as it can be hard to identify when a prospect is in this phase. I find secondary proxies here who are interacting with your prospects in this phase extremely valuable - for example the sales & sales engineering teams, & channel partners. * Retention: Once a prospect has purchased a product, this research helps us understand what will help a customer retain usage and expand footprint. Example forums for this type of user research include small customer advisory boards, private preview feature feedback, UX design sessions, customer success & support manager feedback, user questions & trends on online support communities. 

I don't really have a "scientific" answer to this - I've always done this in 2 ways: creating a bottom-up model, and trying to find data from other companies/competitors to benchmark against. Bottom-up model I've usually done this in a giant spreadsheet, trying to build a model with a lot of documented assumptions. Here's how we did it for Jira Product Discovery: * First, decide on how we would package and price the product, which we did via conversations with our early lighthouse customers, a survey, etc. We landed on: per user pricing, some users pay, some users don't, at a price of $10/user to promote collaboration use cases (we didn't want the price per user to be a blocking point to invite more people to collaborate). I'm not an expert at this but I highly recommend this conversation between Lenny and Madhavan Ramanujam on "the art and science of pricing" * Then, estimate how much revenue, based on that, we could get from the current customer base in the beta. We ran a beta for about 18 months and had > 1000 companies using the product for free. We made assumptions about how many of them would buy the product based on their usage of the product and what we knew about them from our other products (e.g. if they're already paying for Jira, if they're paying for more than one product, etc.). We already knew how many users they had on Jira Product Discovery, so with a price of $10/user we were able to estimate initial revenue in the months following general availability * After that we estimated sign-ups and conversions. * For that we used the data we had from sign-ups and conversions from the beta, we adjusted it (because beta was free), and we compared with sign-up and conversion rates from other products at Atlassian - some were a good benchmark (early products), some were not (more mature products). * We also estimated the impact of experiments we would run to try and recommend the product to existing users of Jira. We knew this was going to be our main distribution strategy, which we had validated via a few experiments already, so we had some data to work with. * Based on this we came up with a guesstimation of signups / month, conversion rates from trial to free/paid (which would go down in time as we reach more customers who are not early adopters), we took into account an element of churn, we estimated the number of users per customer (based on beta users, and also assuming we'd progressively reach bigger companies), etc. * We added to the model future initiatives that could impact revenue - for example the launch of a Premium plan at a higher price point. * Etc. - basically we built a bottom-up estimation based on everything we knew (data) but also bets into the future (new features that make the product appealing to more customers, new plans) The model is usually wrong at the beginning, but it does get better over time as real data comes in. Benchmark with competitors At the very beginning of the product, before we even wrote a single line of code, we tried to assess the TAM/SAM/SOM. There's a lot of literature online about how you do that. What I found works best for me is to assess this by proxy, by looking at other players in the market/competitors. You can find a great deal about a company by crawling its blog, finding out who is in charge, look for talks they gave, opinions they give online, etc. There is so much information online. For example: a competitor might claim they have X users, and you can match that to their pricing structure (public information) and estimate their ARR (Annual Recurring Revenue). They might boast on a podcast that they have 80% growth in the past year - that gives you an idea of their momentum. Do that for a few companies and it gives you an idea of the current size of the pie and how big the pie is growing. And you can decide how big of a slice of that pie you want/need in 1-3-5 years for this to be worth it. Careful though: another company making $100M ARR is not a guarantee it will be the same for you: it also depends on your business model, pricing and packaging. -------------------------------------------------------------------------------- By using a combination of these 2 approaches (bottom-up, top-down) you can usually get to a decent answer. But remember all this is bullshit up until the moment where customers take out their credit card! So make sure to find ways to keep testing your prospects' willingness to pay from very early days.

I like 2 use 2 things to evaluate a job: I should either learn a lot, or earn a lot (or ideally both!). We try to always favor learning, but sometimes your familial situation makes that earning may become the main criteria at some moment in your life. Overall, your career is not the most important, your life is. Nothing beats feeling good in your life, and this is what you should look for. I don't think there is any way to measure when it's time to leave, but usually you know it. Deep in you, you hear this little music telling you "it's time". And when you hear it, just look for other opportunities.

* Ability to get up to speed on unfamiliar, complex areas quickly * Highly reflective on past experiences and deep growth mindset * Infectious curiosity about customers * Succinct communicators, verbal and written These are some of the most difficult qualities to coach, and become more difficult to coach the more years of experience the person has, in my experience.

I have observed that the word strategy can be intimidating as well as misunderstood. In its simplest form, product strategy is a process of defining what your options are, and then selecting which option has the greatest chance of success. The most important step is getting REALLY clear on what your options are - which requires a deep factbase that includes market research, customer research, and product insights. The process that I use is a simple 4 step process that you can apply to most strategic decisions you need to make within a business: (1) Build your factbase (2) Define your options (3) Determine which option is best supported by the factbase (4) Make your decision & socialize. When I run this process at BILL, it usually takes between 6-12 weeks depending on the depth of factbase that we need. You should be spending the majority of your time working on your research so you can have a solid factbase as the foundation for data driven decision making. Here is an example approach you can apply to your own product strategy. * Kickoff: Hold a strategy kickoff so everyone knows you are starting the process - include key stakeholders and walk them through the scope of the strategy and the process you will use to develop it. Let everyone know how and when they can contribute or get updates during the process. * Key Questions: Build a list of your hypotheses and key questions to answer. This will help you understand what you need to learn with your factbase development. * Factbase Development: Start your factbase development. The depth of the factbase will depend on the scope of the strategy - I always include market research (market trends, TAM & SAM sizing, competitive analysis), customer research (both qualitative interviews and quantitative surveys - across current and prospective customers), product insights (this is only necessary if you already have a product live - it includes all your product analytics like conversion, activation, engagement, retention, known feedback, etc.) * Define Optionality: Once you are 50-75% through your factbase, start defining the options you see emerging. Your options should be distinctly different directions you could take. As defined, they should be mutually exclusive options, even if you do decide to take elements from each in your final decision. I usually do 4-5 options. Option definition should include: * 3 year look back vision - this can be a statement or visual of where that strategy lands you in 3 years * Target customer * Target “jobs to be done” * Core value prop for the customer * Business/market opportunity * Competitive advantage (why you have the right to win in the market) * Strategic focus areas (key things this strategy requires you build) * Select an Option: As you continue to finish your factbase, start mapping the research to the options that you have. As you finish your factbase, you should start seeing one option have more supporting evidence than the others. * Write up your Strategy & Socialize: Once you have selected which option you want to pursue, write up your case. Use your research as the supporting evidence to defend your strategy decision. Socialize with key stakeholders. 

Ideas for new features can come from a multitude of sources, and deciding which ones to build involves a thoughtful process of evaluation and prioritization. Here’s how we approach this at Barracuda: SOURCES OF FEATURE IDEAS 1. Customer Feedback: Direct input from users is invaluable. This can be gathered through support tickets, customer interviews, usability tests, surveys, and feedback forms. Customers often provide insights into what features they need, what issues they encounter, and how their user experience can be improved. 2. Market Research: Keeping an eye on industry trends, competitor analysis, and market demands helps us identify features that could be necessary to stay competitive and relevant in the market. 3. Internal Teams: Ideas can also come from within the company—from engineers, marketers, salespeople, and support staff. These team members often see different aspects of how the product performs in real-world scenarios and can offer unique perspectives on what features might enhance the product. 4. Regulatory Changes and Compliance Requirements: Sometimes, new features are driven by changes in legal or regulatory standards within an industry, requiring the product to adapt to new laws and guidelines. 5. Technological Advancements: Innovations in technology can open up possibilities for new features. Our development team stays abreast of new tools, frameworks, and platforms that can enhance our product offerings. DECIDING WHICH FEATURES TO BUILD 1. Alignment with Business Goals: The feature must align with the overall business objectives, such as increasing market share, improving customer satisfaction, or driving revenue growth. 2. Customer Impact: We prioritize features based on the value they deliver to our customers. This involves evaluating how much a feature will improve the user experience and meet customer needs. 3. Feasibility and Cost: The technical feasibility of developing the feature, as well as the cost in terms of time and resources, are crucial considerations. We need to ensure that the benefits outweigh the costs. 4. Market Differentiation: Features that can differentiate our product in the marketplace often receive higher priority. We look for features that can give us a competitive edge. 5. ROI and Prioritization Frameworks: We often use prioritization frameworks like RICE (Reach, Impact, Confidence, and Effort) or the Cost-Adjusted Impact (CAI) model to assess and prioritize feature ideas based on their potential return on investment and impact. 6. Prototype and Validate: Before fully committing to building a feature, we often create a prototype and validate it with a segment of our user base. This testing phase is crucial to gather data on the feature's potential success or failure.

We first absorbed all the relevant user research available, spent a ton of time with the core PMs to understand what had been tried – what worked well and failed. We also, in parallel, looked at data and business trends with the core PMs and assessed not only biggest areas of impact but also areas that potentially had low hanging fruit – all of which were aligned to our top user needs. Aligning the vectors of the growth team with that of the core product organization, leaning on the wealth of knowledge that already exists is critical to initial success. Our biggest challenges in navigating the shift: * Data instrumentation and proof of direction – It takes a bit to get the new KPIs off the ground, especially when it comes to engagement loops. What should the KPIs be (e.g., what is the setup/aha)? How are they correlated to business impact? How many KPIs do we prioritize this qtr.. this year? This takes a good few months to establish and prove out. * Overall dynamics – setting up the growth squads needed for success – the necessary number of engineers, designers, data scientists, PMs… especially in years when resourcing is not easy to come by is the hardest part. This requires constant discussions (read negotiations), operational efficiencies and ruthless prioritization.

One of the most challenging aspects of Platform Product Management is balancing the diverse needs of multiple stakeholders while maintaining a cohesive platform strategy. This involves navigating trade-offs between short-term tactical needs and long-term strategic goals, aligning roadmaps for individual products with the broader platform vision, driving adoption among internal teams and external customers, staying agile in a rapidly evolving ecosystem, and managing complex dependencies. Overcoming these challenges requires strategic thinking, effective communication, and a relentless focus on delivering value to all stakeholders.