Start with fundamentals before spending on anything: read one good PM book (Inspired or Cracking the PM Interview), understand what a PM actually owns — outcomes, not code — and study how products around you make decisions. Then build proof: pick an app you use daily, write a teardown of what you'd improve and why, and try a small side project end-to-end, including talking to a few users. Pair this with structured learning — free resources, a short course, or a mentor — and practise thinking aloud. Most freshers fail not from lack of knowledge but from never practising product thinking, so make that a daily habit from week one.

Treat practice as repetition, not reading. Do weekly product teardowns of apps you use, write one-page PRDs or feature proposals, practise estimating metrics ("what would success look like for this feature?"), and analyse why products succeed or die in the Indian market. Mock interviews and case discussions with other aspiring PMs — or with an experienced PM mentor — add the feedback loop self-study can't give. Side projects count too: shipping something small, even with no-code tools, teaches prioritisation, trade-offs, and working under constraints better than any course.

Product management is the job of deciding what to build, why to build it, and for whom — and then making sure it actually gets built and works for users and the business. A PM usually doesn't write the code or design the screens; instead, they talk to users, prioritise what matters most, define requirements, and keep engineering, design, and business teams aligned. In simple words: the PM owns the "why" and the "what," while the team owns the "how." Done well, it's the role accountable when a product wins — or fails.

Understand the rounds first: most Indian product companies run a recruiter screen, one or two product sense/case rounds, an execution or analytics round, and behavioural rounds. Prepare structured frameworks for product design and guesstimates, build 4–6 real stories for behavioural questions, and research the company's product deeply enough to give opinions, not summaries. Practising aloud matters more than reading, so do a few mock interviews with detailed feedback before the real thing — mentors like Abhishek Singh Rathore, ranked in the top 0.1% on Topmate, offer exactly this kind of detailed-feedback mock. That feedback loop compresses months of trial and error into a few sessions.

Learn frameworks, not scripts. Interviewers spot memorised answers instantly; what they're really testing is whether you can structure an unfamiliar problem. Use a simple pattern — clarify the goal, define the user and their problem, brainstorm options, prioritise with reasoning, and define success metrics — and apply it freshly to whatever is asked. For behavioural questions, keep a small bank of real stories from your own work and adapt them to different questions. Practising the same answer three different ways aloud is far more effective than memorising one polished version.

It usually runs 3–5 rounds over 2–4 weeks: a recruiter or hiring manager screen, a product sense or case design round, an execution/analytics round covering metrics and guesstimates, and a behavioural round, sometimes with a final conversation with a senior leader. Startups often compress this into 2–3 rounds and may give a take-home assignment, while large companies and FAANG-style offices in India follow a more structured, global format. Always ask your recruiter what each round covers, because preparation changes significantly depending on whether the round is case, execution, or behavioural.

For most people switching into PM or applying actively, 6–8 weeks of focused preparation is realistic: 2–3 weeks for frameworks and product fundamentals, 2 weeks for practising cases, guesstimates, and metrics questions aloud, and the rest for behavioural stories, company research, and mocks. If you're preparing alongside a full-time job, plan for 8–10 weeks at about an hour a day. The biggest time-sink is unstructured reading — set an application date, prepare backwards from it, and make sure the final week includes 2–3 mock interviews with honest feedback rather than more theory.

No — it's one of the most common reasons strong candidates fail. Question banks are useful to understand the categories asked (product design, metrics, strategy, behavioural), but interviewers tweak the question slightly and a memorised answer falls apart. The better approach is to practise answering unfamiliar questions using frameworks, out loud, under time pressure — record yourself, review where your structure breaks, and get external feedback through peers or mock interviews with experienced PMs. Use question banks to drill variety, not to collect scripts.

Neither is mandatory — Indian product companies don't screen for a PM certification the way some roles screen for degrees. What courses and certifications genuinely give you is structure: a syllabus, deadlines, and a peer group, which helps if you struggle with self-study. What they don't give is proof that you can think like a PM, so whatever you enrol in, pair it with teardowns, case practice, or a side project you can discuss in interviews. If budget is tight, books, free resources, and a few targeted mentorship sessions usually beat an expensive program with no practical work attached.

Apply where fresher PM internships actually exist: startups on LinkedIn, Wellfound and Internshala, structured APM or internship programs at larger companies, and your campus placement cell if you're a student. Since PM internships attract hundreds of applicants, stand out with proof of product thinking — a teardown, a case study, or a small project linked in your resume — and tailor one line of your application to that specific company's product. Cold outreach works better than people expect: a short, specific message to a founder or PM ("here's something I noticed about your onboarding, here's what I'd test") beats a generic "any openings?" every time, and referrals through alumni and PM communities often unlock unlisted roles.

Engineers already have a real advantage — you understand how products get built — so the switch is about adding product skills to your story, not starting over. Start by taking product ownership in your current role: write specs, talk to users or customers, propose features, own a metric. Redo your resume so it highlights outcomes and decisions rather than technologies, and prepare a genuine, specific answer to "why PM?" Target companies that value technical PMs — developer tools, fintech, B2B SaaS — where your background is a differentiator, and practise product case interviews since that's the muscle engineers use least. Internal transfers are often the easiest route, so tell your manager early that you want product exposure.

It varies widely: fresher PM salaries in India typically range from about ₹6–12 LPA at smaller startups, ₹12–25 LPA at mid-size product companies and well-funded startups, and ₹25–50+ LPA for elite APM programs at top firms. Location, campus, and prior internships move these numbers significantly, and fintech and B2B SaaS tend to pay competitively for technically strong candidates. If you're switching from engineering with experience, expect your current CTC to anchor negotiations — so evaluate the total offer, because learning, scope, and growth matter more in your first two PM years than a small initial bump.

Product discovery is the work you do before building: figuring out which problems are worth solving, for whom, and what solution would actually work. It covers understanding users through interviews and data, defining the problem sharply, testing ideas cheaply with prototypes or small experiments, and validating that the solution is desirable, usable, and viable. It matters because most product failures aren't build failures — they're discovery failures, where a well-built feature solved a problem nobody had. Studying product discovery examples — like how Airbnb tested professional photography to boost bookings, or how Indian apps trial features city-by-city before a national rollout — makes the concept concrete.

Start with the problem, not the solution. Map your users and talk to 5–10 of them about their current behaviour, look for patterns in support tickets, analytics, and drop-offs, then define the problem precisely — who has it, how often, and what it costs them. Next, ideate broadly, prioritise on impact versus effort, and test the riskiest assumptions with cheap experiments: a prototype, a concierge version, or a fake-door test. The product discovery process should end with a validated problem-solution fit and clear success metrics before engineering commits — and remember that discovery is ongoing, not a phase you hand off. If you're unsure whether your approach is sound, a quick problem-discovery review with an experienced PM helps a lot.

A practical starter set: the Opportunity Solution Tree (Teresa Torres) for connecting user needs to outcomes, Jobs-to-be-Done for understanding what users are really hiring your product to do, The Mom Test for running non-leading customer interviews, dual-track agile for running discovery and delivery in parallel, and RICE or impact-effort scoring for prioritising what reaches the roadmap. You won't use all of them daily — most working PMs lean on an opportunity tree plus structured customer interviews, and use prioritisation frameworks mainly to defend decisions to stakeholders. Learn each well enough to know when it fits, then adapt to your team's context.