remidio Product Manager Interview: Questions & Prep (2026)

Remidio is a Bangalore-based medical technology company building AI-powered ophthalmic imaging devices, best known for portable fundus cameras used in diabetic retinopathy (DR) screening. Their products are deployed across primary health centres, NGOs, government health programs, and private hospitals in India and several international markets.

A Product Manager at Remidio works at the intersection of medical hardware, AI inference, clinical workflows, and healthcare distribution. This is not a typical software PM role. You are expected to understand the clinical stakes behind each product decision, work within regulatory timelines, and balance the needs of field users (nurses, ASHA workers, and technicians in rural settings) against those of specialist clinicians and procurement decision-makers.

As of July 2026, Remidio has 26 open roles across functions, signalling active hiring. PM candidates typically go through multiple rounds covering product thinking, domain knowledge, and cross-functional collaboration. This guide covers the questions most commonly reported by candidates, with frameworks and sample answers to help you prepare.

These questions reflect the themes candidates commonly report from Remidio PM interviews. Expect a blend of behavioural questions, product design scenarios, and domain-knowledge checks.

1. Walk me through how you would take a new feature for our fundus camera from discovery to launch.
2. How do you prioritise between a feature requested by a large hospital chain and a workflow fix that benefits field-level users at primary health centres?
3. What metrics would you define to measure success for an AI-based diabetic retinopathy screening product?
4. How do you gather requirements from clinicians or field staff who are not comfortable with technology?
5. Describe a time you worked on a product with both hardware and software components. What was the hardest challenge?
6. How do you handle regulatory or compliance requirements (such as CDSCO registration or CE marking) when the team is under pressure to ship quickly?
7. Remidio works with NGOs, government health programs, and private hospitals. How would you think about pricing strategy differently for each segment?
8. How would you design a feature to help a non-specialist (an ASHA worker or a nurse) capture a reliable fundus image with minimal training?
9. Tell me about a time data changed your mind on a product decision.
10. How would you approach expanding Remidio's reach into tier-2 and tier-3 cities where connectivity and device-handling experience are limited?
11. A clinician tells you the AI model is generating too many false positives and doctors are losing trust in it. What do you do as a PM?
12. What do you understand about the diabetic retinopathy burden in India, and how does that shape your thinking about product priorities?

Q: What metrics would you define to measure success for an AI-based diabetic retinopathy screening product?

*Situation:* At a previous company, I joined a healthtech team shortly after they launched an AI-based screening tool for a chronic condition. The team had no agreed definition of success: some tracked image capture volume, others focused on downstream clinical outcomes, and engineering monitored model accuracy in isolation.

*Task:* Before our next funding review, my job was to define a metrics framework that clinical, business, and technical stakeholders could all align on.

*Action:* I ran three workshops. One with the clinical team to identify what 'good' meant from a patient care perspective, covering sensitivity, specificity, referral rates, and time-to-diagnosis. One with the sales team to map revenue-linked KPIs such as device utilisation and contract renewal rates. One with engineering to surface leading indicators including image quality rejection rates and model confidence distributions. I then built a single dashboard with three tiers: health outcomes as the north-star, adoption and utilisation as secondary metrics, and model health as operational indicators. I also established a quarterly review cadence with our medical advisor.

*Result:* Within two quarters the team had a shared language for success. We discovered that image rejection rate was a leading indicator of false-positive complaints, which let us intervene with model retraining before clinicians raised concerns formally. Making referral conversion the primary north-star kept all roadmap discussions focused on what actually moved patient outcomes.

---

Q: How do you gather requirements from clinicians or field staff who are not comfortable with technology?

*Situation:* At a previous company, we were building a mobile diagnostic tool for use by nurses at primary health centres in rural areas. The users had limited smartphone experience and often managed large patient queues during session hours. Traditional surveys and feature-request forms were not producing useful signal.

*Task:* I needed to understand their actual workflow in enough depth to redesign the onboarding and image-capture flow before the next release cycle.

*Action:* I travelled to three primary health centres across two states and spent half-days shadowing nurses during patient sessions, taking notes and short videos (with consent) of how they handled the device in practice. I also interviewed supervising doctors separately to understand what they needed from the generated reports. Back in the office, I translated the field observations into 'jobs to be done' statements and ran a prioritisation session with engineering using effort-versus-impact scoring.

*Result:* The redesigned capture flow reduced image rejection rates significantly in our internal pilot. Nurse confidence with the device improved on post-training self-assessments, and the feature shipped on schedule. It later became a reference case for the product's deployment in a government screening program.

---

Q: How do you handle regulatory constraints when the team is under pressure to ship quickly?

*Situation:* I was the PM for a medical device software feature that required regulatory documentation before it could be included in a submission. The sales team had already committed to a hospital chain that the feature would be live within the quarter.

*Task:* I had to reconcile the delivery commitment with the regulatory requirement without asking either side to compromise on what mattered most to them.

*Action:* I worked with our regulatory affairs consultant to map every requirement to a specific test case and supporting document. I then split the scope into a 'core release' that could be verified and submitted in the current cycle, and a 'phase 2 scope' for the following quarter. I presented this split to the sales team with a clinical rationale, which they accepted because it also reduced their own liability exposure. I also built a lightweight regulatory checklist into our sprint process so the team would not face the same last-minute pressure again.

*Result:* The core feature shipped on time, the submission was accepted without a major query, and the phase 2 scope launched the next quarter. The hospital chain signed a multi-year renewal with the phase 2 roadmap included as a committed deliverable.

