![\"The](\"https:\/\/bukva.info\/blog\/wp-content\/uploads\/2023\/01\/the-product-book-oblogka.jpg\")
<\/center><\/p>\nWhat is Product Management<\/a> Who is a Product Manager<\/b> The PM job is to provide clear communication between all stakeholders while keeping the end goal\u2014making the customer awesome<\/b>\u2014in everyone\u2019s mind<\/p>\n Customers buy and use products because the products address their needs. Differences between the roles<\/b><\/p>\n The product development lifecycle<\/b> <\/p>\n One of the first things a great product manager should do before even thinking about a product is to understand the company that makes it.<\/b><\/p>\n Why Does the Company Exist? Apple:<\/b> \u201cWith everything we do, we aim to challenge the status quo. We aim to think differently. Our products are user-friendly, beautifully designed, and easy to use. We just happen to make great computers. Want to buy one?\u201d<\/em><\/p>\n Customers will pay for your product because it makes their lives better, not because they want to give you money.<\/p>\n What product are we building? <\/p>\n A persona is a fictional, typical customer, and defining key personas lets you segment your customers by highlighting the things your customers care about that are relevant to your product. Personas are tools to help you understand your customers, they are not actual end customers.<\/p>\n Example:<\/b> A way to envision these customer\u2019s priorities is to imagine the customer\u2019s journey.<\/b> <\/p>\n Focusing on a common problem, pain, or desire yields — is a better segmentation than demographics.<\/p>\n Personas contain demographic information only if it\u2019s relevant. <\/p>\n For example, Airbnb\u2019s \u201chost\u201d personas probably don\u2019t include how much 35 each person makes per year, but they likely do include why a persona is interested in renting her place out.<\/b><\/p>\n Example: That\u2019s a great starting point. But it\u2019s barely the tip of the iceberg. <\/p>\n What persona needs approach<\/b><\/p>\n The goal<\/b> This will help you empathize with that customer, understand his pain points, and think about ways your product can solve that pain.<\/p>\n How to start<\/b> Persona\u2019s template:<\/p>\n Use cases are simply how a company expects each persona to use the company\u2019s product to achieve a goal.<\/b><\/p>\n 1 problem persona wants to solve = 1 feature<\/p>\n Metrics are the measurement of different aspects of your product<\/p>\n Success metrics = key performance indicators (KPIs), are the key metrics that define how we keep score<\/p>\n Success metrics are defined by current strategy and goals. Example:<\/p>\n Phases:<\/p>\n Engagement phase<\/b> Retention phase<\/b> IMPORTANT<\/b><\/span>: Example:<\/b> The bigger the audience you\u2019ve built up on Twitter, the more you\u2019d have to lose by stopping using Twitter and trying to rebuild your audience on another network. <\/p>\n Self-perpetuating<\/b> How to use this approach:<\/b> Types of metrics<\/b><\/p>\n Vanity metrics<\/b> are those that sound useful, and might be great for some other business need, but don\u2019t help us measure product performance.<\/p>\n Example of vanity metric (engagement phase) Actionable metrics are real data we can use to make decisions.<\/b><\/p>\n Now that we know only 10 people completed our product\u2019s core task, we can look at other metrics to try and figure out why so few people were engaged with the app.<\/p>\n The Net Promoter Score (NPS) — measure satisfaction (how likely they recommend)<\/p>\n Roadmap — is a document that shows what the company\/product is doing now, what the company\/product plans to do over the next N months, what the company\/product plans to do later, roughly how much effort each high-level task will take, what products the company will create, and what features they will have, etc.<\/p>\n What\u2019s going on around that company: <\/p>\n 5C analysis<\/p>\n A key part of your role as a product manager is understanding your customers and their problems and needs, and making sure what you\u2019re building next is right for them, be it a feature or a new product.<\/p>\n You have opinions, not facts — Generally, less than 50% of ideas you\u2019ll execute\u2014even awesome ideas\u2014improve the metrics they\u2019re supposed to improve.<\/p>\n customer development, which essentially says that whatever you come up with at first is an opinion; you might be wrong, and you need to interact with real potential customers to learn the truth ASAP<\/b><\/p>\n Great PM needs to help the customer be awesome, and you want to focus your time on building things they need!<\/p>\n How to create the best possible hypothesis about what your customers want<\/b><\/p>\n For example<\/b>, the company might want improved customer satisfaction, which could translate into \u201cgetting customers to read more articles\u201d. OR when Facebook changed the Like button to have different types of reactions, such as love, sadness, and anger. If someone\u2019s dog died it\u2019s better to set a sadness reaction instead \u201clike\u201d<\/p>\n two ways to determine what we want to do to achieve our goal:<\/p>\n Qualitative reasoning — involves more abstract concepts like looking at your overall product vision.<\/p>\n Example: Lyft wants to increase customer retention<\/b>. Quantitative sources are also nice because we can compare the data before and after the change, and determine if it was successful<\/p>\n Quantitative reasoning — involves looking at data, interpreting it, and using that analysis to determine what to do next<\/p>\n Metrics and Analytics<\/p>\n AARRR acronym metrics:<\/p>\n Here are a few common, interesting opportunities you\u2019ll find for mobile and web apps in metrics:<\/p>\n Intercom\u2019 feature audit.<\/b> Analysis methods:<\/p>\n Feature A, with a very low satisfaction, will likely be the first place to focus, instead of Feature B, which is more important but has a moderate satisfaction.<\/p>\n Principles <\/p>\n Feature categories.<\/p>\n In general, the first version of your product needs to cover the basic features. Each successive generation should focus on a mix of satisfiers and delighters, along with making sure you\u2019re continuing to cover the basic features.<\/p>\n To find feature opportunities answer the questions:<\/p>\n Introduction to the problem<\/b> Preparation for solution<\/p>\n To validate hypothesis ideally to build the product. It’s good if it’s about bug fixing or very small part of the product.<\/p>\n In other situation (complex part of the product or major feature) it’s better to use customer development technics:<\/p>\n Also we can build MVP of a new feature (even if we need to do manually the workflow for the first time) and run A\/B test.<\/p>\n Checklist of questions that will help start validating an opportunity:<\/p>\n The model acts as a reminder that your users already have a perspective on the problem you\u2019re solving, a way in which they measure success, and a means by which they work towards that desired state.<\/p>\n CURRENT STATE<\/p>\n MOTIVATION<\/p>\n HINDRANCES<\/p>\n What is the customer development: This includes:<\/p>\n What is NOT a customer development:<\/p>\n Preparing to interviews<\/b><\/p>\n To get started, write down a list of what you know factually and what you\u2019re assuming about our customers, including their needs and how Canvases to explicit opportunity hypothesis:<\/b> MUST VIEW<\/b><\/span>: Template for interviews<\/a><\/p>\n The most valuable thing you can do is to get the customer to tell you about how they currently deal with whatever problem you\u2019re thinking about solving.<\/p>\n Questions example:<\/p>\n Similarly, asking what someone will pay is useless because no one will give you an honest and meaningful answer. But it\u2019s useful to ask what they\u2019ve already paid to try to answer this question.<\/p>\n it\u2019s better to find out about how they deal with the fundamental problem you\u2019re trying to solve. The simplest way to ask a question like this is, \u201cTell me about how you do Important:<\/b> <\/p>\n Logistic<\/b><\/p>\n Where to find interviewees <\/p>\n After all schedule the interview. Write clear instructions how to find you (if on-site) and remind the day before interview start.<\/p>\n Conducting the interviews<\/p>\n Drawing Conclusions from Interviews<\/b> The data surveys provide isn\u2019t as high quality as that from customer interviews, but it\u2019s a low-cost way to see if our conclusions from customer interviews scale to a large number of people.<\/p>\n Executing surveys<\/b> Analyzing Data<\/b> Validate data — what to do with incomplete surveys? (ignore or dig deaper — why users stopped answer)<\/p>\n Portioning data — do you want to do any partitioning based on background questions? (People who listen to streaming music daily may have different answers than people who listen once a week)<\/p>\n In general, like with interviews, you\u2019re still looking for anything that validates or invalidates your opportunity hypothesis. But the other aspect you want to look for with a survey is how many people feel this is a pain point, and how significant of a pain point is it. Try focusing only on data that invalidates your hypothesis before looking for data that validates it.<\/p>\n Experiments<\/b> Different types of MVP:<\/p>\n Values vs cost<\/b><\/p>\n Use an exponential series rather than a linear one\u2014i.e., use 1, 2, 4, 8, and 16 rather than 1 through 5. <\/p>\n Next, for each opportunity, figure out a score using score = value\/cost. Focus on the highest-scoring opportunities first, as they provide the most value for the lowest cost.<\/p>\n Example: Imagine the future.<\/b> Writing an internal product review<\/b> The parts of product that we think will deliver the most value to customer (from internal press release and internal review)- should be built first<\/p>\n Important<\/b><\/span>: minimum is NOT bad<\/p>\n Minimum simply means the fewest buttons or features you need to build to deliver the most important value.<\/p>\n How to come up with MVP<\/b><\/p>\n These are the key sections in a PRD:<\/p>\n Structure of great story:<\/p>\n
\nStrategically understanding the company<\/a>
\nPersona<\/a>
\nUse cases<\/a>
\nMetrics<\/a>
\nHow to choose a right goal for metrics<\/a>
\nHow to measure metrics<\/a>
\nRoadmap<\/a>
\nCreating an opportunity hypothesis<\/a>
\nKano model<\/a>
\nMOOVER.IO\u2019S HYPOTHESIS (EXAMPLE)<\/a>
\nValidating hypotheses<\/a>
\nExternal validation<\/a>
\nCustomer development<\/a>
\nInterviews<\/a>
\nSurveys<\/a>
\nMVP<\/a>
\nHow to prioritize<\/a>
\nFrom idea to action<\/a>
\nDefining a minimum viable product<\/a>
\nProduct requirements document<\/a>
\nBreaking Down a PRD<\/a>
\nUsing a PRD<\/a>
\nExample of PRD<\/a>
\nWorking with design<\/a>
\nThe design process and skills<\/a>
\nUser testing with prototypes<\/a>
\nWorking with design<\/a>
\nDieter Rams\u2019s 10 principles of \u201cgood design\u201d<\/a>
\nDesign Relationship Skills<\/a>
\nWorking with engineering<\/a>
\nProduct\/engineering relationships<\/a>
\nBringing your product to market<\/a>
\nUnderstanding customers<\/a>
\nProduct messaging<\/a>
\nFinding Your Company\u2019s Voice<\/a>
\nPutting the message pieces together<\/a>
\nGoing to market<\/a>
\nGo to market plan (GTM)<\/a>
\n4Ps Framework<\/a>
\nThe Customer Life Cycle<\/a>
\nMOOVER\u2019S GTM PLAN (EXAMPLE)<\/a>
\nFinishing the product-development life cycle<\/a><\/p>\nWhat is Product Management<\/h2>\n
\nProduct manager (PM) represents the customer.<\/p>\n
\nDone properly, the products let the customers be awesome.
\nThe end result of representing the customer is that a PM helps the customer be awesome.<\/b><\/span><\/p>\n![\"The](\"https:\/\/bukva.info\/blog\/wp-content\/uploads\/2023\/01\/the-product-book-01.jpg\")
<\/center><\/p>\n\n
\n
Strategically understanding the company<\/h2>\n
\nMUST WATCH<\/b><\/span>: TED TALK: How Great Leaders Inspire Action<\/a><\/p>\n![\"Why?](\"https:\/\/bukva.info\/blog\/wp-content\/uploads\/2023\/01\/the-product-book-02.jpg\")
<\/center><\/p>\n\n
Persona<\/h3>\n
\nWhen we say, \u201cCan my mom use it?\u201d we\u2019re actually asking if the product is user-friendly enough that someone in the \u201cmom\u201d persona can use the product to achieve a goal without breaking it and without asking for help.<\/p>\n\n
\nOnly demographic approach<\/b>
\nJill\u2014a 23-year-old in a major metro who has a roommate, loves travel, and is very into the DJ scene. Jill is thinking about buying her first car.<\/em><\/p>\n\n
\nUltimately your goal with each persona is to have enough information and detail about that category of customer that you can imagine yourself in this person\u2019s shoes. <\/p>\n
\nJust make your personas rough at first, and as you learn more about your customers, refine the personas, perhaps dividing them up and creating a new persona when key differences appear.<\/p>\n![\"Persona\u2019s](\"https:\/\/bukva.info\/blog\/wp-content\/uploads\/2023\/01\/the-product-book-03.jpg\")
<\/center><\/p>\nUse cases<\/h3>\n
![\"1](\"https:\/\/bukva.info\/blog\/wp-content\/uploads\/2023\/01\/the-product-book-04.jpg\")
<\/center><\/p>\nMetrics<\/h3>\n
\nSuccess metrics are supporting goals.
\nWhen goals change, what was a success metric one week might just be considered a regular metric the next week.<\/p>\n\n
\nIn that case, your product success metrics will include number of downloads of your app, visits to your website, and so on: metrics that indicate people are aware of your company and products.<\/li>\nHow to choose a right goal for metrics<\/h4>\n
\n
\nThe goal is to get customers using your product and completing the core action, like posting a photo to Instagram<\/p>\n
\nThe goal is how frequently those customers use the product in a given time period<\/p>\n
\nProducts that don\u2019t encourage customers to continuously use them are easily replaceable<\/p>\n
\nThe goal is how often people complete loops to be engaged and to engage other people.
\nExample: Pins in Pinterest encourage both new customers to pin something and existing users to return to the product<\/p>\n
\nLook at the number of weekly users completing the core action and the percentage of weekly active users completing the core action over time. This shows growth from the size of the cohort, engagement from the ratio of users completing the core action, and retention from your performance over time.<\/p>\n\n
\nWhen you\u2019re launching a new product, say an app, as a product manager your goal is to have people completing the core task. Maybe 1 million people downloaded your app on the first day\u2014congrats! That sounds awesome, right? While getting someone to be aware of and download your app is the first step, it doesn\u2019t mean they actually opened and used your app\u2014things look very different if only 10 people actually completed your app\u2019s core task.<\/p>\nHow to measure metrics<\/h4>\n
\n
\n
Roadmap<\/h3>\n
\n
\n
\n
\nExample of the business goals:<\/b> to find ways to improve customer satisfaction, and to grow the business.<\/li>\n<\/ul>\n<\/li>\n\n
\n
\n
\n
Creating an opportunity hypothesis<\/h2>\n
\n
\n
\n
\nWe can turn that into a specific product goal by focusing on how to decrease the number of rides cancelled<\/b> — fewer cancellations means more passengers served and happier drivers, which means more payment.
\nThis will also come by tweaking the current product, rather than building something new.
\nWhen you cancel a ride in Lyft, you need to specify a reason. A PM at Lyft could look at the responses and come up with ideas about how to mitigate those reasons. <\/p>\n\n
\n
\n
\n
\nImportant to exclude administrative features like recovery password etc.<\/p>\n![\"A](\"https:\/\/bukva.info\/blog\/wp-content\/uploads\/2023\/01\/the-product-book-05.png\")
<\/center><\/p>\n\n
![\"Analysis](\"https:\/\/bukva.info\/blog\/wp-content\/uploads\/2023\/01\/the-product-book-06.jpg\")
<\/center><\/p>\nKano model<\/h3>\n
\n
\n
\n
MOOVER.IO\u2019S HYPOTHESIS (EXAMPLE)<\/h3>\n
\nThe moving company does a follow-up call to plan details. Based on customer-satisfaction surveys, it has been found that this is the thing that current customers who give the company a lower NPS complain the most about.<\/p>\n\n
Validating hypotheses<\/h2>\n
\n
\n
![\"The](\"https:\/\/bukva.info\/blog\/wp-content\/uploads\/2023\/01\/the-product-book-07.jpg\")
<\/center><\/p>\n\n
\n
\n
External validation<\/h3>\n
\n
Customer development<\/h3>\n
\nIt\u2019s a way to validate if the people you think are your customers truly are the right customers and confirming you\u2019re on the right path. <\/p>\n\n
\n
Interviews<\/h3>\n
\nyour product satisfies them.<\/p>\n
\nI believe that \n
\n
\n
\n
\nIn person is the best, on the phone is easier but without expression emotions, video chat can solve this problem but it depends of customer tech savvy<\/li>\n
\n20 minutes is better<\/li>\n
\n50-100$ per hour is a normal price. A gift, not cash. For some customers, the value will be product improvement + give them early access to a new version of the product (help them feel special)<\/b><\/li>\n<\/ul>\n\n
\n
\nEach interview should help you figure out if your hypothesis addresses a valid pain point the customer has: whether the customer has tried to solve that pain point before, whether the customer cares enough about this pain point to want it fixed, and if there\u2019s nothing that\u2019d stop the customer from using your solution.<\/p>\nSurveys<\/h3>\n
\n
\nTools for creating surveys: Google Forms, SurveyMonkey, Typeform, etc.<\/p>\n
\nRun your survey until you feel you have statistically significant results or until you stop getting new\/useful\/different results.<\/p>\n
\nIf everyone agrees it\u2019s a pain point but no one has spent any time or money trying to solve it, your opportunity is likely not worth building<\/b> unless a solution is very cheap to build or you have reason to believe your solution will make customers realize the pain point is bigger than they thought.<\/p>\n
\nA\/B testing
\nTools for A\/B tests — Optimizely<\/p>\nMVP<\/h3>\n
\n
How to prioritize<\/h3>\n
\nValue = 10, cost = 5, score = 2 — do first
\nValue = 5, cost = 10, score = 0.5 — do second<\/p>\nFrom idea to action<\/h2>\n
\nBefore writing a line of code start writing an internal press release of future product.<\/p>\n\n
\nHeadline:
\nIn one (max 2 sentences, if so, then headline and sub headline): <\/p>\n\n
\nThe first full paragraph in your press release should call out:<\/p>\n\n
\nThe next section should elaborate on the problem and your solution in more detail.<\/p>\n\n
\nInclude a quote from a fictional customer about how the product fits into his life.<\/li>\n\n
\nFocus on what will customer experience with the product:<\/p>\n\n
Defining a minimum viable product<\/h3>\n
\n
\n
\n
Product requirements document<\/h3>\n
Breaking Down a PRD<\/h4>\n
\n
\nUnique code name or something like \u201cMoover Web App\u201d for the first version<\/li>\n
\nWiki tools provide change history automatically<\/li>\n\n
\nList of the most important metrics you will need to be able to measure to figure out if you\u2019ve achieved our goals. Example: increase our user base by 10% (or add ???)<\/li>\n
\nexplain the product to a current or new customer in a short sentence<\/li>\n
\nRough estimates. Ask marketing sales team.<\/li>\n
\ndefine them here so a reader understands what the eventual customers will be like, and their goals.<\/li>\n\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Using a PRD<\/h4>\n