Work backwards from the four things PM interviews actually test: product sense (design/improvement questions), execution (metrics and prioritisation), analytical thinking (guesstimates, root-cause), and behavioural rounds. A practical plan is 3–4 weeks: week one to learn one framework per category, weeks two and three to practise daily out loud (not just reading), and the final week for mock interviews plus deep research on the company's product, recent launches, and the metrics they care about. Keep a running notes doc with your metric definitions and 5–6 personal stories written in STAR format.

Candidates who convert offers don't necessarily know more — they answer with more structure. Clarify the question before answering, state your assumptions, lay out your approach top-down, quantify with metrics, and close with a clear recommendation and its trade-offs. Most people fail not on knowledge but on rambling, so 2–3 mock interviews with honest feedback make a bigger difference than another week of reading. Also prepare a sharp "why product management" and "why this company" narrative, because interviewers probe motivation in almost every process.

Expect 3–5 rounds spread over 2–5 weeks. A typical flow is a recruiter or hiring manager screen, followed by a product sense round ("improve X" or "design Y"), an execution or analytics round (metrics, prioritisation, diagnosing a metric drop), sometimes a guesstimate round, and a behavioural or HR round. In India, startups often add a take-home assignment or a live case with a founder, while larger MNCs lean heavily on structured frameworks. Senior rounds may include a strategy discussion, like whether the company should enter a new market.

Never jump straight into a solution. Start by clarifying scope and constraints, define the users and the goal, then present a structured answer: your framework, your assumptions, quantified reasoning, options considered, and a prioritised recommendation with trade-offs. For behavioural questions, use one tight story per theme with a measurable outcome. Interviewers are scoring your thinking process, so thinking aloud in a clean structure matters more than landing on the "right" answer.

The questions fall into six buckets: product design ("design an app for X"), product improvement ("how would you improve Swiggy or Paytm?"), metrics ("define success metrics for YouTube"), guesstimates ("how many cups of chai are sold in Mumbai daily?"), product strategy ("should X launch Y?"), and behavioural questions on conflict, failure, and prioritisation. Instead of memorising answers, learn one repeatable structure per bucket and adapt it. A strong answer always states the user and goal first, uses numbers, and ends with a decision — weak answers hedge or list features without prioritising.

For freshers and APM roles, the bar on "experience with metrics you owned" is lower, so interviewers lean on guesstimates, basic product design questions, aptitude or SQL in some companies, and a lot of behavioural probing — especially "why PM instead of engineering or analytics?" Expect questions built around your internships, college projects, or any app you've built, so reframe those in product language: users, problem, decisions, outcome. Preparing 2–3 product teardowns and a small case study gives freshers something concrete to steer the conversation towards.

Three books cover most of the ground: Cracking the PM Interview for the overall process and role expectations, Decode and Conquer for answer frameworks you can practise against, and Swipe to Unlock for the tech and business concepts interviewers assume you know. Marty Cagan's Inspired is worth reading for product thinking, though it isn't an interview book. The catch in India is that guesstimate and metrics rounds decide a lot of outcomes, and no book replaces speaking your answers out loud and getting feedback — treat books as the syllabus, not the practice.

Free PDFs circulate widely across prep blogs, Telegram groups, and university club drives, and they're fine for getting familiar with the question types. The problem is that most are recycled, undated, and don't reflect current round structures — companies change their loops more often than PDFs get updated. A better use of your time is building your own answer bank: write out answers to 25–30 real questions across design, execution, guesstimates, and behavioural, then pressure-test them in mocks where you can get feedback on your structure.

It depends on what you're buying. A course is worth it if it gives you structure, deadlines, and — most importantly — live mock interviews with specific feedback from someone who has actually sat on PM interview panels. It's not worth it if it's mostly recorded videos repackaging frameworks that are freely available. If you're self-disciplined, spend the money on mocks instead; if you're switching domains or struggling to stay consistent, a structured program plus mocks shortens the cycle. Judge any course by the feedback loop it offers, not the hours of content.

You need proof of product thinking, not a PM title. Start inside your current role — volunteer for anything involving users, features, launches, or data, and turn that work into 2–3 case studies with measurable outcomes. Then target adjacent doors: APM programs, product analyst, business analyst, or project roles at product companies, since internal transfers are the most common route in India. Pair this with product teardowns or a small side project, a resume rewritten around outcomes instead of responsibilities, and referrals — cold applications without a strategy are where most people stall, not because of their background.

Consulting is one of the better launching pads because you already have structured problem-solving, stakeholder management, and communication — the gaps are product judgment, technical fluency, and owning metrics over outcomes. Bridge them by taking product-adjacent client work if you can, building teardowns and case studies that show user-level thinking, and getting comfortable with analytics basics like funnels and SQL. The highest-probability routes are an internal transfer to a product team, or target startups and scale-ups that actively hire ex-consultants; in interviews, translate your decks-and-savings stories into user-and-outcome stories.

There is no mandatory degree. Most PMs in India come from a B.Tech or engineering background, but companies hire PMs from design, analytics, marketing, and MBA programs too. An MBA helps in specific paths — APM programs at large MNCs and consulting-to-PM switches — but a large share of working PMs in India have no MBA and no Tier 1 college tag. What actually gets shortlisted is evidence: shipped work or projects, comfort with data and metrics, clear communication, and a resume that frames your decisions as product decisions. Doing an MBA purely "for PM" is usually an expensive detour.

Yes, and it happens every hiring season. Startups and most scale-ups hire on demonstrated product thinking rather than pedigree, and the standard playbook is: get into an adjacent role (analyst, project manager, designer, engineering with product exposure), build 2–3 strong case studies or side projects, then switch internally or target companies that weight proof over brand names. What holds people back is rarely the missing MBA — it's applying randomly with a resume that reads like a task list. A focused strategy, referral network, and interview practice close that gap.

Treat it as core PM skills plus AI literacy, not a separate career. Learn the fundamentals that interviews now probe: how LLMs work and where they fail, prompt design, evaluation of model outputs, RAG basics, latency and cost trade-offs, and data privacy considerations. Then create proof — propose or ship an AI feature in your current role, or build a teardown/side project around an AI product. Most Indian SaaS and fintech companies are layering AI features onto existing products, so your fastest entry is often "PM who knows AI" inside a domain you already understand rather than a pure AI research-adjacent role.