Narayana Health (NH) Product Manager Interview: Questions, Experience & Prep (2026)

Narayana Health (NH) is one of India's largest hospital networks, founded on the mission of delivering quality care at affordable prices across hundreds of facilities. For a Product Manager, NH means working on tools used daily by patients booking appointments, doctors managing clinical workflows, and administrators running multi-specialty operations. The role sits at the intersection of healthcare, technology, and real-world operations, and the mission-driven culture attracts PMs who care deeply about health outcomes.

As of the knok jobradar snapshot from July 2026, NH has 3 open PM roles. Candidates report the process typically spans several rounds. A take-home case study or assignment usually comes early, focused on a healthcare or operations problem. Later rounds cover product thinking, data fluency, stakeholder management with clinical teams, and leadership or culture fit. Expect a strong emphasis on how you handle non-tech stakeholders and how you measure success in complex environments.

Across the Indian PM market broadly, salary bands run from 12-20 LPA at Associate PM level, 24-40 LPA for PMs with 3-6 years of experience, 40-60 LPA for Senior PMs, and 55-90+ LPA for Group or Principal PMs. NH-specific pay is not publicly reported at scale, so use these as market reference points and check platforms like Glassdoor for current self-reported estimates.

These questions reflect the patterns candidates report from NH PM interviews, shaped by the company's focus on affordable healthcare, large-scale hospital operations, and close collaboration with clinical teams.

1. 'Why do you want to build products at Narayana Health specifically, and what draws you to healthcare as a domain?'
2. 'How would you prioritise features for a patient appointment booking app when doctors, administrators, and patients all want different things?'
3. 'NH's mission is affordable care at scale. Design a product or feature that reduces patient wait times without raising costs for the hospital.'
4. 'Tell me about a time you worked with a non-tech stakeholder, such as a doctor or a nurse, to ship a product. What did you learn from the experience?'
5. 'How would you define and track the right success metrics for an electronic medical records (EMR) system used by doctors every day?'
6. 'Walk me through how you would improve the post-discharge experience for patients across a large multi-specialty hospital network.'
7. 'NH operates in smaller towns and cities too. How would you roll out a digital product where patients or staff have lower digital literacy?'
8. 'How do you make product decisions when user research is thin or the data you have is incomplete or noisy?'
9. 'Tell me about a product or feature you shipped that did not work out. What went wrong, and what would you do differently?'
10. 'How would you gather meaningful feedback from a patient group that cannot give it directly, such as ICU patients or elderly patients without smartphone access?'
11. 'A senior doctor is insisting on a feature your data shows very few users actually need. How do you handle that conversation?'
12. 'NH is expanding internationally. How would you approach adapting an existing product for a new country or market?'

Q: Tell me about a time you worked with a non-tech stakeholder to ship a product feature.

*Situation:* I was the PM on a digital discharge summary feature at a healthcare organisation. The clinical team, especially senior nurses, were sceptical about replacing paper-based forms they had relied on for years.

*Task:* My job was to get the nursing team genuinely on board and make sure the feature fit their actual workflow, not the workflow we had assumed on paper.

*Action:* I spent several shifts shadowing nurses during handovers, taking detailed notes and asking questions at every step where paper was involved. I then ran a co-design session where nurses helped us rework the digital form fields directly. I flagged several places where our original design would have slowed them down rather than helped them, and we fixed those before the pilot launch.

*Result:* The nursing team became the strongest champions of the feature during the wider rollout. Adoption in the pilot ward was strong within the first month, and their feedback directly shaped improvements we shipped in the next release.

---

Q: Tell me about a product or feature you shipped that did not work out.

*Situation:* I led the launch of an in-app health tips module for a patient-facing app. The idea came from a hypothesis that patients wanted preventive care content alongside their appointment management.

*Task:* After launch, I needed to honestly evaluate whether the feature was delivering value and decide what to do next.

*Action:* A few weeks after launch, engagement data showed the module was barely used. I ran interviews with a small group of active app users and found that patients opened the app mainly to book or check appointments, not to read health content. I put together a clear recommendation to deprioritise the module and redirect engineering time to improving appointment reminders instead.

*Result:* The team aligned quickly. The reminder improvements shipped in the next cycle and drove clear gains in appointment show-up rates, which was the metric the business cared most about. The failed module taught me to validate the core use case before building the nice-to-have layer.

---

Q: How would you prioritise features when different stakeholders have conflicting needs?

*Situation:* At a health-tech company, three groups were all pushing for different work at the same time: doctors wanted richer clinical notes fields, patients wanted a simpler booking flow, and the operations team wanted better reporting dashboards.

*Task:* I had to make a clear recommendation on what the engineering team would focus on next, with limited capacity to do everything at once.

*Action:* I ran a prioritisation exercise tying each request to a specific measurable outcome. Booking completion rate for patients, time-on-task for doctors, and report generation time for the ops team. I then brought all three stakeholder groups into the same session so they could each see the other groups' needs, not just their own request. That transparency changed the tone of the conversation immediately.

*Result:* The group agreed together to focus on the booking flow first, because it had the clearest link to both revenue and patient satisfaction. The doctors' top request was broken into a smaller change we could ship alongside the booking work. Everyone left aligned, and we avoided weeks of back-and-forth escalation.

STAR for behavioural questions. Every story needs a clear Situation, Task, Action, and Result. NH interviewers particularly pay attention to the Action section because healthcare product work involves navigating complex stakeholder dynamics, not just writing specifications. Be specific about what you personally did, not what the team achieved.

