Big Assets Infra Product Manager Interview: Questions, Experience & Prep (2026)

Big Assets Infra has 13 active Product Manager openings as of July 2026, signalling a meaningful growth phase for its product team. Across India, there are 2,009 PM openings in total, so the broader market is active. Big Assets Infra's infrastructure and asset management focus, however, means you are competing against a more specific pool of candidates who either know the domain or have done serious homework before applying.

The company builds tech for the infrastructure sector, so interview panels typically care about how you think through long-cycle projects, enterprise client relationships, and products where the end user is often a field professional rather than a tech-savvy consumer. Candidates report a process that runs through three to five rounds, blending product thinking questions, behavioural interviews, and sometimes a take-home case.

For market context, PM compensation in India sits at:

Big Assets Infra has not publicly confirmed its own pay bands. Use the table above as a market benchmark when preparing to negotiate.

Candidates who have gone through the Big Assets Infra PM process typically report questions across three themes: product strategy, stakeholder management, and behavioural depth. The company's B2B enterprise and infrastructure context shapes most of these questions directly.

1. Walk me through a product you use or admire in the infrastructure, construction, or asset management space. What would you change about it?
2. How would you prioritise features for a platform used by both enterprise clients and internal operations teams when their needs conflict?
3. A large enterprise client is requesting a custom feature that no other client has asked for. How do you evaluate the request and respond?
4. How would you define and measure success for an asset tracking module in its first quarter?
5. Tell me about a time you had to kill or delay a feature you personally championed.
6. Describe how you would run product discovery for a new module targeting field supervisors with low digital literacy.
7. How do you manage a roadmap when engineering timelines and client-facing commitments are in conflict?
8. Walk me through how you would build a roadmap from scratch when there is no existing user research.
9. Tell me about a product decision you made with incomplete or unreliable data. What was your process?
10. How do you communicate a product delay to an enterprise client without damaging the relationship?
11. If you were PM for Big Assets Infra's core platform today, what is one thing you would ship in the next quarter and why?
12. Describe a product failure. What happened, what was your specific role, and what did you do differently afterward?

Q: Tell me about a time you had to kill or delay a feature you personally championed.

*Situation:* I was PM for a workflow automation tool at my previous company. I had driven a document templating feature through six months of planning and development.

*Task:* Shortly after beta launch, usage data showed the feature was barely being picked up. I had to decide whether to invest more in fixing it or cut it and redirect capacity.

*Action:* I ran structured interviews with a small group of beta testers. The feedback was consistent: the feature solved a real problem but the setup was too complex for non-technical field staff. Engineering estimated a meaningful rewrite would take three months, directly competing with a mobile release the business had already committed to clients. I documented the findings, aligned with the engineering lead, and recommended we sunset the feature and redirect to the mobile release.

*Result:* The mobile release shipped on schedule. I preserved the discovery notes in a product brief so a simpler version of the feature could be revisited later with a clearer scope.

---

Q: How do you handle conflicting priorities between a B2B enterprise client and internal operations?

*Situation:* At a previous role, a large infrastructure client requested a custom report format on a two-week timeline. At the same time, our internal ops team had been waiting on a bulk-upload bug fix that was blocking their daily work.

*Task:* Both requests were valid. I had one sprint of engineering bandwidth.

*Action:* I mapped the actual impact of each. The client's report was needed for a presentation, not a broken workflow, so a well-formatted CSV export could cover them short-term. I aligned with the account manager on that workaround, set clear expectations with the client, and prioritised the ops bug fix. I put the custom report on the following sprint with a written commitment.

*Result:* Ops productivity recovered within the week. The client accepted the workaround and the report was delivered on the committed date with no escalation.

---

Q: Tell me about a product decision you made with incomplete data.

*Situation:* We were deciding whether to build a mobile-first version of our asset inspection tool. The product had only ever run on desktop, so there was no mobile usage data at all.

*Task:* The business wanted a go or no-go recommendation within two weeks.

*Action:* I ran a short discovery sprint: a small round of interviews with field inspectors, a brief survey sent to contacts at our top clients, and a review of publicly reported trends in mobile adoption for field workers in comparable sectors. I also analysed drop-off patterns in the desktop tool that suggested users were attempting mobile access. The signals consistently pointed to mobile being a genuine need, not a nice-to-have.