STAR (Situation, Task, Action, Result) is the default for behavioural questions. Keep Situation and Task brief and spend most of your time on Action and Result. Interviewers at medtech companies value specificity about the constraints you navigated, not just what you built.

CIRCLES (Comprehend, Identify, Report, Cut, List, Evaluate, Summarise) works well for open-ended product design questions such as 'design a feature for ASHA workers.' Walk through user, goal, constraints, and options systematically before landing on a recommendation. This signals structured thinking rather than jumping straight to a solution.

Jobs to Be Done is particularly effective for user research and prioritisation questions. Frame the user's need as a job: 'When I am at a rural health camp with a long patient queue, I need to capture a reliable fundus image quickly without device errors, so the right patients get referred before the session ends.' This framing resonates with interviewers who think primarily about field users.

Metric Trees signal PM maturity in success-metric questions. Show a hierarchy with a north-star metric at the top, broken into input metrics, then operational or leading indicators beneath. For a diagnostic product, the north-star is typically a clinical outcome, not an engagement metric.

Regulatory-First Thinking is specific to medtech. For roadmap and prioritisation questions, treat regulatory timelines as non-negotiable constraints rather than inputs to be weighed against features. Frame your prioritisation around what can ship within the next regulatory window, and show you understand that post-market surveillance is an ongoing PM responsibility, not a launch-day checkbox.

Clinical empathy without clinical over-indexing. Remidio's products are used in high-stakes settings, but the PM is not expected to be a doctor. Interviewers want to see that you understand the clinical stakes and can translate them into product decisions, without claiming expertise you do not have. Saying 'I would validate this with our medical advisor' is stronger than guessing at clinical detail.

Cross-functional fluency across hardware and software. Remidio ships physical devices and software in the same release cycle. Candidates who have only worked in pure software roles need to demonstrate they understand how hardware constraints (device calibration, battery life, connectivity, field servicing) affect software timelines and roadmap decisions.

Real market context for Indian healthcare. Questions about tier-2 city expansion, government program integration, and NGO pricing are not hypothetical exercises. Interviewers want to see that you understand the actual distribution landscape in India, including last-mile logistics, connectivity limitations, and procurement processes within public health programs.

Data discipline with clinical humility. In AI-powered diagnostics, a metric like sensitivity or specificity represents a clinical claim with patient safety implications, not just a model benchmark. Candidates who treat model performance metrics with the same rigour as business KPIs, and who know when to escalate a metrics question to a clinical expert, consistently stand out.

Comfort with longer development cycles. Medical device development moves more slowly than typical software. Candidates who can plan around extended regulatory timelines while keeping short-term delivery moving, and who show patience with cross-functional dependencies, match the profile Remidio is typically looking for.

Week 1: Know the product and the domain.
Spend time on Remidio's website, published case studies, and publicly available press coverage to understand their product line. Know what a fundus camera does, what diabetic retinopathy is, and why point-of-care screening is critical in the Indian context. Read briefly about the National Programme for Control of Blindness to understand the government program landscape Remidio operates in.

Week 2: PM fundamentals with a medtech lens.
Revise prioritisation frameworks (RICE, ICE, value-versus-effort) and practise applying them to medtech scenarios. Read about India's CDSCO medical device rules and how they differ from international regulatory pathways. You do not need to be a regulatory expert, but knowing the name of the Indian regulatory body and what device risk classification means will set you apart from most candidates.

Week 3: Behavioural preparation.
Write out five to seven STAR stories from your past covering: cross-functional conflict, user research in unfamiliar settings, a product that was cut or failed, a data-driven decision, and a launch under significant constraint. Practise delivering each story in under three minutes. Know the measurable outcome for every story before you walk in.

Week 4: Mock interviews and case practice.
Complete at least two mock PM interviews with someone who can give structured feedback. Practise one product design case on a healthcare or hardware-adjacent scenario. Candidates report that Remidio interviews favour realistic, applied problems over abstract brain-teasers, so prioritise depth in your case practice over breadth.

If you are looking at similar healthtech and medtech openings in parallel, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you, so you do not miss relevant openings while your time is focused on interview prep.

1. Treating it like a pure software PM role. Remidio's products involve physical hardware with field service and calibration implications. Answers that assume rapid patch cycles or ignore hardware constraints signal you have not researched the company.

1. Knowing the company only at surface level. Candidates who can only say 'you make eye care devices' tend to struggle in domain-knowledge rounds. Know the specific product lines, the clinical problem they solve, and the market segments Remidio serves.

1. Ignoring the actual end user. The person using the fundus camera in the field is often a nurse or technician in a rural setting, not a specialist ophthalmologist. PMs who only speak about doctors as users miss a critical dimension of the product challenge.

1. Being vague about metrics. 'I would track engagement and retention' is not sufficient for a medical device context. Interviewers want specific, clinically meaningful metrics and a clear explanation of why each one matters for patient outcomes or business health.

1. Underestimating regulatory constraints. Proposing a very short MVP cycle for a feature that touches the AI diagnostic output will raise concerns. Show you understand that regulatory review is a mandatory step with its own timeline, not a formality to work around.

1. Over-engineering answers for a large-company context. Remidio is a scaling startup. Answers that assume dedicated UXR teams, extended A/B test infrastructure, or large PM organisations may not reflect the company's actual operating reality. Show you can work lean and move fast within real constraints.