Jobs-to-be-Done for product design questions. Instead of jumping straight to features, start with: 'What job is the patient or doctor trying to get done?' This framing resonates strongly in healthcare because the real user need is often different from the surface request. A nurse asking for a simpler form may actually need faster handover, not fewer fields.

North Star Metric with guardrail metrics. When asked about metrics, name one primary metric that captures product success (such as appointment completion rate or time-to-discharge), then name guardrail metrics that ensure the primary metric cannot be gamed at the cost of quality or safety. Clinical safety is a guardrail that matters deeply at NH and naming it signals domain awareness.

The 'Affordable at Scale' lens. NH's founding mission is quality care at low cost across many locations. When you propose a solution, ask yourself: does this work for a hospital in a smaller city, not just a flagship urban facility? Does it add cost or reduce it? Framing answers through this lens shows you have genuinely internalised what NH is optimising for.

Stakeholder mapping for conflict questions. Before proposing a resolution, map out who has decision-making authority, who is most impacted, and who holds domain expertise. In healthcare, doctors often have high authority but patients carry the most risk. Showing you can hold both perspectives at once signals maturity to an interviewer.

Mission alignment, not just product enthusiasm. NH interviewers can spot candidates who say 'I am passionate about healthcare' without backing it up. Show that you understand the real constraints: regulatory requirements, clinical workflow complexity, affordability pressure, and the challenge of designing for users with varying digital literacy. Go beyond the surface-level statement.

Comfort with clinical complexity. Healthcare products touch safety-critical data and are used by professionals who have little tolerance for software that slows them down. Interviewers want to see that you respect this complexity rather than treating it as a minor detail to solve later in the sprint.

Data fluency paired with honesty about its limits. NH values candidates who use data to drive decisions but who also know when data is thin or potentially misleading. Saying 'I would validate this assumption with a small pilot before scaling' scores better than claiming you always have clear metrics for every situation.

Proven ability to manage clinical stakeholders. This comes up consistently in candidate feedback. Can you influence a senior doctor without formal authority? Can you explain a technical trade-off to a hospital administrator who does not think in product terms? Experience in regulated or healthcare environments is a bonus, but the underlying skill is what they are testing for.

Operational thinking beyond the design. NH runs hospitals across many locations. Interviewers appreciate PMs who think about rollout logistics, staff training, and change management, not just the product design in an ideal world. Mentioning how you would handle a rocky rollout or low adoption signals real-world readiness.

Week 1: Build your NH and healthcare foundation.
Research everything NH has published publicly about its mission, clinical programs, and technology direction. Understand the difference between patient-facing products (apps and portals) and internal tools (EMR systems, scheduling, operational dashboards). Map out the key user types you might build for: patients, doctors, nurses, and hospital administrators.

Week 2: Practice case studies with a healthcare lens.
Take standard PM case prompts (improve a product, design a new feature, diagnose a metric drop) and reframe them in healthcare contexts. Apply the 'affordable at scale' test to every solution you propose. Practise a clear structure: understand the problem, define users and their jobs, explore solutions, prioritise, define success metrics, and consider rollout.

Week 3: Sharpen your behavioural stories.
Prepare at least four STAR stories covering: working with non-tech stakeholders, handling a product failure, prioritising under constraint, and making a call with incomplete data. If you have healthcare experience, lead with those stories. If not, focus on the transferable skills: user empathy, data reasoning, and influencing without authority.

Week 4: Mock interviews and case study polish.
Do at least two full mock interviews with a peer or mentor. Check that your answers connect to business outcomes, not just feature delivery. Review your case study structure: problem framing, user insight, solution options, recommended approach, success metrics, and rollout considerations. Make sure every answer you give could survive a 'so what?' follow-up.

While you prepare, knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR for you, so you do not miss openings at NH or similar companies while you are busy practising.

Treating the mission as a generic talking point. Saying 'I am passionate about healthcare' without demonstrating knowledge of NH's specific challenges tends to fall flat. Show that you understand affordability trade-offs, clinical workflow constraints, and the difficulty of scaling digital products across hospitals of different sizes and cities.

Jumping to solutions too fast in case questions. A common pattern is naming a feature within the first minute of a design question. NH interviewers want to see you slow down, ask clarifying questions, define the user and the problem clearly, and only then explore solutions. Rushing signals shallow product thinking.

Ignoring the non-digital user. Not every patient or doctor at NH uses a smartphone or is comfortable with apps. Proposals that assume fully digital workflows across all locations miss the reality of how NH operates in smaller cities and towns. Design for the full spectrum of users, not just the tech-comfortable ones.

Being vague about metrics. Saying 'I would track engagement' is too thin for an NH interview. Name the specific metric, explain why it matters for this product and this user type, and add at least one guardrail metric. In healthcare, clinical safety or accuracy is almost always the guardrail to name first.

Skipping the stakeholder layer in behavioural answers. Candidates often describe what they built without explaining how they navigated the people involved. At NH, how you managed a difficult doctor, a resistant team, or a sceptical administrator is often as important as the product outcome itself.

Missing the operational dimension. PM roles at a large hospital network involve rollouts across many facilities, training non-technical staff, and managing change in traditionally conservative environments. If your answers only cover the design phase and not the delivery phase, it suggests you have not thought through what it actually takes to ship in this context.