*Result:* I recommended a lightweight mobile prototype for one core workflow rather than a full rewrite. That framing got engineering and business buy-in. The prototype shipped in one quarter and became the foundation for the full mobile roadmap.

STAR for behavioural questions. Every 'tell me about a time' question expects Situation, Task, Action, Result. Keep the first two brief. Spend most of your answer on Action (what you specifically did, not the team) and Result (what actually changed, including honest caveats about what did not go perfectly).

Jobs-to-be-done for product thinking. When asked about features or roadmaps, anchor on the user's underlying job before describing a solution. 'Field supervisors need to confirm asset handover without switching apps mid-inspection' is a stronger starting point than 'we should add a mobile scan feature.'

Impact versus effort for prioritisation. When asked how you would prioritise, state your assumptions about impact and effort out loud before ranking anything. Interviewers want to see your reasoning, not just your list. Always mention what you are deliberately deprioritising and why.

Funnel-first for analytical questions. If a metric drops, walk through the conversion funnel layer by layer before proposing a fix. This signals systematic diagnosis rather than intuition-led guessing.

Assumptions-first for estimation. State your assumptions before you calculate anything. This lets the interviewer redirect you early if an assumption is off, and it signals rigour even when your final answer is approximate.

Domain curiosity over domain expertise. Big Assets Infra is niche enough that most candidates will not have direct infrastructure PM experience. Interviewers typically reward those who have researched the product, the clients, and the competitive landscape, not just those who have spent years in the sector.

Structured thinking under ambiguity. Infrastructure products involve long project cycles, multiple stakeholders, and data that is often incomplete. Candidates who ask clarifying questions, surface assumptions, and work through problems methodically tend to do better than those who jump to polished answers too quickly.

Stakeholder balance. The role sits at the intersection of enterprise clients, internal ops, and engineering. Interviewers look for evidence that you have navigated competing demands without letting one party down silently.

Ownership language. In your stories, use 'I recommended,' 'I made the call,' 'I aligned the team.' Stories where 'we' does all the work leave interviewers unsure about your specific contribution.

Client-facing clarity. Big Assets Infra's end clients are often non-technical. Interviewers notice whether you can explain complex product decisions in plain terms, both in your answers and in how you frame your scenarios.

Week 1: Company and product research. Go through Big Assets Infra's website, any press coverage from 2024-2026, employee posts on LinkedIn, and all 13 open PM job descriptions. Write a paragraph in your own words describing what the core product does, who uses it, and what problems it solves. Being able to name a comparable product or a competitor signals genuine interest.

Week 2: Product practice. Pick two or three infrastructure or asset-management products and critique each one out loud: what works, what is broken, what you would ship next. Record one session and watch it back to catch vague language and filler.

Week 3: Behavioural preparation. Write out five STAR stories from your last two roles. Cover: a product failure, a stakeholder conflict, a prioritisation call made under pressure, a time you used data to change direction, and a feature you killed or delayed. Practise with a peer who will push back with follow-up questions.

Week 4: Mock interviews and logistics. Do at least two full mock interviews. Confirm the interview format with your recruiter (number of rounds, panel or individual). Review your resume for any claim you cannot back up with a story.

If tracking 13 open roles at Big Assets Infra across multiple platforms sounds like extra work on top of your prep, knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR for you.

1. Talking about the team instead of yourself. Interviewers want to know what you did. Replace 'we built' with 'I drove the decision to build' wherever that is accurate.

1. Skipping the 'why' on roadmap answers. Listing features without connecting them to a user need or business outcome reads as shallow. Always explain the prioritisation logic, not just the output.

1. Ignoring the infrastructure context. Generic PM answers that could apply to any SaaS company miss the mark here. Ground your examples in scenarios relevant to asset management, enterprise clients, or project-tracking workflows.

1. Over-relying on framework vocabulary. Dropping terms like 'north star metric' or 'OKR cascade' without applying them to the actual question signals surface-level knowledge. Frameworks are a thinking tool, not vocabulary to impress.

1. Not preparing questions to ask. Candidates who have no questions at the end leave interviewers unsure about their genuine interest. Prepare two or three specific questions about the product roadmap, team structure, or how success is measured in the role.

1. Polishing away the failure. Big Assets Infra, like most product companies, values candidates who have learned from things that went wrong. A story that is too clean often sounds less credible than an honest one with a real learning at the end.