# 1. What's a great product manager? ## Responsibilities of a product manager - [Be a Great Product Leader | Psychohistory](https://adamnash.blog/2011/12/16/be-a-great-product-leader/) 1. **Responsibility #1: Product Strategy** - Quite simply, it’s the product manager’s job to articulate two simple things: - What game are we playing? - How do we keep score? - Clearly describing the game your playing and the metrics you use to judge success allows the team, independent of the product manager, to sort through different ideas and decide which ones are worth acting on. - The result: aligned effort, better motivation, innovative ideas, and products that move the needle. 2. **Responsibility #2: Prioritization** - The question isn’t what is the best list of ideas you can come up with for the business – the question is what are the next three things the team is going to execute on and nail. 3. **Responsibility #3: Execution** - Product managers, in practice, actually do hundreds of different things : QA, PR, design, etc. - However, there are parts of execution that are massively important to the team, and without them, execution becomes extremely inefficient: - Product specification – the necessary level of detail to ensure clarity about what the team is building. - Edge case decisions – very often, unexpected and complicated edge cases come up. Typically, the product manager is on the line to quickly triage those decisions for potentially ramifications to other parts of the product. - Project management – there are always expectations for time / benefit trade-offs with any feature. A lot of these calls end up being forced during a production cycle, and the product manager has to be a couple steps ahead of potential issues to ensure that the final product strikes the right balance of time to market and success in the market. - Analytics – in the end, the team largely depends on the product manager to have run the numbers, and have the detail on what pieces of the feature are critical to hitting the goals for the feature. They also expect the product manager to have a deep understanding of the performance of existing features (and competitor features), if any. - What do product managers do? [Stripe - Product Management.](https://stripe.com/fr/atlas/guides/building-a-great-pm-org) 1. **Product strategy and vision.** - What is the goal of the product? Who is the customer? What are the primary features and use cases? How do we define success and what metrics can we use to track the product? What are the competitive dynamics and how should we position the product against competitors? How will the product differentiate? What are some key distribution channels? What is the business model for the product? How should we price the product? The product manager will work with many other functions (design, marketing, sales, engineering, data science etc.) to answer the questions above, but should ultimately be in charge of asking and answering these questions. 2. **Product prioritization & problem solving.** - Product managers “own” the product roadmap and are responsible for ensuring it has the right set of tradeoffs. Tactical aspects of this include: writing and receiving feedback on PRDs (product requirement documents), organizing/directing product roadmapping sessions, working with all the functions mentioned above, and making tradeoffs on features versus impact and work needed. Crisp product requirements documents can make a world of difference in driving concise agreement on, and execution of, the product. PRDs should clearly articulate primary features and product needs. - However, the ultimate role of product management is making or suggesting tradeoffs between the pristine, platonic ideal of beauty that the design team wants, the technical pizazz engineering desires, the “just give me some shit I can sell” of sales, and the “this may be risky” of legal (these examples are all purposefully exaggerated). 3. **Execution: Timelines, resources, and removal of obstacles.** - As part of driving the success of a product, product managers should work closely with engineering to set and hit goals on time. 4. **Communication and coordination (overlays all of the above).** - Product managers should organize and communicate team status, progress, obstacles, and functional sequencing to the rest of the organization. - Often the hardest part of the communication is communicating the “why” behind the product roadmap, prioritization, and sequencing. Part of this will be creating a framework that establishes why some things are prioritized higher than others – and it’s important that all other functions buy into this framework. - Product managers should also function as the “buffer” or shield that protects engineers and designers from other internal and external parties. Sales and marketing people will always want to meet engineers directly to lobby for their favorite features, while customers will want to have a conversation directly with engineering. - That said, sometimes the best way to convince an engineer of a customer need is to put her in front of a customer. ## Characteristics of Good product managers - [["Good product manager, Bad product Manager", Ben Horowitz, David Weiden (2013).pdf]] - **CEO of the product** - A good product manager acts like and is viewed as CEO of the product. - Bad product managers think of themselves as marketing resources. - Bad product managers have lots of excuses: not enough funding, the engineering manager is an idiot, Microsoft has 10 times as many engineers working on it, I'm overworked, I don't get enough direction. - **Balance all important factors** - Good PMs take all important factors into consideration: Company goals & capabilities / Customer demand / Competition. Know what you know and what you don't know. Think ahead and monitor your assumptions. - Bad product managers miss the big picture or miss small but important factors. - **Clear, written communication with product development** - Good product managers clearly define product requirements -- in writing - Good product managers think their Product Requirements Document (PRD) is a big deal. Good product managers don't rest until they are sure that the product vision is consistent across product management, engineering, QA, tech pubs, and support and is reflected in the PRD. - Bad product managers cut corners on communication with engineering or misunderstand their role. Bad product managers specify the how not the what. - **Clear goals and advantages** - Good product managers have clear goals. - Good product managers know the advantages of their product cold. - Bad product managers have mushy goals and mushy product advantages. Bad product managers hesitate when asked for the advantages of their product. Bad product managers have inconsistent product positioning and advantages change from time to time. - **Focus on the sales force and customers** - Good product managers are loved by the salesforce. Focused on making them money: "Bell Atlantic paid $3m for directory because of abc feature" not "abc allows referential integrity to be maintained across entries." - Knowledgeable of what actually happens in the field -- nothing turns off a salesperson more than a product manager who rambles on about their product features and seems to have no idea of the salesperson's actual situation. - Good product managers know and understand customers. - Bad PMs don't have time for the salesforce or customers. Bad product managers focus on their product and competitors and aren't sure what's going on in the field. Bad product managers delegate working with sales. - **Other key skills** - Marketing & communication - Time management and sense of what's important - Discipline - **Really good product manager** - Be paranoid. Really paranoid. - Work well with executives. - Leverage the entire organization. - Use whatever intensity is required to close critical issues. - Other readings on the subject: - [Good Product Team / Bad Product Team | Silicon Valley Product Group](https://svpg.com/good-product-team-bad-product-team/) - [Ian McAllister's answer to What distinguishes the Top 1% of product managers from the Top 10%? - Quora](https://www.quora.com/Product-Management/What-distinguishes-the-Top-1-of-product-managers-from-the-Top-10/answer/Ian-McAllister) - Characteristics of great product managers [Stripe - Product Management.](https://stripe.com/fr/atlas/guides/building-a-great-pm-org) 1. **Product taste.** - Product taste means having the insights and intuition to understand customer needs for a product in a given area. What product features will wow a customer or meet their core needs? 2. **Ability to prioritize.** - What is the value of a proposed product feature versus the engineering work needed to accomplish it? 3. **Ability to execute.** - A big part of product management is convincing and cajoling teams and different resources to get the product to launch, and then to maintain the product and support the customer base. 4. **Strategic sensibilities.** - How is the industry landscape evolving? How can the product be positioned to make an end run around the competition? 5. **Top 10% communication skills.** 6. **Metrics and data-driven approach.** - You build what you measure. - [Finding and Fostering Great Product Sense - Stay SaaSy](https://blog.staysaasy.com/p/finding-and-fostering-great-product) - **Lots of Good Ideas** - **Structured Product Opinions** - “Developers are expensive; companies will invest in even tiny efficiency gains from AI assistance; AI needs to be integrated into DevOps workflows” vs “AI is exciting; we should make sure that our product has AI in it” - **Non-Linear Solutioning** - For example: “We can skip building a huge project by creating a report that someone will review every month.” - **Easily Testable Solutions** - “After we talked yesterday afternoon, I put together a prototype in the evening and it’s ready to go.” - Other notes - Realize that great product sense is a one way street. You can get someone with great product sense to tweak and optimize a product if necessary (in fact, they’ll likely do this themselves when warranted), but you can’t get an inveterate optimizer to become an inventor. - Pay people with really great product sense very well. Your competition isn’t the same job somewhere else; your competition is them starting their own business or taking your job elsewhere (even if, and perhaps especially if, you’re the CEO). - How to get better - Launch a ton of products – this takes a lot of time and effort, as well as a willingness to fail. - Understand the fundamentals of both business (customer incentives & how companies make money) and technology (what’s possible in your domain) really well. This also takes a ton of time. - Be very open-minded to motivations – for example, if you’re going to build expense management software, you need to be open to empathizing with Procurement teams, which might be completely alien to you. This requires openly admitting that you know basically nothing, and learning about other people’s goals from first principles. ## Types of product managers - The four types of product managers [Stripe - Product Management.](https://stripe.com/fr/atlas/guides/building-a-great-pm-org) 1. **Business product manager** - These product managers are strongest at synthesizing external customer requests into an internal product roadmap. Business PMs tend to thrive at enterprise software companies, or working on the partner-facing portions of consumer applications. 2. **Technical product manager** - Technical PMs are often (but not always) deeply technical people who can work with engineering on areas like infrastructure, search quality, machine learning, or other inward-facing work. 3. **Design product manager** - Most commonly found working on consumer applications, design-centric product managers are more user experience centric. 4. **Growth product manager** - Growth PMs tend to be quantitative, analytical, numbers-driven, and in the best cases wildly creative and aggressive. The focus of the growth PM is to (i) determine the critical levers needed to drive product adoption and use, and then (ii) to manipulate those levers. - In general, the more technical and back-end heavy your product, the fewer product managers you will have. A database company is likely to have a much lower product manager to engineer ratio than a consumer Internet company. - **Not a product manager: Project managers.** - In general, project managers are not needed in high functioning software organizations, where a mix of the engineering manager and product manager will take on project management. Project managers may become useful for hardware products, external partner implementations or vendor-specific hardware integrations. - 3 Types of PM - [3 Types of Product Managers: Builders, Tuners, Innovators | Sachin Rekhi](https://www.sachinrekhi.com/3-types-of-product-managers-builders-tuners-innovators) - **Builders** - The builders are what most people would consider the traditional product manager. As product managers are often seen as defining the what for their product, they are responsible for driving the roadmap for an existing product to build ever more useful, usable, and delightful experiences to serve the needs of their target users. - **Tuners** - The most common example of tuners are the growth PMs that have risen in popularity throughout consumer internet firms and now B2B teams. - **Innovators** - The innovators are the product managers tasked with the incredibly challenging job of finding product/market fit for a brand new product. They are truth seekers that take a hypothesis-driven approach to validate and iterate on practically every dimension of their product strategy, whether it’s target customer, problem their solving, value proposition, product differentiation, go to market, monetization, or more. ## Required skills to be a product manager - [[Shreyas Doshi - PM Skills.jpeg]] - Product sense - Analytical sense - Execution sense - Product vision & strategy - Commercial sense - PM Management - Influential communication - Critical thinking - [[Be a top Product Management 10-30-50.png]] - Need to be top 10/30/50% in each category, no matter in which order - **Analytical sense** - **Execution sense** - **Product sense** - Important skill: Influence Without Authority: [The Most Underrated Product Management Skill:](https://www.sachinrekhi.com/the-most-underrated-product-management-skill-influence-without-authority) 1. **Inspire others to share your vision** - The number one tactic you can use to influence without authority is to get others behind your product vision. 2. **Make their problems your own** - A high degree of empathy is also extremely important for success in influencing others. This involves deeply understanding other’s motivations, their struggles, and their own objectives. And then finding ways to help them address those in alignment with your product goals. 3. **Invest in relationships** - There is no substitute for investing deeply in the relationships of people you work most closely with. ## How to be technical enough? - [Getting to “technical enough” as a product manager | by Lulu Cheng | Medium](https://medium.com/@lulu_cheng/getting-to-technical-enough-as-a-product-manager-5b372513cd1c) - Establish a baseline of technical understanding and invest more over time. - Build trust and credibility by figuring out how you can add immediate value. ## How to become a better PM - [[Becoming a better PM.JPG]] - *"Every Friday, go on ProductHunt. Look at the top 10. Study their marketing, their onboarding, etc. Look at the patterns."* - Great resources - [Top 100 Resources for Product Managers | Sachin Rekhi](https://www.sachinrekhi.com/top-resources-for-product-managers) ## Books to learn Product Management ![[Product Manager - Books.jpeg]] ## Hiring a PM - [The Swiss Army Product Management Team | Stay SaaSy](https://staysaasy.com/product/2022/02/02/the-swiss-army-product-management-team.html) - A Former CEO - A Transfer From Your Engineering Team - A Former Management Consultant - A Former Customer - Someone Who’s Helped Achieve Product/Market Fit - A PM Who’s Worked on a Bottoms-up SaaS Product - A PM Who’s Worked on an Enterprise SaaS Product - A Former Head of Product - A PM from a Top-tier Public Technology Company - A Very Tenured PM - Interviewing PMs [Stripe - Product Management.](https://stripe.com/fr/atlas/guides/building-a-great-pm-org) - Which of the 4 types of product managers are you hiring for? (cf. previously : business, etc.) - + Check for the characteristics for good product managers - Other areas to check: 1. **Product insights.** - What products do you use daily? How would you change X product? How would you design X product for a specific set of users? What features would you add? What would you drop/discontinue? If you were starting a company from scratch, what product would you start with, and why? - For example, how would you design a mobile phone for children? 2. **Contributions to past successful products.** - For example: What role did you play in the product definition and launch? Who came up with which product features? Who drove the idea to price the product X way? Etc. 3. **Prioritization.** - Focus your questions around prioritization on the frameworks the candidate uses for making tradeoffs, rather than the tradeoffs themselves. - For example: What is a real world example where your company had multiple potential product paths to invest in but could not do all of them? How would the PM approach this decision-making choice? What factors would fold into it? What data could be used? What is an example of a product feature that the executive team requested that you pushed back on or had removed? 4. **Communication and team conflicts.** - Have you been able to sell a vision or product to your last company’s leadership team? What disagreements or conflicts did the PM have with engineering or design? How were these disagreements resolved? How does the PM actively build relationships with other parts of the organization? What communication approaches does the PM use? What is important to communicate, and when? What is an example where a miscommunication caused an issue for a product? How was this resolved and what changed from a process perspective after? In general there is a natural tension between product, design, and engineering 5. **Metrics and data.** - What metrics did the PM track for their last product? How did they choose these metrics? What bad behavior could these metrics have driven and how would you avoid this behavior? What metrics would the PM track for your company’s product? Why are those the right metrics? How often and in what context should metrics be reviewed? How do you evaluate if a product launch has been successful? - Reference check all your product hires - Other reads on the subject - [Alex Cohen - My top 5 interview questions and why I ask them - Twitter](https://twitter.com/anothercohen/status/1386103752931758082?s=21) - [How to Hire a Product Manager | Ken Norton](https://www.bringthedonuts.com/essays/productmanager.html) - [Find, Vet and Close the Best Product Managers | First Round Review](https://review.firstround.com/find-vet-and-close-the-best-product-managers-heres-how) ## Joining a team as a new PM / Head of Product - [How to spend your first 90 days](https://giddy-amusement-c74.notion.site/How-to-spend-your-first-90-days-c94c05261548403fa59a45710a953ff2) ## Product Manager Career Map - [Product Manager Career Map Template - Google Drive](https://docs.google.com/spreadsheets/u/0/d/1mFiZN1xNgaD0MijlIrT0R5ELEf2nmAz2f28NQ66m0wQ/htmlview#gid=1656727001) # 2. Product Management - Frameworks ## A. Product vision & strategy ### Inspiration - Best speeches from product leaders: - [Steve Jobs introduces iPhone in 2007 - YouTube](https://www.youtube.com/watch?v=MnrJzXM7a6o) - [LinkedIn Economic Graph | Economic Opportunity - YouTube](https://www.youtube.com/watch?v=M86okhXTwfU) - [Peter Thiel - PayPal Speech](https://en.wikipedia.org/wiki/Peter_Thiel#PayPal) - Great texts from product leaders: - [Amazon - Shareholder letter 1997](http://media.corporate-ir.net/media_files/irol/97/97664/reports/Shareholderletter97.pdf) - [Tesla - The Secret Tesla Motors Master Plan (just between you and me) | Tesla](https://www.tesla.com/blog/secret-tesla-motors-master-plan-just-between-you-and-me) - So, in short, the master plan is: 1. Build sports car 2. Use that money to build an affordable car 3. Use that money to build an even more affordable car 4. While doing above, also provide zero emission electric power generation options - Don't tell anyone. - [Bitcoin - Satoshi Nakamoto - Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - [Slack - We Don’t Sell Saddles Here. The memo below was sent to the team at… | by Stewart Butterfield](https://medium.com/@stewart/we-dont-sell-saddles-here-4c59524d650d#.s97x9xpzr) - Because the best possible way to find product-market fit is to define your own market. - We are unlikely to be able to sell “a group chat system” very well: there are just not enough people shopping for group chat system (and, as pointed out elsewhere, our current fax machine works fine). - What we are selling is not the software product — the set of all the features, in their specific implementation — because there are just not many buyers for this software product. (People buy “software” to address a need they already know they have or perform some specific task they need to perform, whether that is tracking sales contacts or editing video.) - However, if we are selling “a reduction in the cost of communication” or “zero effort knowledge management” or “making better decisions, faster” or “all your team communication, instantly searchable, available wherever you go” or “75% less email” or some other valuable result of adopting Slack, we will find many more buyers. - That’s why what we’re selling is organizational transformation. The software just happens to be the part we’re able to build & ship (and the means for us to get our cut). - We’re selling a reduction in information overload, relief from stress, and a new ability to extract the enormous value of hitherto useless corporate archives. We’re selling better organizations, better teams. That’s a good thing for people to buy and it is a much better thing for us to sell in the long run. We will be successful to the extent that we create better teams. ### Product strategy - Frameworks - Understand the PMF frameworks : [[Iterating & Reaching PMF - Strategy - Frameworks]] - [[Business concepts, Business criteria (Market, Team, Distribution & Product) & Finding ideas]] ### [[Product Positioning]] ### After PMF, Feature/Product Fit - [Feature/Product Fit | Casey Accidental](https://caseyaccidental.com/feature-product-fit/) - Every product team tries to make their core product better over time. But sadly, at most companies, the process for this is launching new features and hoping or assuming they are useful to your existing customers. - This process should be similar to finding product/market fit, but there are some differences. - For product-market fit, you need: - Retention: A portion of your users building a predictable habit around usage of your product - Monetization: The ability at some point in the future to monetize that usage - Acquisition: The combination of the product’s retention and monetization should create a scalable and profitable acquisition strategy - Feature/Product Fit has a similar process. We’ll call this the Feature/Product Fit Checklist: - The feature has to retain users for that specific feature - The feature has to have a scalable way to drive its own adoption - Feature/Product Fit has a third requirement that is a bit different: **the feature has to improve retention, engagement, and/or monetization for the core product.** - What happens when a feature has retention and adoption, but does not increase retention, engagement, or monetization for the company? This means it is cannibalizing another part of the product. This might be okay. As long as those three components do not decrease, shipping the feature might be the right decision. - How does this happen? It’s very simple. The team working on the feature is motivated by feature usage instead of product usage, so they force everyone to try it. This makes the product experience more complicated and distracts from some of the core product areas that have feature/product fit. - Mistakes Feature Teams make searching for feature/product fit - Mistake #1: Email your entire user base about your new feature - Feature emails in my career always perform worse than core product emails. This inferior performance affects the value of the email channel for the entire product, which can decrease overall product retention. - Mistake #2: Put a banner at the top of the product for all users introducing the new feature - New features usually target specific types of users, and are therefore not relevant to all users. - Mistake #3: Launch with a lot of press about the new feature - PR for your feature feels great, but it won’t help you find feature/product fit. PR can be a great tool to reach users after you have tested feature/product fit though. - Many features won’t find feature/product fit - How do I help my feature find Feature/Product Fit? - All features should be launched as experiments that can test for feature/product fit. During this experiment, you want to expose the new feature to just enough people to determine if it can start passing your feature/product fit checklist. - Most good product development starts with a combination of data analysis and user research. - Grubhub - In research, we saw people were having trouble figuring out which restaurants to click on in search results. On the web, they might open up multiple tabs to solve this problem, but this was not possible in the app. - So, we determined what information would help them decide which restaurants were right for them, and started adding that information into the search results page. That included cuisine, estimated delivery time, minimum, star rating, number of ratings. - On the surface, the page now feels cluttered, but this improved conversion rates and retention. - Since Grubhub is a transactional product, we were able to leverage **incentives** as a strategy to help find feature/product fit. Our early data showed that people who started to use the mobile app had double the lifetime value of web users. So, we offered $10 off everyone’s first mobile order. - **The Feature/Product Fit Checklist** - When helping a product find feature/product fit, you should run through this checklist to help your feature succeed: - What is the data telling me about usage of the feature? - What are users telling me about the feature? - How can I use the core product to help drive adoption of the feature? - How can I use notifications to help drive adoption of the feature? - How can I use incentives to help drive adoption of the feature? - How can I use people to help drive adoption of the feature? - When confirming feature/product fit, you need to ask: - Is the feature showing retention? - What type of user(s) is retaining usage of the feature? - How do I limit exposure to only those users? - What is the scalable adoption strategy for the feature for those users? - How is this feature driving retention, engagement, or monetization **for the overall product**? ### Make a simpler product ![[Paul Graham - Making a simple product.JPG]] ![[Simplify the product to sell more - David Sacks.JPG]] ### Time to value & Onboarding : Craft a good first mile - [Crafting The First Mile Of Product | by Scott Belsky | Positive Slope | Medium](https://medium.com/positiveslope/crafting-the-first-mile-of-product-7ed25e8f1027#.lyr6c0qhu) - In the early days of Behance, the immediate utility was presenting your portfolio online. If we didn’t execute this well, nobody would have stuck around long enough to experience the benefits of the networking and marketplace components. - [[Sales & Product - Customer Onboarding]] ### Advice from Patric Campbell - Pricing, Retention & Types of product (workflows vs anti-usage products) [[Pricing Playbook - How to price your product]] [[Management Playbook - How to be a better CEO]] - 2023-03 Podcast - Patrick Campbell (founder of ProfitWell, bootstrapped to 20M revenue and sold for 200M recently) on Lenny’s podcasts - **Pricing** - Increase your price every year - Do a review of your pricing every 3 months - Pricing is as important as acquisition and retention. There 3 of them make your business. - **Pricing on a Value metric** - It decreases churn (instead of a full churn, just a plan downgrade) - And accelerate expansion (it’s easier to expand seats or usage, than selling new features to customers which classically requires a new sale) - **Retention, there a two types:** - Strategic retention: product features, etc - Tactical retention: credit card expiration, reminding the customer about what he likes about the product, etc. Usually 25-40% of churn. Usually product team don’t spend enough time here and only focus on strategic retention. That’s why it’s better if it’s tracked by the finance team to improve tactical retention - **Two types of products that works:** - The **workflows products** that you have to use everyday or mostly everyday (note: GSuite, Front, Slack, etc.) - Or the **anti-usage products** that you get the value from without logging. Like Stripe. Those have the lowest churn rates and highest expansions. - **Everything in the middle is the Death Valley**. That’s why it’s so hard to build an analytics SaaS business, because you don’t need to log on it everyday. - **People/Management** - Good people ship whatever team they work on (HR, tech, sales, CS, etc.) - You should tell everyone what good looks like for each type of role, what is the good tempo/cadence. Otherwise you have misalignment, and then you have to fire them months later because they don’t ship. - You should have a way to remind the teams regularly what good looks like. ### Psychological principles applied to product design - [20 psychological principles applied to product design | by Lucas Didier | UX Collective](https://uxdesign.cc/20-examples-of-psychological-principles-applied-to-product-design-a0d3ecaeb214) 1. **Social proof** - “_We tend to follow the patterns of similar others in new or unfamiliar situations._” - Pricing plan: You’ll often see a “Most popular” label associated with the more expensive option, and sometimes a few customers testimonials in order to convince you to finally buy the product or service. 2. **Curiosity** - _“When teased with a small bit of interesting information, people will want to know more!”_ - Another industry heavily relies on curiosity to generate subscribers and thus revenue: news. We’re all used to articles ending unexpectedly with this annoying fade inviting you to subscribe to read the full story. 3. **Recognition over Recall** - _“It’s easier to recognize things we have previously experienced than it is to recall them from memory.”_ - That’s why the insurance startup Lemonade suggests several pre-defined categories of high value items. This makes it much easier for users to remember which items they own might potentially be worth a lot of money. 4. **Delighters** - _“We remember and respond favourably to small, unexpected and playful pleasures.”_ - As an example, the location sharing app Zenly sends lots of compliments (“You’re probably the best looking user we have”) and easter eggs (showing ski slopes on its map) to its users, which makes it one of the most loved apps on social media. 5. **Anchoring & Adjustment** - _“When making decisions, we rely too heavily — or anchor — on one trait or piece of information.”_ - The same approach goes for donations to charities when you’re paying your $150 groceries at the cashier. Will it really change anything if you’re adding $0.50 to that amount? 6. **Appropriate challenges** - _“We delight in challenges, especially ones that strike a balance between overwhelming and boring.”_ - That’s why the language learning app Duolingo starts with a placement test, in order to make sure you start lessons that are appropriate to your level and you don’t drop from the first lesson because you’re bored. 7. **Aesthetic-Usability Effect** - _“Aesthetically pleasing designs are often perceived as being easier to use.”_ 8. **Value Attribution** - _“We value things when they cost more.”_ - Cost can be monetary or just an investment of time. - In their book “It Doesn’t Have To Be Crazy At Work”, Jason Fried and DHH talk about how increasing the entry price of Basecamp from $29 to $99 a month enabled them to attract new customers. 9. **Loss aversion** - *“We hate losing or letting go of what we have (even if more could be had).”* - A good example of how this psychological insight is applied can be seen on the cancellation flows of many subscription-based services. - Loss aversion is also heavily used in freemium subscription apps (to convert from free trial to premium subscription). 10. **Contrast** - _“When scanning new visual information, we are unconsciously drawn to things that stand out against their surroundings.”_ 11. **Periodic Events** - _“Recurring events create sustained interest, anticipation and a sense of belonging.”_ - That’s why Headspace implemented a “group meditation”: everyday, at a fixed time, all Headspace premium users get to connect and meditate together 12. **Sequencing** - _“We are more likely to take action when complex activities are broken down into smaller tasks.”_ - Several products have managed to break down complex flows into seamless and quick experiences. For instance, Airbnb’s publication flow or TransferWise’s money transfer flow. 13. **Limited Choice** - _“We’re more likely to make a choice when there are fewer options.”_ - The same goes for the French health insurance Alan, who took a complete opposite approach vs. traditional health insurances, where the pricing model is usually very obscure and complex. With Alan, there’s only one offer, and it’s only calculated based on your age. 14. **Reputation** - _“We care more deeply about personal behaviors when they may affect how peers or the public perceive us.”_ - Reddit and StackOverflow are two examples of products heavily relying on reputation. 15. **Authority** - _“We want to follow the lead and advice of a legitimate authority.”_ - AirHelp add some elements justifying its authority on their request flow: (1) The mention of the “EU regulation EC261” ; (2) A human presence, “Jane — Your AirHelp Assistant” 16. **Limited Access** - _“We naturally desire things that are perceived as exclusive or belonging to a select few.”_ - Hypes can be currently observed around Superhuman and Clubhouse. 17. **Self-Expression** - _"People seek opportunities to express their personality, feelings or ideas."_ - A lot of apps that target teenagers almost always offer their users to customize their profile with a color, an avatar, cool accessories, etc. I’m thinking of Pokémon Go, Snap (with the Bitmoji) and more recently of Stadium Live. - Other example in SaaS tools can also be found: Trello enables its users to change the background color/image, Slack provides lots of themes to customize its interface. 18. **Scarcity** - _“We infer value in something that has limited availability or is promoted as being scarce.”_ - The absolute specialist of this principle is Booking.com. When you browse hotels on their search results page, it’s not uncommon to find several visual clues indicating scarcity. 19. **Humor Effect** - _“Humorous items are more easily remembered — and enjoyed!.”_ 20. **Variable Rewards** - _“Random rewards make powerful motivators; they seem scarce and unpredictable (and they’re less likely to conflict with intrinsic motivation).”_ - One of the things that has made Snapchat so exciting to its users is its “trophy case”. - B2C-specific - Product behavior - Instagram: The more you make progress and feel good, the more you want to engage - Usage spike on instagram after someone posted something: seeing who saw and reacted to your post is more important than just posting. It fuels the usage ## B. Understanding users' problems ### User research & Jobs to be done - [[Customer Interviews & PMF Hypotheses]] - Getting better at user research: [UX Design Challenges | UX Tools](https://uxtools.co/challenges/) - [[Jobs to be done - Framework]] ### Empathy Maps - [10 Tips to Develop Better Empathy Maps | Adobe XD Ideas](https://xd.adobe.com/ideas/process/user-research/10-tips-develop-better-empathy-maps/) - A typical empathy map includes four quadrants: - **Say** – What the user says about the product. Ideally, this section contains real quotes from users recorded during interviews or user testing sessions. - **Think** – What is the user thinking about when interacting with a product? What occupies the user’s thoughts? What matters to the user? - **Feel** – This section contains information about the user’s emotional state. What worries the user? What does the user get excited about? How does the user feel about the experience? - **Do** – What actions does the user take? What actions and behaviors did you notice? - Empathy mapping is not a replacement to journey mapping. - [What is an Empathy Map? - YouTube](https://www.youtube.com/watch?v=QwF9a56WFWA&ab_channel=PlaybookUX) ### Journey Mapping - [An Introduction to User Journey Map + PDF Templates by Stéphanie Walter - UX designer & Mobile Expert.](https://stephaniewalter.design/blog/an-introduction-to-user-journey-map-pdf-templates) #### Process mapping & Flow charts - [Cawemo - Cloud BPMN](https://cawemo.com/) - [diagrams.net](https://app.diagrams.net/) - Miro: white board ### Avoid the Focusing illusion (Customer Problems Stack Rank) & Break out of the Product Death Cycle ![[Avoid the Focusing illusion (Customer Problems Stack Rank) & Break out of the Product Death Cycle]] ### Understand user behavior to build a better product [The Irrational Truths of User Behavior, with Dan Ariely](https://www.nfx.com/post/irrational-truths-behind-user-behavior/) > I want to create interfaces that motivate first, then help people understand cause and effect, and then are accurate. > It’s all about the perspective of thinking about all the little details. > Two Questions To Determine A Strong Business Model : >1. “What is causing people to… ?”: What are you assuming about your users? What is motivating them? What is causing them to want something versus something else? >2. Test: What’s the friction and what’s the motivation?: Basically, go very slowly through the experience with your product, and at each point, ask yourself, what’s the friction and what’s the motivation. What is holding people back and what would give them extra motivation? >--- >When we design products, we often think that people care about the things we care about. We think: Here I have this new product. People would probably read the manual. I want to lose weight and people after all want to control their diabetes but the reality is that people have very little time and very little attention and if we design with that in mind, I think we’ll make much more progress. ## C. Execution: How to ship software? ### The right way [The Right Way to Ship Software | First Round Review](https://firstround.com/review/the-right-way-to-ship-software/) - My fellow engineers, please stop asking “Is this process good or bad?” and start asking “Is it well-suited to my situation?” - **First, Take a Look at Who the Customer Is** - Chances are, if you sell software at a high price tag, you are selling to businesses that are buying your software based on their need. The more expensive your software is, the more mission critical it is for your customers, the more likely you have to optimize for reliability, functionality and a predictable schedule. - As a rule of thumb, expensive software means predictability is key while shipping. Customers need your product. If you have a lower (or no) price tag, focus on UX. Users who don’t need your product have to want it. - **Next, Assess How You Deploy and How Much You’re Willing to Risk** - Facebook’s struggle pivoting to mobile illustrates the potential for trouble. Facebook’s speedy, individualistic and iterative way of designing and shipping software was deeply embedded in product team culture. - As the company’s focus shifted to native mobile apps, the engineers hired for their mobile expertise insisted on a heretofore unknown process like feature and UI freeze, functional specs and QA. - As a rule, startups should be aggressive risk takers, for entirely rational reasons. When you have no customers, revenue or brand, the impact of a mistake is immaterial. You had nothing before, you have nothing afterwards. So who cares? But once you have customers, you have to define the cost of a mistake in terms of the pain you cause. Similar kinds of operational mistakes might cause a 5% decline in growth rate for one startup and a 75% decline for another, based on different business and deployment models. If that’s the case, those founders had better be running those companies differently. - In Twitter’s early years, service outages were so common, users coined the term “fail whale” (inspired by the graphic on Twitter’s outage page) as a shorthand for “yet another outage.” The fail whale was ultimately not fatal in Twitter’s business because users patiently gave them a long time to fix it. Yes, we cracked a lot of jokes, but we didn’t leave the service. Imagine if instead a company like Salesforce had a “fail whale” problem. - So a consumer business can afford a lot more risk than an enterprise software business. - **How You Ship is One Strand of Your Cultural DNA** - Your company’s mission and values are immutable. Your team hopefully can agree that what ultimately matters is to ship the best product for your users, and that what remains is negotiable. ### Agile isn't done right: resource allocation, mutable requirements & uphill strategies - [Running in Circles - Signal v. Noise](https://m.signalvnoise.com/running-in-circles/) - Agile became synonymous with speed. Everybody wants more, faster. And one thing most teams aren’t doing fast enough is shipping. So cycles became “sprints” and the metric of success, “velocity.” - But speed isn’t the problem. And cycles alone don’t help you ship. The problems are doing the wrong things, building to specs, and getting distracted. - **Deliberate resource allocation** - Designers and developers can’t make progress if people constantly pull at their attention. It doesn’t matter if support finds a bug or sales needs a new feature. Allocating resources means dedicating resources - **Mutable requirements** - If a team works to a spec, there’s no point in iterating. The purpose of working iteratively is to change direction as you go. Defining the project in advance forces the team into a waterfall process. - **Uphill strategies** - Teams that track “velocity” and “story points” treat development as if it’s linear labor. Software development is not like moving a pile of stones. - Work that requires problem solving is more like a hill. There’s an uphill phase where you figure out what you’re doing. Then when you get to the top you can see down the other side and what it’ll take to finish. - The most important question for a team isn’t “what is left?” but “what is unknown?” Can you see the edges? Have you gone in there and seen everything that needs to change? - The uphill work is where you learn what’s hard and what’s possible and make value judgements. Here’s where you make decisions about those mutable requirements because you’re seeing the real costs and opportunities in the implementation. Learning uphill requires the focus and time given to the teams by deliberately allocated resources. - **It takes a whole business to ship** - Whether teams work in cycles or not is just one part of the story. An “agile” team isn’t going to get very far if management doesn’t protect their time. And if they don’t have flexibility to change requirements as they learn, late nights and late delivery are guaranteed. ### Build or Buy - [Why is it so hard to buy things that work well?](https://danluu.com/nothing-works/) - Joel Spolsky has an old post where he says: “Find the dependencies — and eliminate them.” When you're working on a really, really good team with great programmers, everybody else's code, frankly, is bug-infested garbage, and nobody else knows how to ship on time. - Most markets are like this, except that there was never an unreasonable firm like Volvo in the first place. On unreasonable employees, Yossi says - Who can, and sometimes does, un-rot the fish from the bottom? An insane employee. Someone who finds the forks, crashes, etc. a personal offence, and will repeatedly risk annoying management by fighting to stop these things. Especially someone who spends their own political capital, hard earned doing things management truly values, on doing work they don't truly value – such a person can keep fighting for a long time. Some people manage to make a career out of it by persisting until management truly changes their mind and rewards them. Whatever the odds of that, the average person cannot comprehend the motivation of someone attempting such a feat. - It's rare that people are willing to expend a significant amount of personal capital to do the right thing, whatever that means to someone, but it's even rarer that the leadership of a firm will make that choice and spend down the firm's capital to do the right thing. - If you can't trust other firms, you frequently don't have a choice with respect to bringing things in house if you want them to work. ### Priorization: Only doing the top item on the list - [How To Do Less](https://alexturek.com/2022-03-07-How-to-do-less/) - **There are two loose definitions of prioritization.** - **Prioritization(1):** Ordering a todo list. You make a giant list of things you could do, things you should do, things you’d like to do… and then you put a unique number next to each item. Now it’s an ordered list. - **Prioritization(2):** Only doing the top item on the list. You already have a giant todo list. Which thing are you actually going to finish? - **Make and broadcast cuts** 1. Keep the lights on, and make keeping them on cheaper. This work is arguably more important than any new features - make sure you message it that way. It’s glorious work, because that lead is maintaining something that is already valuable today. 2. Cut the entire roadmap of new features down to one thing at a time. Take the entire list of WIP, and get ready to drop almost all of it. I know you’re dropping critical things - we’ve established that you’ve already dropped every P2+. Now it’s time to cut the P1s. - So now, you’ve committed to a big, one-time effort of saying No to everybody. - **Stay out of the trap** - How do you avoid “WIP creep”, and falling back into the trap? - Say No, early and often - Copy/paste: How to Say No - Here are some concrete ways to tell management or stakeholders no. > This isn’t MAIN_PRIORITY, so we aren’t going to do it until at least ESTIMATED_DONE_DATE. > Right now our priority is MAIN_PRIORITY because of ONE_SENTENCE_JUSTIFICATION, and this is 100% our shipping focus. > I agree this sounds like a really useful feature - once we finish MAIN_PRIORITY, should we consider dropping SECOND_PRIORITY and do it? - Copy/paste: How to correct distractions > Here are some concrete ways to challenge distractions. > This isn’t MAIN_PRIORITY, that we all said we’re going to work on. > What if we don’t do this? What can we do without it? > Is this a requirement or a nice to have? Will it speed up MAIN_PRIORITY? > Can we put this onto our (New Feature/Maintenance) Roadmap after our current priority finishes? > I think we can finish MAIN_PRIORITY without this. - **Maintaining flexibility** - Here’s the thing: an early stage startup is just a future company that might get customer traction and take off. - You have these things in tension: - Iterate: You need to try some stuff with the product, to see if customers care about it. - Invest: There’s a reasonable chance that this hack you’re about to ship causes an entire team to be mad at you in 6 months. - The only way I’ve found to handle that tension is in a small org is to be all in on one mode or the other. Default to Iterate, but be willing to Invest, maximizing how many people can work on the investments until they’re done. - After enough iterating, you’ll identify the real investment areas that are critical. These are areas that cause high amount of distractions while iterating, and act as constant drag. When you’re nearing the end of Invest mode, you can start getting ready to Iterate again. A fun bonus benefit is that the product roadmap will probably have significantly changed due to customer discovery, so you may not have lost that much time. - [How to choose your Product Prioritization Framework | by Andrew Quan | UX Collective](https://uxdesign.cc/how-to-choose-your-product-prioritization-framework-ff0320d63ebf) ### Checklist - How to solve product problems 1. **LISTEN & ASK QUESTIONS**: One of the key traits of a product leader is his/her ability to listen carefully. With customers, colleagues, bosses, you need to work on your empathetic skills to understand where people come from and where they want to go. 2. **LEARN THE FUNDAMENTALS**: Without the right words, you won’t convince a lot of people. Learning the psychology behind product decisions is paramount to becoming a great product leader. 3. **CLARIFY THE PROBLEMS YOU’RE SOLVING**: The best way to keep a conversation on topic, is to go back to the core problem: Can the team agree on what you’re trying to solve? 4. **TALK TO CUSTOMERS**: The truth is always outside the building. Spreadsheets won’t question your decisions; people will. 5. **LEARN TO GIVE CONSTRUCTIVE FEEDBACK**: Lead by example as they say. It’s even more important while giving feedback to peers. Important to highlight the good and the bad, and ask questions (#1). 6. **LEARN TO SAY NO**: Not all ideas are good. Focus on the core problem, filter the rest. 7. **TEST, TEST, TEST**: Nobody nails the best solution on their first try. You need to nurture a place where it’s okay to fail at first, but as long as you iterate and learn, then you’re on the right path. ### Write better product specs - [On Writing Product Specs. If you’re a PM at a medium-to-large… | by Gaurav Oberoi | Gaurav Oberoi](https://goberoi.com/on-writing-product-specs-5ca697b992fd#.ysztdkv5p) - [Read example notes. (2 min read)](https://docs.google.com/document/d/1lGUTukK0b5Jp-nikMl7yBUaDxKVpgj77tUn4UF-vsaU/edit?usp=sharing) - [Read the example spec. (6 mins)](https://docs.google.com/document/d/1MU-fo5FlBbcz3R-Eg38lFtcAr5s_k2ynpd9ew0aButs/edit?usp=sharing) - Why write a spec? 1. Do critical thinking up front 2. Communicate efficiently 3. Raise accountability - What should a spec contain? 1. The Problem 2. Measurable Goals 3. Context. Provide evidence that your audience needs to understand the problem and believe in your proposal. Assumptions, use-cases, metrics, etc. 4. Detailed Solution 5. Timeline - How to write a spec? 1. Write a quick draft (1–2 hours) 2. Setup a couple of 30 minute 1–1 meetings (1–4 hours). - The aim is to work through assumptions, improve your proposal, and get buy in. Keep these meetings tiny and focused with as few people in the room as possible (ideally 1–1s). 3. Write and edit the spec(0.5–3 days) 4. Publish and setup a 1 hour review (15 minutes). - Send a wide email with your stakeholders on the “to” line, and other interested parties on the “cc” line (e.g. your product team, the broader support org). Follow up with a meeting invite for key people: those who will do the work, and those who have veto/approval authority. 5. Review the spec (1 hour) - Start your spec review meeting by asking who has not read the spec in detail. There will usually be 1 or 2, in which case, say “no worries, let’s take 10 minutes to read the spec, if you have read it already, feel free to take a break”. Use this meeting to get sign off from stakeholders and get understanding and commitments from the doers (Dev, Support). You may need to revise and repeat this step based on what you learn. 6. After the review, send an update and file tickets (1–2 hours) - Often, the next major step will be for an engineer to write a tech spec, but not always (my example doesn’t need it). - What are some pro-tips for writing an effective product spec? 1. Keep it short 2. Use plain English and simple formatting. Use bullets and bold styling to make it easy to scan your doc. Write in a casual style, and make it interesting. Use humor if you can. 3. Stay ahead of your dev team - A completed spec is one that has been reviewed and generally agreed upon. If you’re hoping to slot in work into a future sprint, make sure you start this process 2–3 weeks before. 4. Think like an engineer - A lot of edge cases appear when one finally sits down to write code — but that doesn’t have to be the case. 5. Bring everyone on the journey 6. Work hard on images - Like flow diagrams, or wireframes. They can convey huge amounts of info in an easily digestible manner, but can also take lots of time to make. 7. Spend 0.5 to 3 days thinking and writing 8. Set direction and point at the vision - You’re not just defining this one feature, but you’re also providing context on why we’re doing this and where we’re going. 9. Make sure your Audience reads it - If your spec is too long, confusing, or just not shared with the right people, you might as well not write it. 10. Get honest feedback - Are your specs specifying the obvious? Or don’t have enough detail? Are we finding too many edge cases later on? Or are we spending too much time in planning/review? Ask your team. - [What Is A Product Spec? 10 Components Of A Great Product Spec — Reforge](https://www.reforge.com/previews/product/how-to-write-product-specs) - Product specs, or specifications, are written documents that communicate what, why, and how a product or feature should be built. - **All product specs should provide three types of information:** 1. Context on why the team is building the feature. - Product specs are primarily meant to be straightforward, informational documents, but it’s actually pretty easy to create a product spec that is either too vague or too prescriptive. 2. Implementation guidance on how it should be built. 3. FAQ section that answers obvious questions that stakeholders might have. - **5 Key Contextualizing Components Of A Product Spec** 1. Opportunity 2. Target Audience 3. Customer Insights 4. Competitive Insights 5. Success Metrics - **5 Key Implementation Components Of A Product Spec** 6. Scope 7. Experience 8. Implementation Details 9. Launch Plan 10. Investigative Metrics - Why Product Specs Need An FAQ Section ### PRD Template - [kevinyien: PRD Template](https://docs.google.com/document/u/0/d/1mEMDcHmtQ6twzNlpvF-9maNlAcezpWDtCnyIqWkODZs/mobilebasic) ### Agreed Target Quality Framework - Very effective for proactively & rigorously addressing Eng/Design/PM conflict when building a product. - Instead of litigating 100s of details just before launch, discuss upfront the quality level you are aiming for (and why) ![[Agreed Target Quality Framework.png]] ### Ship products in Enterprise - [EnterpriseReady - Build SaaS Features Enterprises Love](https://www.enterpriseready.io/) ## D. Measure: Product analytics/metrics ### NPS as a core metric - [A Practitioner's Guide to Net Promoter Score at andrewchen](https://andrewchen.co/a-practitioners-guide-to-net-promoter-score/) - [The #1 Reason SaaS Companies Stall Out at $15m-$20m ARR | SaaStr](https://www.saastr.com/why-i-think-saas-companies-stall-out-at-20m-arr/) ### Tools - Product analytics #### Heatmaps, Conversion Funnels & Visitor recordings - [FullStory | Pixel-Perfect Session Replay](https://www.fullstory.com/) - Open-source alternative to FullStory or HotJar: [Microsoft Clarity - Free Heatmaps & Session Recordings](https://clarity.microsoft.com/) - [Amplitude | Product Intelligence for Web and Mobile](https://amplitude.com/) - [SumoMe](http://sumome.com/) #### Feedbacks - [Doorbell.io - Gather in-app user feedback, simply, across multiple platforms, for free!](https://doorbell.io/) # 3. Managing Product Managers & Techs [[Managing Product Managers & Techs]] ![[Managing Product Managers & Techs]]