Expert Insights: Sameer Sawarkar – Rural Healthcare Innovation (Part 1)
Neurosynaptic Communications is a venture focused on digital healthcare for the last mile – rural areas where 69–70% of India's population lives. The company develops technological solutions (medical devices, software, workflows) and implements projects to deliver healthcare access, either as a service for partners or through its own clinics.
Founder Background and the Original Idea
- Sameer Sawarkar and his partner Rajiv Kumar are both electrical communication engineers from the Indian Institute of Science (IISc) and former Motorola colleagues.
- Sawarkar’s earlier entrepreneurial stint (Dax Software) taught him what entrepreneurship meant.
- Inspired by an article on brainwaves used to detect driver alertness and the concept of neural plasticity (the brain re-wires itself when one sense is lost), they formed Neurosynaptic in 2000 as a neurotechnology company.
- Early project: a vision-substitution device for the blind. A camera fed visual data to a 16×16 electrode array mounted on a denture placed on the tongue. The tongue has the highest neuron density; the brain learns to "see" through taste-related areas. Tested successfully with the National Association of Blind.
The Pivot to Rural Healthcare
- A chance meeting with Professor Ashok Jhunjhunwala (IIT Madras) revealed a massive, unsolved problem: healthcare access in rural India. Sawarkar and Kumar, both from rural backgrounds, immediately connected with it.
- IIT Madras had built an ecosystem of rural kiosks using DECT-based wireless connectivity (CoroDECT, 32–64 kbps, 30 km radius). These kiosks provided tele-education, e-governance, and later were the forerunners of the Common Service Centres (CSCs).
- The core philosophy: profit-making, not profiteering – a system must be self-sustaining through profit to scale, but profits should not come at the expense of others. This bridges shareholder (maximising value) and stakeholder (social welfare) views.
The Rural Healthcare Problem
- 31% of the rural population must travel >30 km for nominal healthcare; in remote areas, up to 100 km.
- Result: avoidance of care, delayed treatment, catastrophic expenses – ~100 million people fall below the poverty line every year due to healthcare costs.
- Government runs a vast network (sub-centres, PHCs, CHCs, district hospitals) but faces disconnects: doctors and infrastructure are hard to sustain in scattered villages (6 lakh+ villages, ~1,200 population each).
- Attempts to post doctors to rural areas have repeatedly failed for genuine reasons.
Initial Product and Pilot
- Sawarkar and Kumar aimed to plug into the existing kiosk ecosystem. They consulted doctors (Apollo, Vellore) who specified required parameters: temperature, blood pressure, pulse oximetry, stethoscope, ECG.
- The operator (local entrepreneur) assisted the patient and operated the device. The remote doctor conducted a video/audio consultation, viewing vital signs and an electronic medical record.
- Early prototypes had to handle:
- Electricity fluctuations (rural power supply with surges, limited hours).
- Fear of electric shocks among villagers – device was designed to run on battery, charged off-grid.
- Low bandwidth (32–64 kbps) – they built a stamp-size video conferencing (QSIF, 15 fps) that worked on that constraint.
- Pilot in Tamil Nadu: technology worked well, but traffic collapsed after the first week. Reason: no medicine at the kiosk. Patients had to walk 3 km to a pharmacy anyway, so they bypassed the teleconsultation. Ecosystem was missing.
Exam tip: A product can be technically perfect but fail if the surrounding ecosystem (pharmacy, lab, referral) isn't in place. This is a classic "ahead of its time" case.
Realisations and Evolution
- The company faced a critical decision: abandon or solve the ecosystem gap. They chose the latter, shifting from a pure business mindset to working with the development sector.
- Discovery of Janani (later World Health Partners – WHP), an NGO that used cross-subsidisation and private providers to deliver non-incentivised services (e.g., contraceptives). This taught them that processes are technology – not just hardware.
- Key insights:
- Aggregation of services: land records and healthcare don't mix (different populations, sensitivities). Health + education works better.
- Quackery risk: operators began diagnosing and prescribing on their own. Solution: usage-aware devices that work only when connected to the system, recording every use and preventing standalone operation. All Neurosynaptic devices are connected devices.
- Medicine delivery: studied what reaches villages daily – not newspapers, but Coca-Cola supply chain. They set up bus-route pharmacies (tie-up with Piramal Group) where prescriptions were sent via bus to a central pharmacy and delivered back.
- Lab integration: tied up with local labs to pick up samples and upload results online for follow-up visits.
- Doctor incentives: a mix of social motivation and financial payment. Many doctors wanted to contribute but needed a convenient platform. The biggest hurdle was acceptability of telemedicine by the medical community – resolved only after COVID-19.
The Bihar Program (2008–2016)
- With WHP and funding from the Susan Thompson Buffett Foundation, Neurosynaptic implemented the first large-scale telemedicine program: 1,300 centres in 21 districts of Bihar.
- Operated through Registered Medical Practitioners (RMPs) and their spouses, who were private providers cross-incentivised.
- Core disease pillars: leishmaniasis, childhood pneumonia, diarrhoea, tuberculosis – all linked to government referral systems.
- Telemedicine was the incentive for RMPs: one out of ten RMPs was selected to run the Sky Health Clinic (telemedicine centre), raising their prestige in the community.
- Entire ecosystem built:
- Sky Meds: 10,000+ pharmacy supply chain.
- 500–600 labs integrated for sample pickup and online results.
- Referral hospitals (secondary and tertiary) linked via training and patient flow.
- Connectivity used BSNL DSL lines under the Universal Service Obligation Fund (USOF), providing 64 kbps uplink/downlink – enough for Neurosynaptic’s low-bandwidth system.
- Two central medical facilities (Delhi, Patna) each housed 20–30 doctors (GPs and specialists) providing continuous care.
- Checks and balances were built into the entire system to prevent misuse, with product evolution from peer-to-peer (one doctor, one clinic) to a centralised multi-centre model.
- Program wound down in 2016 when the disease-specific goals ended, but it proved the technological and operational model.
Key Takeaways
- Neurosynaptic started as a neurotechnology venture but pivoted to rural telemedicine after recognising a larger, unmet need – healthcare access at the last mile.
- Profit-making, not profiteering is the guiding philosophy: systems must be self-sustaining via profit, but profits must not exploit stakeholders.
- Ecosystem > technology alone: the first pilot succeeded technically but failed because medicine and labs were missing. Solving the entire ecosystem (pharmacy, lab, referral, training) was essential.
- Usage-aware connected devices prevent quackery by requiring constant online connection – a key product innovation.
- Low-bandwidth innovation (video conferencing at 32–64 kbps) was critical in an era of poor rural connectivity.
- Cross-incentivisation and private provider models (learned from WHP) allowed large-scale, efficient deployment without relying on government infrastructure.
- Telemedicine acceptance was a major barrier until COVID-19 changed perceptions.
Product Evolution: From Cabled Box to Wireless Kit
Intuition: Building a medical device for rural India is not a one-shot design. The product must evolve through continuous field feedback — what works in a lab often fails when handled daily by operators with varying skill levels.
Neurosynaptic’s first device (ReMeDi) started as a single box with 4–5 parameters, each measured via a dedicated wired connector (USB-like, but with different connectors per measurement). This led to frequent cable failures: operators would pull cables, insert them into wrong slots, or damage connectors. The result was an excuse for non-use — when a device is non-earning, operators quickly blame hardware.
Hardware iterations:
| Version | Key Change | Rationale |
|---|---|---|
| V1 (metallic box) | Cable-based, lead-acid battery | Initial prototype, no product experience |
| V2 (plastic) | Lighter casing | Cheaper, easier to produce |
| V3 (ready-made moulds) | Used off-the-shelf box | Moulding custom boxes was prohibitively expensive |
| V4 (no battery, USB power) | Removed internal battery | Reduced cost and failure point |
| V5 (wireless hub) | Hub connected to sensors via USB cables | Intended to fix cable problems but introduced more wires between hub and sensors — failed in field |
| V6 (fully wireless, separate devices) | Each sensor is an independent Bluetooth Low Energy device | Eliminated cables entirely; each device has own processor, connectivity, mould. More expensive but gives customer choice |
Key learning: The wireless hub version (MDoc) was a failed experiment that taught the team what not to do. The next wireless version succeeded because they had clear understanding of failure modes.
Software evolution: Peer-to-peer → client-server (on-premise) → cloud-based SaaS (by 2017). SaaS enabled pay-per-use and remote management.
Exam tip: In low-resource settings, “reported problems” may be excuses for lack of revenue. The real test is whether the problem disappears when the device becomes profitable. Always cross-validate user feedback.
Key takeaways
- Product design must account for operator behaviour – cables are fragile, connectors are misused.
- Feedback filtering is critical: distinguish genuine problems from excuses by testing alternative designs.
- Wireless solved cable failures but required separating devices → increased cost but added flexibility.
- Software architecture evolved from peer-to-peer to cloud SaaS to support scale.
- Each iteration was driven by field experience, not pure engineering.
R&D Strategy: Grants as a Risk-absorbing Fuel
Intuition: For a deep-tech health startup with long cycles, equity dilution is painful. Grants provide non-dilutive capital to develop risky innovations while preserving ownership.
Neurosynaptic’s model:
- R&D funded entirely by grants – never from debt or equity.
- Revenue from device sales + software licenses used for operations, not product development.
- Equity used only for market development and scaling.
Concrete grant journey:
| Grant / Award | Use | Outcome |
|---|---|---|
| Grand Challenges Canada (Stars in Global Health) | Funded 3 technology developments | One led to Millennium Alliance, one to DBT |
| Millennium Alliance | Automated motorized microscope | Prototype built, but not launchable – operator could not focus slide reliably due to internet delay; scanning time too long |
| Department of Biotechnology (DBT) – Spurge grant | Optical rapid test reader + third version of ReMeDi | Successful product iterations |
| DBT – later grant | Fully wireless kit | Completed product now in field |
Why grants work for this sector:
- High risk of failure (many products discarded).
- Long time to market (regulatory, clinical validation, field usability).
- Government grants also provide brand credibility (e.g., DBT funding signals quality to other stakeholders).
Exam tip: In impact sectors, grants are a strategic tool, not charity. They allow you to “fail fast” without destroying the company. Always apply for grants that align with product development milestones.
Key takeaways
- Grants are the primary R&D fuel for many health-tech startups.
- Multiple failures are expected – only 1 in 3 grant-funded ideas becomes a viable product.
- Government grants also serve as endorsement for later fundraising.
- Separate financing sources by activity: grants for R&D, debt for working capital, equity for market expansion.
Product Failure & Abandonment Decisions
Intuition: The hardest entrepreneurial skill is knowing when to kill a project. Attachment to sunk cost is dangerous when resources are limited.
Neurosynaptic’s approach to abandonments:
- Conduct usability studies in adaptable centers.
- Define parameters: ease of use, utility vs. cost, stakeholder needs.
- If the product will not be accepted by the market → put it in cold storage rather than launch a failure.
- Key mantra: The market decides.
Example – Automated Microscope:
- Goal: Enable remote pathology (TB, malaria) by attaching a camera to a low-cost microscope, with doctor guiding operator via video.
- Problem: Internet delay → operator overshoots focus; scanning entire slide for TB takes enormous time.
- Outcome: Working prototype, but not “happy” → never launched.
Example – MDoc wireless hub:
- Attempted wireless by having one hub connecting to many sensors via USB.
- Result: more wires, more failure points → sold a few units, but not field-worthy → abandoned.
Emotional dimension: Founders do get attached, but limited resources force ruthlessness. It's better to preserve cash for future opportunities than to waste it on a doomed launch.
Exam tip: “Pivot” is overused. Sometimes the right decision is to stop a product line entirely. Ask: Is the market ready? Is the unit economics viable? If not, shelve it.
Key takeaways
- Abandonment decisions should be data-driven (usability, time, cost, stakeholder acceptance).
- Sunk cost fallacy is dangerous – the market, not past investment, determines the future.
- “Cold storage” allows keeping IP for later when technology or ecosystem matures.
- Multiple failures are part of the innovation process; celebrate learning, not just launches.
Shift from Technology Provider to Service Provider
Intuition: Selling a device once generates 1× revenue. Running a service (telemedicine + diagnostics) using that device generates 12–13× annual recurring revenue, plus deep customer insight.
The transition:
| Phase | Business Model | Revenue Nature | Customer |
|---|---|---|---|
| 2004–2019 | Device + software license | One-time + recurring license | Partners (NGOs, hospitals) |
| 2019 onwards | Full-stack service (nurse + doctor + devices + medicine) | Annual per-center revenue (SaaS + O&M) | Government / Foundations |
Catalyst for change:
- HCL Foundation project (2019) insisted on operationalization – they wanted a partner to run centers, not just supply tech.
- Neurosynaptic took the leap: set up 2 centers, then 13, serving >1 lakh patients/year, 35 teleconsultations per center per day.
- Result: Predictable revenue, direct patient feedback, and a scalable unit model.
Why it works better:
- Customers (government, CSR) understand “we will provide healthcare” more easily than “here is a box and software”.
- Services create a stickier relationship – daily interaction means problems solved in real time.
- Technology becomes a small fraction of total revenue (3–4%), but the service annuity multiplies revenue.
Exam tip: For any hardware startup: ask if you can wrap a service around the product. Services often have higher margins, recurring revenue, and deeper moats.
Key takeaways
- Product + Service business model can generate 12× more revenue per customer than product alone.
- Services provide predictable cash flows and direct customer insight.
- The shift requires new capabilities (hiring nurses, managing field ops, logistics) – but those are learnable.
- In rural healthcare, “running centers” is more understandable and fundable than “selling devices”.
Regulatory Environment for Medical Devices
Intuition: Medical devices are not like consumer electronics. They require certification to ensure safety and efficacy. In India, regulation was absent, then gradually formalized – a huge shift that now provides a level playing field.
Timeline of Indian medical device regulation:
| Year | Event | Impact |
|---|---|---|
| Pre-2017 | No CDSCO framework; DGFT issued “free sale certificates” loosely | Uncertified devices sold alongside certified ones – no comparison |
| 2017 | CDSCO began registration process | Manufacturers had to self-register |
| 2019 | Formalization of regulation | Standards (ISO 13485, IEC 60601) became mandatory |
| 2021–22 | Active enforcement; time given for compliance | Level playing field; earlier uncertified devices cannot claim equivalence |
Risk classification:
- Type A & B (low risk): certified at state level (~6 months).
- Type C & D (critical care): certified at central level (~1 year).
Global standards:
- FDA (USA) and CE (Europe) are the most widely accepted.
- India’s base standards (ISO 13485, IEC 60601) are aligned with FDA/CE.
- Some countries (Russia, China, Japan) have their own standards – need separate registration.
Practical lesson:
- Start regulatory planning from Day 1 – it can make or break your product.
- Example: A company making a vaccine cold-chain device was stopped from selling because they lacked certification – only later realizing they didn’t need it for that customer.
- Free sale certificate (FSC) – needed for export; until 2022, issued by DGFT, now by CDSCO (properly recognized as medical device).
Exam tip: In any regulated sector (health, energy, transport), certification timelines and costs must be baked into your product roadmap. Underestimating regulatory can kill your startup.
Key takeaways
- Medical device regulation in India became formalized from 2017 – previously a free-for-all.
- ISO 13485 (quality management) and IEC 60601 (safety) are core standards.
- Risk classification determines approval level (state vs. central) and timeline (6–12 months).
- Regulatory runs behind innovation – always expect gaps (e.g., no AI framework yet from CDSCO).
- Compliance is a competitive advantage – it validates quality against uncertified rivals.
Healthcare Market Dynamics: Primary Care vs. Tertiary Care
Intuition: Healthcare spending is inverted – people will pay any amount for ICU, but almost nothing for prevention. Primary care is a “distributed market” competing with government, making it unattractive for traditional investors.
Continuum of healthcare:
- Spending: Increases exponentially as you move right. Prevention (left) has lowest spend.
- Investor perception: Primary care = government’s job; low margins; long payback; competing with free/subsidized public services.
- Neurosynaptic’s response: Persisted because they believe solving India’s biggest problem (rural health access) will eventually be recognized.
Key external enablers (pre-COVID):
- National Health Authority (NHA) – established ~2016–18; mandate for digital health interoperability.
- Universal Health ID (UHID) – now ABHA under Ayushman Bharat Digital Mission (ABDM).
- Milestones (M1, M2, M3):
- M1: Generate universal health ID.
- M2: Generate health records in interoperable format.
- M3: Read any patient’s interoperable record.
- RSBY / PMJAY – insurance for workers → expanded to Ayushman Bharat.
- Jan Aushadhi – affordable generic medicines.
- Ayush bridge course – allows Ayush doctors to practice allopathy partially.
- Telemedicine guidelines (March 2020) – gave legal standing, removed fear.
Why COVID changed everything:
- Doctors overcame fear of telemedicine – they had to use it.
- Telemedicine became legally recognized.
- Patient acceptance surged.
- But opportunistic players (post-COVID startups) often collapsed because they lacked the long-term infrastructure (like bamboo – grows underground for years before shooting up).
Exam tip: In impact sectors, the market may not be ready when you start. You must survive until the ecosystem catches up. That requires financial discipline and patience.
Key takeaways
- Primary care is under-monetized but essential – the spending curve is the opposite of value.
- Policy changes (insurance, UHID, telemedicine guidelines) are major tailwinds.
- Surviving until “right time” requires grants + conservative growth + multiple revenue streams.
- Many startups collapsed post-COVID because they were opportunistic, not foundational.
International Expansion Model
Intuition: Entering regulated foreign markets alone is expensive. A partner-based model reduces risk.
Neurosynaptic’s approach:
- Technology partner for overseas territories – local company handles liaison, business development, implementation.
- Neurosynaptic provides: product, SOPs, training, train-the-trainer programs (local language).
- Example – Panama: Product registered via CDSCO + CE certification → local partner won a ministry project → 25 centers now, expanding to 40+.
- Papua New Guinea: initial deployment, scaling statewide.
Key enabler: Indian regulatory compliance (CDSCO, CE) is accepted in many countries, reducing duplication.
Exam tip: International expansion is not a revenue shortcut – it requires prior regulatory work and a reliable local partner.
Key takeaways
- Use local partners for distribution and implementation.
- Regulatory certifications (CDSCO, CE) open doors to many countries.
- Start small: one country project, then scale based on results.
AI in Healthcare: Process vs. Diagnostics
Intuition: AI is not a magic wand. For a rural health startup, the most valuable AI improves processes (quality, efficiency) before it replaces diagnostics.
Two AI tracks at Neurosynaptic:
-
Process AI (launching soon):
- Assistants for nurses, doctors, medical directors.
- Audit quality of care – how well are consultations being done?
- Tune service delivery.
-
Diagnostic AI (in development, partnering):
- Use retinal images to detect retinopathy/glaucoma.
- Oral cancer screening via phone camera (partner with Niramai, IISc).
- Neuropathy, nephropathy assessment.
- Philosophy: Not reinventing the wheel – partner with best-in-class AI companies.
Key partnership: National Centre of Excellence for AI in Healthcare (IISc) – focus on high-sensitivity screening (detect all possible cases, even at cost of false positives).
Exam tip: In resource-constrained settings, high sensitivity (catch all potential cases) is more important than high specificity. Missed diagnoses are more harmful than unnecessary follow-ups.
Key takeaways
- AI should first improve operations (auditing, assisting) before replacing clinical judgment.
- Partner for diagnostic AI rather than building in-house.
- Screening applications prioritize sensitivity over specificity.
- Avoid the “AI bubble” – build useful, focused solutions, not hype.
Entrepreneurial Lessons from a 20-Year Journey
Intuition: Building a venture in a difficult sector requires patience, humility, and a long-term perspective. Quick riches are the exception, not the rule.
Key mental models:
| Lesson | Practical Implication |
|---|---|
| Survive until the market is ready | Use grants, conservative growth, multiple revenue streams |
| Cash is king | Cash flow management is the #1 skill |
| Market decides | If product isn’t accepted, shelve it – don’t force it |
| Moderate growth | “If you grow too fast, you collapse too fast.” Grow the whole organism (delivery, support, systems) |
| Unit economics first | Before scaling, prove one unit is profitable and sustainable |
| Bamboo tree | Years of underground root growth → then explosive visible growth |
| Solve our own problems | Imported solutions don’t fit India; we must build indigenous models |
| Different financing vehicles | For-profit, Section 8, NGO – pick the right vehicle for each activity |
On giving up: Founders often have unrealistic expectations. The win and defeat can feel the same – you trade one set of problems for another. Persistence is key, but must be directed by validation from the field.
Exam tip: When evaluating a startup opportunity, ask: “What is the unit model? How long can the company survive without external funding?” The answer reveals risk.
Key takeaways
- Persistence is mandatory, but it must be paired with learning from failures.
- Financial discipline (grants for R&D, debt for working capital, equity for market) is a strategic choice.
- Growth must be balanced – scale capacities alongside market reach.
- Impact sectors require long time horizons – the bamboo tree analogy is accurate.
- India’s startup ecosystem is now supportive (recognition, MSME benefits, grants) – ideal for solving homegrown problems.
Product Management vs. Project Management
Product management answers what to build—understanding customer pain points, defining features, and setting the product roadmap. Project management answers how to build—scoping deliverables, timelines, and ensuring execution follows plan.
| Aspect | Product Management | Project Management |
|---|---|---|
| Focus | What to build (features, strategy) | How to build (timelines, resources) |
| Core activities | Customer discovery, prototyping, roadmap | Scheduling, task tracking, delivery |
| Key question | Why build this? For whom? | When will it be done? Who does what? |
The two roles are converging. Most product managers now also handle project management tasks. When you understand both the product and the team’s capability, you give better timelines and feasibility assessments.
Key takeaways
- Product management = “what to build” (strategy, customer needs)
- Project management = “how to build” (execution, timelines)
- Industry trend: roles merging; PMs increasingly own both.
Real-World Product Examples
Lending Product (NBFC – Riya)
A credit product involves deciding which customers to lend to at scale. The core challenge is risk underwriting – determining creditworthiness using data.
- Data sources: bureau data (credit score), behavioral parameters (spending habits, past records), and account aggregators (cross-institutional loan history).
- Product-to-customer fit happens via multiple channels:
- Direct lending (B2C)
- Partner cross-sell (e.g., Bajaj Finance + Reliance Digital → no-cost EMI customers)
- Customer journey stages: offer, data collection (PAN, bank account), final approval – each stage runs checks.
- Risk signals are data points (e.g., previous default) inserted into the journey. Steps:
- Data scientists analyze sources → identify significant variables.
- Test on historical data (improve detection of defaulters or upsell opportunities).
- Locate where in the journey the data is available → place the check.
- Check redundancy with existing signals.
- Live refinement: After launch, analyze rejection rates per segment → adjust thresholds or provide alternate offerings. Balance risk vs. business: too tight → no loans; too loose → defaults.
Capital Planning Product (B2B Government – Aviral)
A capital planning product helps US government agencies forecast budgets, enter funds, and identify shortfalls. Key priority for public sector: utilise allocated funds (avoid lapsing) rather than ROI.
- Legacy product (20+ years) being broken into next-gen products (capital planning, build phase, etc.).
- Prototyping approach: End‑to‑end prototype (99% of product – frontend, backend, database) built in 6 weeks; sales teams demo it to customers before the actual product is ready. This accelerates onboarding.
- Feature discovery: Government clients issue RFPs (Request for Proposals) – these reveal requirements. Product managers demo the prototype, collect feedback, and shape the roadmap.
- Example AI feature: Natural‑language scenario planning – user prompts “prioritise projects with ROI >15% within budget” → AI returns a prioritised list.
- Compliance: Government customers require compliance checks (e.g., accessibility for disabled) – PMs run scans, fix issues, and iterate.
Key takeaways
- Lending PM: risk signals, data-driven policy, scale, compliance‑first.
- Capital planning PM: fund utilisation, RFP-driven, end‑to‑end prototypes, AI enhancements.
- Both roles require deep data understanding and stakeholder management.
Product Development Process
From Idea to Launch
- Identify need: Customers (directly or via RFP), legacy product insights, or market observation.
- Build prototype: Rapid, end‑to‑end (not just UI) – used for demos before full product is ready.
- Demo & feedback: Sales team sets calls; PM presents prototype; customer feedback defines roadmap.
- Iterate: Monthly releases; continuous customer touchpoints.
- Compliance & scale: For government – security, accessibility; for lending – regulatory compliance (e.g., data privacy).
PRD (Product Requirements Document)
A PRD scopes all requirements for a feature – constraints, actions, what user should/should not be able to do. In a lending context, it covers:
- Functional requirements (from business team – balance risk vs. business)
- Data requirements (from data science – available data points, feasibility)
- Technical design (from engineering – integration with existing systems)
All three must align to achieve the product goal.
Team Structures
| Structure | Description | Example |
|---|---|---|
| Pod structure | Cross‑functional team (engineers, PM, designer, QA) working on one product/feature. | Aviral’s experimental team → replicated to whole org after success. |
| Functional + divisional | Functions (product, tech, data science, HR) each divided by product line. | Riya’s company: analytics team has sub‑teams for product one, product two, etc. |
Stakeholder management is critical – PMs interact with business, risk, data science, and CXO levels to align on product decisions.
Key takeaways
- Pod structure enables fast, cross‑functional execution.
- Functional+divisional provides deep expertise per product.
- PMs must navigate multiple stakeholders to achieve consensus.
Evolving Role: Technical & Data Skills
Modern product managers increasingly need hands-on technical or data capabilities:
- Aviral: codes end‑to‑end prototypes (uses Cursor, Claude Code). Technical understanding earns engineers’ respect, improves communication, and helps manage AI products.
- Riya: data engineering background → works as data product manager. Queries databases, performs analysis, and can substitute for data analysts when needed.
Exam tip: The PM role is shifting from “product specifier” to “product builder” – especially in startups and AI‑focused teams. Expect interview questions testing technical depth (system design, AI concepts).
Impact of AI on Product Management
AI affects PMs in two dimensions:
- Personal workflow (how PMs work)
- Product features (what PMs build)
And can be classified by augmentation (human‑in‑the‑loop) vs automation (AI alone):
| Augmentation | Automation | |
|---|---|---|
| Personal workflow | AI‑assisted meeting notes, drafts, research | Recording → structured document → Notion |
| Product features | User interacts with AI to explore options | Agent performs task autonomously (e.g., scenario planning) |
AI in Personal Workflow (Aviral’s Example)
- Meeting transcription: Recordings → Claude Code → structured document in Notion (via MCP server). PM can later query: “What was decided about feature X?”
- PBI (Product Backlog Item) creation: Claude Code, using meeting context, generates PBIs and pushes to Azure DevOps.
- Workshops: Aviral conducted training for 20+ PMs to adopt Claude Code.
- Key principle: Human must be in the loop to validate AI output (non‑deterministic).
AI in Products
- Scenario planning agent: Uses legacy data (golden datasets) to validate AI responses. Requires evals (evaluation), latency/cost monitoring, and explainable AI to build trust.
- Agent architecture: Orchestrator agent breaks task into sub‑tasks → sub‑agents execute → report back. PM manages cost, latency, trust, and monitoring.
- Pricing challenges: AI costs are high; even big players (ChatGPT) are not yet profitable. PMs must rethink pricing models.
- Build vs. buy: Organisations should experiment with closed models but also build open‑source infrastructure to avoid vendor lock‑in (e.g., Anthropic restricting third‑party tool usage → switch to Codex + orchestrator).
Shelf Life Changes
- Products ship faster (execution has become cheap).
- PM role is not disappearing but evolving into agent manager – managing AI agents, their costs, latency, and trust.
- Judgment is the new moat – AI cannot yet replace product judgment.
Key takeaways
- AI impacts PMs both in workflow automation and product capabilities.
- Human‑in‑the‑loop is essential; full automation risks losing differentiation.
- PMs must understand agent architecture, cost management, and evals.
- Don’t depend on a single AI tool or vendor – build flexibility.
Advice for Aspiring Product Managers
Foundational Skills
- Product fundamentals: Solve cases (e.g., “What is your favourite product and how would you improve it?”). Use case books from product clubs.
- Stay updated: Follow AI news daily (Anthropic, OpenAI, etc.). Use agents (e.g., OpenClaude) to curate updates.
- Build unique perspectives: Leverage your background – psychology, data, coding, economics – to differentiate.
Practical Roadmap (for young students)
- Identify a daily pain point (e.g., meeting context loss).
- Use an AI tool (Lovable, Cursor, Claude Code) to build a rough prototype.
- Iterate with feedback from friends/colleagues.
- Scale – host, add authentication, handle multiple users.
- Research existing solutions – don’t build in isolation; improve upon what’s out there.
Personal Journey Insights
- Riya: Try multiple fields and discard what doesn’t work. Civil engineering → data engineering → finance → product management. Narrowing down by elimination is effective.
- Aviral: Passion from early age (web development) → clear clarity. Built technical foundation (IIT Kanpur, Bajaj Finserv, cloud certification) then moved to product management to answer “what to build.”
Exam tip: For product management interviews, be ready to discuss your unique angle (e.g., “I bring a psychology perspective to customer experience”). Also, demonstrate how you use AI tools to build and validate ideas.
Key takeaways
- Fundamentals (cases, design thinking) still matter, but AI knowledge is now expected.
- Differentiate by combining product skills with a specific domain or technical depth.
- Practical building (even small prototypes) teaches the product lifecycle faster than theory.
- Stay adaptable – avoid over‑reliance on any single AI tool or vendor.