Creating value for the customers is a must. But as a PM, you also need to capture value for the business. And it doesn't happen automatically. I've been playing with available tools and, over time, started using the Extended Opportunity Solution Tree: - ❤️ Customer opportunities: Customer needs, problems, and desires - 💚 Business opportunities: Business, needs, problems, and goals Here's how it might look in practice for a SaaS product where only 2% of users upgrade from free to paid. In the attached OST, you can see that: - We included both the user perspective (creating value) and the business perspective (capturing value). - We discovered that the free version offers too much value, while the paid version offers too little. Those are Business Opportunities. - We identified Customer Opportunities that, when addressed, could increase the value offered in the paid version. - We came up with the idea of decreasing limits in the free version. This doesn’t add value for free customers but reduces it. We wouldn’t consider this approach when working with a traditional OST. - We decided that a new Customer Opportunity related to security should also be tackled in the free version. - We could reverse-engineer the “Customers don't know what they are missing out” to create Customer Opportunities, but this approach feels somewhat artificial. These are growth/marketing needs. It would feel more natural to create Customer Opportunities below if needed. Hope that helps. What are your thoughts? --- Enjoy this? Deep dive on combining Impact Mapping with OST: https://lnkd.in/dwiUBvzp Read Continuous Discovery Habits by Teresa Torres to learn about the original approach. It's a must-read for any PM: https://lnkd.in/d9AtGkEC
The Product Compass
Technologia, informacja i Internet
Weekly newsletter by Paweł Huryn. Actionable tips and resources for Product Managers.
Informacje
Actionable tips and resources for Product Managers.
- Witryna
-
https://www.productcompass.pm
Link zewnętrzny organizacji The Product Compass
- Branża
- Technologia, informacja i Internet
- Wielkość firmy
- 1 pracownik
- Siedziba główna
- Warsaw
- Rodzaj
- Działalność edukacyjna
- Data założenia
- 2022
- Specjalizacje
- Product Discovery, Product Innovation, Product Strategy, Product Growth i Product Marketing
Lokalizacje
-
Główna
Warsaw, PL
Pracownicy The Product Compass
Aktualizacje
-
Steal my collection of 112 books for PMs: summaries, related YouTube videos, and the authors' social profiles. Recommendations by experience: - Everyone (8) - Product Managers (21) - Senior Product Managers (25) Recommendations by category: - Business and Strategy (17) - Execution (13) - Leadership (15) - Data Analytics (4) - Product Discovery (13) - Experimentation (8) - Product Marketing (11) - Product Growth (8) - Other (34) BONUS: 13 free ebooks as a separate category No email, no paywall: https://lnkd.in/dm3ym_qH
-
I wish all companies lived and breathed by those principles from TRANSFORMED by Marty Cagan. Is that too much to ask? I. PRODUCT TEAM PRINCIPLES: - Empowered with Problems to Solve - Outcomes over Output - Sense of Ownership - Collaboration Selected insight: “The most fundamental of all product concepts is the notion of an empowered, cross-functional product team” II. PRODUCT STRATEGY PRINCIPLES: - Focus - Powered by Insights - Transparency - Placing Bets Selected insight: "Product strategy is all about which problems are the most important to solve" III. PRODUCT DISCOVERY PRINCIPLES: - Minimize Waste - Assess Product Risks - Embrace Rapid Experimentation - Test Ideas Responsibly Selected insight: "The heart of product discovery is rapidly testing product ideas for what the solution could be (…) An experimentation culture not only helps you address risks, but it is absolutely central to innovation." IV. PRODUCT DELIVERY PRINCIPLES: - Small, Frequent, Uncoupled Releases - Instrumentation - Monitoring - Deployment Infrastructure Selected insight: "This means, at a minimum, each product team releases their new work no less than every other week (…) For strong product companies, this means releasing several times per day (...)" V. PRODUCT CULTURE PRINCIPLES: - Principles over Process - Trust over Control - Innovation over Predictability - Learning over Failure Selected insight: "(...) this means moving from hands-on micromanagement to servant-based leadership with active coaching. It means leading with context rather than control." ----- P.S. Enjoy it? A detailed breakdown: - Part 1: Product Team and Strategy: https://lnkd.in/dUMy7KQb - Part 2: Product Discovery, Delivery, and Culture: https://lnkd.in/dDFKSe89 You can also download my 30+ high-quality PM infographics by subscribing here: https://lnkd.in/d5bHGj5j ----- I recommend you read TRANSFORMED: Moving to the Product Operating Model: https://lnkd.in/dUi537Sp
-
90% of PMs use Customer Journey Maps. But most waste 50% of their potential. I was inspired by a conversation with Amy Mitchell, who suggested combining a Customer Journey Map with operating principles such as: - Terms of service - Special requests during pre-sales - Service renewal This approach is easy to understand and can radically: - Improve team collaboration by providing a clear framework - Reduce costs by focusing on high-revenue customers - Improve customer satisfaction with a service Want to dive deeper? Amy has published a free case study in which she presents: - How to integrate a Customer Journey Map with operating principles - Best practices and common mistakes - Free template to download 🎁 No email, no paywall: https://lnkd.in/d_E92vMb
-
User Journey Mapping is essential for product teams. But it's often poorly applied and can lead you astray. Top 7 mistakes and a free template: 1. Guesses instead of data The User Journey Map is worthless without talking to users. How else can you understand what they think and feel? One helpful method is "thinking aloud." Start by defining a series of tasks. Next, ask the first-time user to discuss their thought processes as they interact with your product. 2. Mapping only the top-level phases It's tempting to just focus on the big phases for a neat user story map. But those little steps matter, too. Each one can spark different thoughts and emotions. Balance is key here. 3. Ignoring variations Not every user journey will look the same. For example, before publishing the first product, the user might want to add a custom domain. So try to capture all these different paths. 4. Mapping only the happy path Let's face it: users aren't always happy. If your map only shows sunshine and rainbows, you're missing something. Look out for negative emotions like confusion or frustration. These are important, too. 5. Simplifying emotions We're complex beings. We can feel exhausted, delighted, and worried at the same time. And our emotions can be much richer than emoticons. Name the emotion and consider adding a context to paint a complete picture. 6. Mapping only the current state Mapping the current state is great for spotting the current problems. But don't forget about the future. Map out where you want to be and test your assumptions before the implementation. 7. Not taking action It's disappointing to map out a user journey, find opportunities, and then... nothing. Use what you learn. Otherwise, your insights are just gathering dust. --- Hope that helps. A free template (PPTX): https://lnkd.in/dJeVnGrQ --- If you enjoyed this, subscribe to my newsletter (78K+). You will get 600+ free PM learning resources by email: https://lnkd.in/dns_iaYG
-
In product, it’s essential to test our assumptions. But you can’t test everything. And you can’t test what you’re unaware of. I couldn't find a single assumption prioritization canvas that would: - Focus specifically on prioritizing assumptions - Allow you to use value, usability, viability, and feasibility risks - Work for both Initial and Continuous Product Discovery - Be easy to integrate with RICE/ICE and similar frameworks - Avoid ambiguous labels on the axes So I created a free Assumption Prioritization Canvas. How to use it? - The entire Product Trio must work together - Start with a clear objective, either in pursuit of the Product-Market Fit or a meaningful problem to solve with clear desired outcomes - Explore the problem space (e.g., interviews, data analytics, market research) - Define your knowledge about the specific problems you want to tackle - Ideate on how you can solve those problems and prioritize those ideas - Identify assumptions related to value, usability, viability, and feasibility risks - For a new product, consider the go-to-market risk as a separate category - Focus on testing the riskiest assumption first. As a rule of thumb, conduct 1-2 experiments at a time. Learn from it and repeat. Once there are no more assumptions to test, you can select an idea for implementation - Product Discovery results in a validated product backlog. A free template (Google Drive; use File > Download): https://lnkd.in/dR6BdawZ And in my new free post: - Traditional assumptions mapping techniques and my thoughts - The Assumption Prioritization Canvas in depth - Proven techniques to identify hidden assumptions - Prioritizing assumptions vs. Product Discovery No paywall: https://lnkd.in/dc83WmH3
-
"Outcomes over output" is essential for any PM. But there is no single definition of an outcome. 3 types of outcomes a PM should know about: 1. Business Outcomes They refer to the metrics related to the organization’s goals, for example: - profit margin grew by 5% - churn rate was reduced by 10% Product teams typically cannot influence them directly, so they need to be translated into product outcomes. 2. Product Outcomes At the product level, we may decide that a way to decrease the churn rate (impact a business outcome) is to increase customer engagement, measured, e.g., as the total number of hours customers watch videos every month. In Outcomes over Output, Joshua Seiden argues that these outcomes are always associated with a change in human behavior, for example: - Customers spend 30 min. more watching videos/month - Activation rate is 10% higher More in Teresa Torres's post: https://lnkd.in/dR6JYC-y 3. Customer Outcomes (needs) Customers do not care about the output (features). The three types of customer outcomes, as defined in Product-Led Growth by Wes Bush, are: - Functional outcomes. The core tasks the customer wants to get done. - Emotional outcomes. How do customers want to feel or avoid feeling as a result of using your product? - Social outcomes. How do customers want to be perceived by others by using your product? A similar definition can be found in Jobs to Be Done by Tony Ulwick, in which a “Desired outcome” is defined as: "A metric that customers use to measure the successful execution of a functional job or a consumption chain job. Synonymous with customer need." What I like about JTBD is that the desired outcome is a metric. And there is a way to identify and prioritize those that have the highest potential for the business: Opportunity Score = Importance + Max(Importance-Satisfaction) An alternative way to calculate it from the Lean Product Playbook by Dan Olsen: Opportunity Score = Importance * (1-Satisfaction) --- 4. BONUS: Which outcomes should a product team focus on? In TRANSFORMED, Marty Cagan defines two types of problems the team can be empowered with: customer problems and company problems. And explains that they are accompanied by desired outcomes to achieve. As long your team gets a set of desired outcomes you can directly influence, I encourage you not to obsess over whether those are “changes in human behavior.” In my experience, regardless of the outcomes you focus on, most aspects of Product Discovery remain unaffected. The key is empowering the team with a meaningful problem and clear measures of success. Hope that helps. --- Enjoy this? More information: - [Free] Product Discovery 101: https://lnkd.in/dNUB__n3 - [Free] Product Team Principles: https://lnkd.in/eJ527rpK P.S. Here you can download 30 free high-res PM infographics: https://lnkd.in/d5bHGj5j
-
Product Metrics: The Ultimate Guide (free links): 1. Frameworks: - AARRR (Pirate) Metrics: https://lnkd.in/eQPNqvpC - North Star Framework 101 (12 pages, PDF): https://lnkd.in/dGK9wAKs - Google HEART framework: https://lnkd.in/eAEjiu25 2. Techniques: - Cohort Analysis: https://lnkd.in/eCmx3PCH - Funnel Analysis: https://lnkd.in/earcgtMs - Customer Segmentation: https://lnkd.in/esezNevG 3. Types of metrics: https://lnkd.in/daKCrG-w - Vanity vs. actionable metrics - Qualitative vs. quantitative metrics - Exploratory vs. reporting metrics - Lagging vs. leading metrics 4. What makes a good metric? https://lnkd.in/dnQ7TaxZ - A good metric is understandable - A good metric is comparative - A good metric is a ratio or rate - A good metric is behavior-changing 5. The Ultimate List of Product Metrics (7 pages, PDF): https://lnkd.in/dAkaBEMk - Acquisition Metrics - Activation Metrics - Engagement Metrics - Retention Metrics - Revenue Metrics - Referral Metrics 6. Recommended books: - Lean Analytics by Alistair Croll and Ben Yoskovitz: https://lnkd.in/eyb2FESt - Product Analytics by Joanne Rodrigues: https://lnkd.in/eu2e-WFf - Data Science for Business by Foster Provost and Tom Fawcett: https://lnkd.in/eEB35M4v --- P.S. An interactive mind map: https://lnkd.in/dSycusDk --- Hope that helps. What would you add to the list?
-
Value Proposition is a fundamental term for Product Managers. But it's largely misunderstood. And everyone defines it differently. It doesn't help that the most popular canvas: - Focuses on multiple products - Lumps jobs, pains, and gains without explaining their connections - Doesn't clarify what gain/pain relief each feature addresses - Doesn’t mention existing alternatives or workarounds Recently, Aatir Abdul Rauf and I collaborated to bring some order. A good value proposition defines: 1. Who is the value for: Persona 2. Why is it important: Jobs to be Done 3. What before: Existing, problematic state (e.g., maintaining tasks in Excel) 4. How: Features and capabilities (e.g., Kanban board) 5. What after: The benefits and outcomes (e.g., organized tasks with clear deadlines, increased productivity) 6. Alternatives: your unique value, unique attributes, and optionally relative pricing vs. competitors and substitutes (often represented as a Value Curve). What I loved about this format is that it allows you to tell the story. Value propositions are great alignment tools for PMs, leadership, and cross-functional teams. It’s also an essential part of your product strategy. But remember that designing a value proposition and adjusting your messaging is not a one-time exercise. It’s an ongoing process of learning, iterating, experimenting, and improving based on feedback. Ultimately, you might be able to define a unique value proposition with benefits that are must-haves for specific market segments. If: - Your product solves specific problems way better than alternatives - Your messaging communicates it effectively - You can quickly and easily onboard your customers ("Aha moment") - Your product delivers the benefits promised Your customers will be unable to resist. --- Hope that helps. What are your thoughts? --- Download 25+ high-definition infographics by subscribing (free): https://lnkd.in/d5bHGj5j And here you can read the full post: https://lnkd.in/du9zcZDA
-
I hate the word "requirement" in a PRD. The advice from popular websites on adopting a heavy, waterfall approach only increases my frustration. They insist on documenting every detail: - Requirements - User stories - Acceptance criteria - Data flows - Dates and milestones ...all supposedly crafted solely by the PM. Where to start? The name ”Product Requirements Document” might be misleading. Because it’s not about documenting the “requirements.” Empowered product teams are led with the strategic context, given problems to solve, and are held accountable for the outcomes, not the output (features). They perform product discovery together: explore the problem and solution space, ideate, and run experiments to test their assumptions before the implementation. To product people, writing detailed documents to pass requirements from stakeholders to the product team or from PMs to other members sounds absurd. Of course, some initiatives need to be summarized. But a good PRD is a living document that captures your product discovery journey. It explains why the initiative matters, the objective, and how the success will be measured (key results). It's not a rigid contract. And it shouldn't replace open communication and building alignment. Actually, collaboration is key. And it’s way more important than documentation. --- What do you think about replacing the term PRD with something that better captures its essence? Product Initiative Brief? Product Discovery Canvas? Something else? Share your thoughts in the comments. --- P.S. You can download 25+ high-quality PM infographics by subscribing here: https://lnkd.in/d5bHGj5j More on PRDs & the best PRD template (premium): https://lnkd.in/d-7gXB3y