# PMcademy > Six free levels, Apprentice to Principal. Every lesson is a real case and something you build, with AI from lesson one. PMcademy is a free six-level product management course built as a job rather than a syllabus. Every lesson is a scene inside a company and ends with something the learner builds. Site: https://www.pmcademy.com ## Levels - [Level 01, Apprentice: Product Foundations](https://www.pmcademy.com/levels/01): Walk into a company with no product process and produce something useful in your first week. - [Level 02, Practitioner: Discovery & Product-Market Fit](https://www.pmcademy.com/levels/02): Find problems worth solving in a product that already has users, and prove one of them before anyone writes code. - [Level 03, Artisan: Design & Prototyping](https://www.pmcademy.com/levels/03): Design a real interface yourself, critique one without being annoying, and prototype fast enough that arguments end. - [Level 04, Operator: Build & Ship It Yourself](https://www.pmcademy.com/levels/04): Understand how software actually works, answer your own data questions, write a spec an engineer does not have to rewrite, and put a real product on a real URL without waiting for anyone. - [Level 05, Architect: AI Product Management](https://www.pmcademy.com/levels/05): Ship an AI feature you can defend: a versioned prompt, an eval suite that turns “feels better” into a number, a cost per interaction, and an interface designed for the times the model is wrong. - [Level 06, Principal: Launch, Growth & Your Career](https://www.pmcademy.com/levels/06): Get it in front of people, tell the difference between a win and noise, and turn everything you have built into a job. ## Field Notes (blog) Short, practical notes on doing the product manager's job: evidence, metrics, memos and the first week. A new note every Monday by Manish Poduval. Author: Manish Poduval. RSS: https://www.pmcademy.com/blog/feed.xml - [Retention is the one product metric that cannot lie to you](https://www.pmcademy.com/blog/retention-is-the-product-metric-that-cannot-lie): Signups, downloads and daily actives can all be bought. Retention cannot. How to read a retention curve, pick the right interval, and find the moment users decide to stay. - [How to turn app store reviews into product evidence (not a wishlist)](https://www.pmcademy.com/blog/turn-app-store-reviews-into-product-evidence): A practical method for reading app store reviews and support tickets as evidence: keep the original words, extract rather than summarise, cluster by cause, and size before you prioritise. - [Your first week as a product manager, planned day by day](https://www.pmcademy.com/blog/first-week-as-a-product-manager): A day-by-day plan for a new product manager's first week: who to meet, what to read, which numbers to pull, and the one-page memo to have ready by Friday. - [How to become a product manager with no experience](https://www.pmcademy.com/blog/become-a-product-manager-with-no-experience): No PM title, no MBA, no network? Here is what actually gets people hired into product management: a small portfolio of real decisions, written down, built on evidence anyone can check. ## Policy All public pages may be read, indexed and quoted by search engines and AI assistants. Please attribute quotes to PMcademy and link to the page. ## Full text of the notes ### Retention is the one product metric that cannot lie to you Published 2026-10-26 by Manish Poduval. https://www.pmcademy.com/blog/retention-is-the-product-metric-that-cannot-lie The short answer: Retention is the share of people who come back after a given period, and it is the only headline metric that money cannot inflate. You can buy installs, signups and even daily actives with ads and notifications. You cannot buy someone's decision to return on week four. Read it as a curve, not a number: if the curve flattens, something in the product is worth keeping; if it slides to zero, growth spend is filling a leaking bucket. #### Why every other number can be bought A launch week looks wonderful on almost any chart. Downloads jump because a press mention or a paid campaign put the app in front of people. Signups jump because the download screen has a button. Daily active users jump because you sent three push notifications. None of these tell you whether anyone wanted the thing. Retention is different in kind, not in degree. To show up in a week-four retention number a person has to have had a reason to come back three weeks after the campaign stopped nudging them. Nobody can be paid into that. Which is exactly why it is the first number an experienced investor, founder or product lead asks for, and the one a new product manager is least often shown. Margin note: If you can only put one chart on the wall, make it the retention curve and let the vanity numbers live in a spreadsheet. #### Read it as a curve, not a percentage A single retention figure such as "day 30 retention is 22%" hides the shape that matters. Plot it instead: on the x axis the number of days or weeks since a cohort of users first arrived, on the y axis the share of that cohort still active. Every product drops steeply at first, because most people who try anything try it once. The question is what happens after the drop. A curve that flattens into a floor, say 25% of people still around at week eight and still 24% at week twelve, means a group of people have found a lasting use for the product. A curve that keeps sliding toward zero means nobody has, and every new cohort is simply being replaced rather than kept. Two products can both report 22% at day 30 and be in completely different situations. One has flattened at 22% and will keep those users for a year. The other is passing through 22% on its way to 5%. The number is identical. The curve is the whole story. #### Pick the interval the product actually lives on Daily retention is the right lens for a messaging app, where a normal user opens it most days. It is the wrong lens for a tax tool, where a happy user shows up once a quarter and a daily chart will say the product is dying. Before you read any curve, ask how often a satisfied person would naturally use this, then measure on that interval. A simple way to find the interval is to look at your most engaged users and count the gaps between their sessions. If the typical gap is a week, measure weekly retention. If you measure on a shorter interval than the product's real rhythm you will panic over noise. If you measure on a longer one you will miss a problem for months. Margin note: Personal finance apps usually live on a weekly or monthly rhythm. People check their money when it moves, not every morning. #### Find the moment people decide to stay Once the curve has a floor, the interesting question becomes what the people on the floor did that the people who left did not. Compare the first session of retained users with the first session of churned users. Often one specific action separates them: they connected a second account, they finished one full flow, they invited a person, they saw the result of the thing they came for. That action is not a magic trick. It is the point at which the product delivered what the user came to test. Your job is then straightforward: get more new users to that moment sooner, and remove whatever stops them. This is what onboarding work should be in service of. Not a tour, not tooltips, but the shortest path to the moment of proof. #### What retention cannot tell you Retention tells you whether people keep a product. It does not tell you why, and it does not tell you what to build next. A flat curve at 30% with no growth is a loyal product nobody new is finding. A steep curve with huge top of funnel is a product with a marketing engine and a hole. Pair the curve with two things: interviews with people who stayed, and the funnel of how people arrive. It also lags. A change you ship today shows up in the week-four number a month from now. That is why teams who manage by retention also track a leading indicator, usually the share of new users who reach the moment of proof in their first session. That number moves this week and predicts the curve next month. #### Do this week 1. Pull one monthly cohort of new users and plot the share still active each week for twelve weeks. Do not accept a single number. 2. Write down how often a happy user would naturally use the product. Re-plot on that interval if it is not daily. 3. List the five actions most common in the first session of retained users and absent from churned users. Pick the one that is most clearly the product doing its job. 4. Propose one onboarding change that gets more people to that action, and name the leading indicator you will watch for it. #### Questions people ask Q: What is a good retention rate? A: It depends on the interval and the category, so compare curves rather than figures. The useful test is whether the curve flattens. A product whose weekly curve settles above 20% has a core of people who keep it; many consumer products settle lower, many business tools settle far higher. Q: Should I measure daily or weekly retention? A: Measure on the rhythm a satisfied user would naturally use the product. Daily for products people reach for most days, weekly or monthly for products tied to a weekly or monthly task. Q: Can retention be improved with notifications? A: Notifications can lift an active-user count for a while, but if the product does not deliver something people want when they open it, the curve will keep sliding. Improve the moment of proof first, then use notifications to bring people back to it. ### How to turn app store reviews into product evidence (not a wishlist) Published 2026-10-19 by Manish Poduval. https://www.pmcademy.com/blog/turn-app-store-reviews-into-product-evidence The short answer: Reviews become evidence when you stop summarising them and start extracting from them. Copy the user's exact words into a table with a source ID, a date and the app version. Tag each row with the job the person was trying to do and what stopped them. Then cluster by cause, not by vocabulary, and count. Two reviews that both say "login" can describe two unrelated bugs. Done this way, a pile of one-star reviews turns into a ranked, defensible list of problems with numbers attached. #### The trap: reading reviews to form an impression Most people read reviews the way they read a comment thread, scrolling until a feeling forms. The feeling is usually "people are angry about X", where X is whatever the three longest reviews happened to mention. Then X goes into a document as a priority and nobody can say how many people it affects, when it started, or whether it is one problem or three. The fix is a little dull and completely reliable. Treat each review as a record and extract from it. Impressions cannot be checked by a colleague. A table can. #### Keep the original words The first discipline is to copy, not paraphrase. "Can't log in since the update" and "got logged out while paying a bill" both sound like login problems to a tired reader. In the user's own words they are plainly different: one person cannot get in at all after a version change, the other was thrown out mid-task. Paraphrasing merges them. Copying keeps them apart until you have a reason to join them. Give every row a source ID so anyone can go back to the original, and record the date and app version. Half of all "the app is broken" reviews cluster around a single release once you can see the version column. Margin note: A spreadsheet with four columns beats a beautiful summary deck every single time: quote, source, date, version. #### Extraction is not summary Summary compresses. Extraction pulls out specific things in a fixed shape. For each review, extract three fields: the job the person was trying to do, what stopped them, and the words they used for the feeling. "I wanted to pay my electricity bill, the OTP never arrived, I was furious" becomes job: pay a bill; blocker: OTP not delivered; feeling: furious. This is also the right way to use an AI model on reviews. Ask it to summarise and you get a smooth paragraph that sounds true and cannot be verified. Ask it to extract those three fields per review into a table and you get something you can audit row by row, correct, and count. Then spot-check a sample against the originals, because the model will occasionally invent a job the person never mentioned. #### Cluster by cause, not by vocabulary Now group the rows. The temptation is to group by the words people used, because that is what a word cloud does. Resist it. Group by what would have to change in the product for the complaint to disappear. "OTP never arrived" and "OTP arrived after it expired" share a word and may share a cause. "Logged out while paying" and "can't log in after update" share a word and almost certainly do not. A cluster that is real has three properties: the rows describe the same user action, the same point of failure, and roughly the same period. If a cluster fails any of those tests, split it. Splitting is cheap. A wrong merge sends an engineer to fix the wrong thing. #### Count, then size, then prioritise With clean clusters you can finally count. Twenty-three rows about OTP delivery in the last thirty days, all on version 4.2, is a claim you can defend in a room. Three rows about dark mode across two years is also a claim, just a different one. Counting reviews is not the same as sizing the problem, because people who leave reviews are not a sample of people who use the app. So the last step is to go from the review count to a product number: how many bill payments were attempted on 4.2, how many failed at OTP. Reviews tell you where to look. The product data tells you how big it is. Prioritise on the second number and cite the first as how you found it. Margin note: Reviews are a smoke detector, not a thermometer. They tell you there is a fire, not how big it is. #### Do this week 1. Export the last 100 reviews or support tickets for one product into a sheet with quote, source ID, date and version. 2. Extract job, blocker and feeling for every row. Use a model if you like, then spot-check 15 rows by hand. 3. Cluster by cause. Split anything that mixes two user actions or two failure points. 4. For your top cluster, find the product number that sizes it, and write one paragraph that states the problem with both numbers. #### Questions people ask Q: How many reviews do I need before the method is worth it? A: Around fifty gives you clusters you can trust. Below that, still keep the table, because the discipline of copying exact words pays off even with ten rows. Q: Can I use AI to read reviews for me? A: Yes, for extraction into fixed fields, with a hand check on a sample. No, for summaries you intend to act on, because a summary cannot be audited and models will smooth over differences that matter. Q: What about feature requests in reviews? A: Record them the same way, with the job the person was trying to do. A request for dark mode is usually a request about reading in bed, which may have other solutions. Prioritise the job, not the suggested feature. ### Your first week as a product manager, planned day by day Published 2026-10-12 by Manish Poduval. https://www.pmcademy.com/blog/first-week-as-a-product-manager The short answer: Spend the first week producing one small, useful thing rather than absorbing everything. Monday: read the feedback nobody has read. Tuesday: meet the three chairs, engineering, design and whoever owns the number. Wednesday: pull the metric the company actually optimises and its counter metric. Thursday: write a one-page memo with one claim, the evidence and a recommended next step. Friday: deliver it, take the questions, and write down what would change your mind. You will know more about the product than most people in the building by then, and you will have shown how you work. #### Monday: read what nobody has read Every company has a pile of feedback that nobody owns: app store reviews, the support inbox, cancelled-subscription reasons, sales call notes. On your first day, ask for access to all of it and read for three hours. Do not summarise yet. Keep a table of exact quotes with a source and a date. This does two things. It gives you first-hand knowledge that is not filtered through anyone's opinion, and it means that by Tuesday afternoon you can quote real users to people who have been too busy to read them. That is worth more than any onboarding deck. Margin note: Ask for access on Monday morning, not Monday afternoon. Access requests are the slowest thing in any company. #### Tuesday: meet the three chairs Three people shape what you can do: the engineering lead who decides what is feasible this quarter, the designer who decides what the product feels like, and the person who owns the number the company is judged on, often a founder or head of growth. Ask each the same four questions. What is the last thing this team shipped that worked? What is the last thing it cancelled, and who decided? What do you wish someone would look into? What would make your next month easier? Write their answers down verbatim, the same way you did with reviews. You will notice that the three chairs describe three different products. That gap is your job. #### Wednesday: find the number and its counter Ask what number the company would most like to see go up. Then ask what number would tell you that it went up for a bad reason. Revenue with churn. Signups with activation. Session count with task completion. Pull both for the last six months and look at the shape, not the latest value. If nobody can tell you the counter metric, that is a finding, and it belongs in Friday's memo. If the dashboards are broken, that is a finding too. A product manager who cannot get a number should say so plainly rather than guess. #### Thursday: write one page By Thursday you have a table of quotes, three interviews and two charts. Write one page. Not a strategy, not a roadmap: one claim you can defend, the evidence for it, what you would do next, and what you do not yet know. A claim looks like "around a fifth of bill payment attempts on the current version fail at the OTP step, and it started with release 4.2". A wishlist looks like "we should improve login". Keep it to a page because people will read a page. Put the claim in the first sentence. Put the evidence in the next paragraph with the counts. End with the next step and the open questions. Then sleep on it. Margin note: If the page has more than one claim, it has none. Pick the one you can best support and park the rest for week two. #### Friday: deliver it and take the questions Send the page to the three chairs in the morning and ask for fifteen minutes in the afternoon. Expect to be challenged, because you have been there four days. Do not defend the claim beyond what the evidence supports. When someone raises a point you cannot answer, write it down as a question you will go and answer, and say so. The purpose of the meeting is not to win. It is to show the building how you work: from evidence, in writing, with a next step, open to being wrong. People will bring you problems after that, which is the moment the job actually starts. #### Do this week 1. Day one: request access to reviews, support tickets and the analytics tool before lunch. 2. Day two: book the three chairs for thirty minutes each with the same four questions. 3. Day three: pull the company's headline metric and its counter metric for six months. 4. Day four: write a one-page memo with one claim, the evidence, a next step and the open questions. 5. Day five: deliver it, collect the questions you could not answer, and make those the plan for week two. #### Questions people ask Q: What if the company has no product process at all? A: Then this week is the process. A memo written from evidence is the smallest possible version of a product practice, and it is easier to grow one from a working example than to introduce one from a slide. Q: Should I ship anything in the first week? A: No. Shipping in week one usually means shipping someone else's unexamined idea. Learning something true and writing it down is the right first deliverable. Q: What if my manager wants a roadmap by Friday? A: Offer the memo as the first item on it, with the evidence, and explain that the rest of the roadmap will be better in two weeks once you can support it. Most managers prefer a defensible first item to a decorative full list. ### How to become a product manager with no experience Published 2026-10-05 by Manish Poduval. https://www.pmcademy.com/blog/become-a-product-manager-with-no-experience The short answer: You become a product manager by doing product management on something real before anyone gives you the title. Pick a product you can observe, read its users' feedback, find one problem with evidence, write a one-page recommendation, build the smallest version you can and put it on a real URL, then measure what happened. Do that three times and write each one up. That is a portfolio of decisions, which is what hiring managers are actually looking for, and it is worth more than any certificate, including ours. #### What hiring managers are really checking A product manager's job is to make decisions about what to build, with incomplete information, in a way other people will accept. So the only thing an interviewer can really assess is whether you have made such decisions and how you made them. A degree says you can study. A certificate says you can finish a course. Neither shows a decision. This is why people with unusual backgrounds get hired into product roles all the time: support leads, teachers, analysts, engineers, founders of things that failed. They have a story about a problem, evidence, a call they made, and what happened. That story is the interview. Margin note: Interviewers do not want to hear that you are passionate about products. They want to hear what you decided and why. #### Build decisions, not a résumé If the job is decisions, the preparation is making some. You do not need permission, a title or a company. You need a product you can observe closely. That might be an app whose reviews are public, a tool your current team uses and complains about, a small business you can talk to, or something of your own. The sequence is always the same. Read the feedback and keep the exact words. Find a problem that shows up repeatedly and attach a number to it. Write one page that states the problem, the evidence, and what you would do. If you can, build the smallest version of the fix, put it on a real URL, and get five people to use it. Then write down what happened, including when it did not work. Each loop takes a few weeks of evenings. Three loops is a portfolio. It is also the content of every interview you will ever have. #### Learn by doing the job, not by reading about it The product management content industry is enormous, and most of it is frameworks: prioritisation matrices, canvases, five-step processes. Frameworks are fine as vocabulary and useless as preparation, because the hard part of the job is never the framework. It is noticing that two reviews describe different bugs, or that the number everyone celebrates has a counter metric nobody tracks, or that the engineer's estimate was for a different scope than the one on the page. Those are skills of attention, and attention is trained by doing the task with real material and getting feedback. This is the entire design principle behind PMcademy: every lesson is a scene inside a company, with real-looking data, and ends with something you build. It is free, all six levels, because the thing that gets you hired is the work, not the receipt. Margin note: We say this knowing it reads strangely from a course: finish the work and the badge is optional. The work is what you show. #### Use AI the way a working PM does The job now involves a model from the first morning. A good product manager uses it to extract fields from five hundred reviews, draft the first ugly version of a spec, generate test cases for an edge the engineer mentioned, or build a working prototype of a flow before design has time to look at it. A poor one asks it to summarise and pastes the paragraph into a document. Learn the move and the trap for each use. The move is extraction into a table you can audit. The trap is a fluent summary that cannot be checked. Interviewers increasingly ask how you use these tools, and "I asked it to write my PRD" is the wrong answer. #### Get the first conversation With three written loops you have something to send. Do not apply cold with a résumé that says "aspiring product manager". Send the one-page memo from your best loop to a product lead at a company whose product you studied, with two sentences: here is a problem I found in your product, here is what I would do, happy to talk. Some will ignore it. Some will reply, because people who care about a product like hearing from someone who read its reviews more carefully than they did. Associate product manager roles, internal moves from support or analytics, and small companies with a founder doing product badly are the three most common doors. All three open to the same key: a decision you made, written down, with evidence anyone can check. #### Do this week 1. Pick one product you can observe and collect fifty pieces of its user feedback into a table with exact quotes. 2. Find the problem that appears most often and attach one number to it. 3. Write a one-page memo: the problem, the evidence, what you would do next, what you do not know. 4. Share it with one person who works on a product and ask them to poke holes in it. #### Questions people ask Q: Do I need an MBA or a certificate to become a product manager? A: No. Some companies prefer them, most do not require them, and none of them substitute for a written decision with evidence. If you want structured practice, take a course that makes you build things; the course should be the means, not the credential. Q: How long does it take to become a product manager? A: Three written loops of a few weeks each puts most people in a position to have serious conversations in three to six months. The time is spent making decisions on real material, not consuming content. Q: Which background is best for product management? A: Any background that involved deciding things with incomplete information and explaining them to others. Support, analytics, engineering, teaching and founding have all produced strong product managers.