Berg Group Product Manager Interview: Questions, Experience & Prep (2026)

Berg Group currently has 22 open Product Manager roles, making it one of the more actively hiring companies for PMs in India right now. The knok jobradar tracked these openings as of early July 2026, with Bangalore (271 total PM openings across the market), Delhi (177), and Mumbai (56) seeing the most activity.

Candidates report a process that typically runs three to five rounds. These commonly include a recruiter screen, one or two product thinking rounds covering product sense and strategy, a round focused on data and metrics, and a closing conversation with a senior stakeholder. Round structures vary across teams, so confirm the format with your recruiter before each stage.

Compensation for PM roles in the Indian market ranges from 12-20 LPA at the Associate level to 55-90+ LPA for Group or Principal PMs. Mid-level PM roles with three to six years of experience typically sit in the 24-40 LPA band, and Senior PM roles at 40-60 LPA. Your specific offer will depend on the vertical, your experience level, and how you negotiate.

These questions reflect themes that candidates publicly report being tested on in PM interviews at companies like Berg Group. Prepare concrete examples for each one.

1. Walk me through a product you have shipped end-to-end. What was your specific role, and what would you do differently?
2. How do you prioritise competing features when your engineering team has limited capacity and multiple stakeholders are pushing different items?
3. Tell me about a time data changed a product decision you had already committed to. What did you do?
4. How would you define and measure success for a new user onboarding flow?
5. Pick a product you think is broken or underperforming. How would you diagnose it and what would you fix first?
6. A key feature launches and engagement is significantly lower than expected in the first week. Walk me through how you would diagnose and respond.
7. How do you manage a stakeholder who repeatedly asks for features outside your core roadmap?
8. Tell me about a time you had to say no to a customer or business request. How did you handle it, and what was the outcome?
9. How do you decide when to build a capability in-house versus buying a tool or partnering with a third party?
10. Describe a competitive market you have worked in. How did you position your product, and what signals did you track to stay ahead?
11. How do you write a product requirements document that engineers will actually read and follow?
12. Where do you see AI changing the PM role over the next two to three years, and how are you preparing for it?

Use the STAR format for all behavioural questions. Here are three full examples for the kinds of questions Berg Group candidates typically face.

Q: How do you prioritise features when capacity is limited and multiple stakeholders want different things?

*Situation:* At my previous company, we had a small engineering team and six features competing for the next sprint, each backed by a different internal stakeholder.

*Task:* I needed to select the two highest-impact items without creating lasting conflict among the teams involved.

*Action:* I ran a RICE scoring exercise (Reach, Impact, Confidence, Effort) and held a short session with each stakeholder to gather their estimates on each dimension. I then put all six features on a shared sheet so every stakeholder could see the full picture. One item that everyone assumed was top priority scored poorly once effort was factored in. I proposed deprioritising it and walked through the reasoning transparently.

*Result:* We shipped the two highest-scoring features on time. The stakeholder whose item was dropped accepted the outcome because the process was visible and fair. The deprioritised feature shipped in a later sprint with a stronger design.

---

Q: Tell me about a time data changed a product decision you had already committed to.

*Situation:* We had publicly committed to launching a social sharing feature in our mobile app within the quarter.

*Task:* Three weeks before launch, I was reviewing early beta feedback and saw that usage was well below our target.

*Action:* I pulled session recordings and ran a quick survey with our beta cohort. The data showed users specifically wanted to share via WhatsApp, but we had only built generic social platform sharing. I presented this finding to the team with supporting evidence and recommended accepting a two-week delay to add WhatsApp sharing.

*Result:* We launched two weeks later with the right integration. Adoption came in materially higher than what our beta had projected, and the change became a frequently cited example of customer-first thinking within the team.

---

Q: Tell me about a time you had to say no to a business request.

*Situation:* A senior sales leader asked our team to build a custom reporting dashboard for a single enterprise prospect they were close to closing.

*Task:* I had to respond without derailing the core roadmap or damaging a relationship with a senior internal stakeholder.

*Action:* I met with the sales leader, asked them to walk me through the deal size and timeline, and mapped the request against our roadmap to show the opportunity cost. I proposed a lighter version using existing configurability that would take one engineer two days rather than two weeks, and I offered to join the sales call to explain our product direction to the prospect directly.

*Result:* The prospect accepted the lighter version, the deal closed, and we protected our roadmap. The sales leader became a stronger advocate for looping PM into client conversations before commitments are made.

RICE for prioritisation questions. Reach (how many users in a given period), Impact (effect on the key metric per user), Confidence (how certain you are of your estimates), Effort (person-months of work). Divide the first three and divide by Effort to get a score. Use it to make trade-offs visible and defensible, not to claim false precision.

STAR for behavioural questions. Situation sets the scene in one or two sentences. Task explains what you were personally responsible for. Action is the longest part and must focus on what YOU specifically did, not what the team did. Result should be concrete, and if you lack a number, state the qualitative outcome clearly.

Jobs-to-be-Done for product sense questions. When asked to evaluate or improve a product, start with the user job: what are they trying to accomplish, and what is blocking them? This shifts the conversation from features to outcomes and signals product maturity.

North Star plus input metrics for metrics questions. Identify one North Star metric that captures long-term user value for the product. Then name two to three input metrics that drive it. This answers 'how do you measure success' questions cleanly without listing ten KPIs.

MECE breakdown for estimation or market-sizing questions. Divide the problem into mutually exclusive, collectively exhaustive segments. Walk through your logic out loud. Interviewers care more about structure than the final number.

Customer obsession over feature obsession. PM interviewers consistently reward candidates who start with the user problem before jumping to a solution. If you lead with a feature idea before explaining the user pain, expect a follow-up that challenges your reasoning.

Data fluency, not data worship. Interviewers want to see that you know when to trust data and when to override it. Saying 'the data was inconclusive so I ran a quick qualitative check' shows more maturity than always citing numbers.

Structured thinking under pressure. When given an ambiguous problem, candidates who ask one clarifying question, state their approach, and work through it step by step perform better than those who jump to conclusions or ask five questions before saying anything substantive.

Ownership and cross-functional influence. Companies like Berg Group want PMs who treat outcomes as their responsibility even when they have no direct authority over engineering, design, or business teams. Frame your past experiences around what you drove, not what the team delivered.

Self-awareness in failure stories. When asked about mistakes, interviewers are listening for honesty and a clear articulation of what you learned. Blaming external factors or quietly turning a failure into a stealth success story are both red flags.

Week 1: Know the company and the role. Read Berg Group's publicly available product and press materials. Map what you find against the 22 open PM roles on their careers page to understand which verticals they are investing in. Write down three to five hypotheses about their current product challenges.

Week 2: Build your story bank. List eight to ten situations from your past work that can answer the most common PM behavioural questions. Use the STAR format for each. Cover at least one failure, one stakeholder conflict, one data-driven decision, and one prioritisation trade-off.

Week 3: Practise product sense out loud. Pick two to three products and practise diagnosing them using Jobs-to-be-Done. Time yourself. Recording yourself for five minutes and replaying it is uncomfortable but effective at surfacing gaps in your reasoning.

Week 4: Mock interviews and logistics. Do at least two mock interviews with someone who will push back on your answers. Prepare your questions for the interviewer (ask about the team's biggest unsolved problem, not about perks or culture). Confirm the round structure and interviewer names with your recruiter before each stage.

While you are preparing, knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR for you, so your applications keep moving even when your time is going into interview prep.

Skipping clarification on ambiguous questions. Many candidates launch into an answer before understanding what is being tested. One focused clarifying question shows product instinct and buys you a moment to think.

Using jargon without substance. Saying 'I am data-driven' or 'I follow agile' without a concrete example is filler. Every claim in a PM interview should be backed by a specific situation.

Making the STAR answer about the team, not yourself. 'We decided' and 'the team built' make your individual contribution invisible. Use 'I' when describing your specific actions and decisions.

Ignoring the business context in product questions. Candidates who suggest solutions without mentioning revenue, retention, or cost trade-offs often get eliminated even if their idea is creative. A strong PM answer always connects user value to business value.

Treating the offer as fixed. Many candidates, especially first-time job changers, do not negotiate. For PM roles in the 24-40 LPA band, a well-prepared negotiation conversation is expected and usually welcomed. Know your target number before the offer call.

Not asking good questions at the end. The 'do you have any questions for us?' slot is a product sense test in disguise. Ask about a real challenge the team is working on, not about work-life balance or team size.