Selected product work

Product Work

My work as a Product Owner spans two years in a highly collaborative startup environment, where I had the opportunity to work closely across product, design, development, marketing, and management. The flexible work culture gave me creative freedom and independence, which meant I had room to learn, explore, and take on work across different areas. Here, I aim to shed some light on a few important areas of my Product Owner work so far.

The Layers of My Product Owner Work

My Product Owner role was multi-faceted and involved bringing several skill sets together. It pulled me into product thinking, research, team coordination, customer conversations, content, reporting, and execution, often all at once. Many of these responsibilities were new when they first came my way. This is how I brought clarity into my role: I learned to figure things out, ask better questions, bring energy into unclear situations, and do what the product or team needed at that point in time. Over time, this role also helped me understand something about myself: I learn quickly, I enjoy solving messy problems, and I naturally bring a product-first lens to the work I take on.

Coordination, communication, and team alignment

One layer of my Product Owner work involved acting as a link between the Product Manager and the rest of the team. This included supporting sprint planning, organizing sprint meetings, prioritizing tasks, solving bottlenecks, filling gaps, and refining the strategic direction of the product so the team could stay aligned with the product vision and business priorities. I also helped turn business priorities into structured direction for the team, while planning and presenting quarterly meetings, tracking KPI metrics, and monitoring OKR progress.

Product research, requirements, and module planning

Another layer was focused on the product itself. This involved looking at the product through a diagnostic lens, studying healthcare SaaS workflows, researching the compliance landscape in India, drafting functional requirements, researching new product features, and designing module concepts. It also included competitor analysis, pricing research, product marketing research, backlink strategy research, and outreach emails for backlink opportunities.

Customer demos and feedback

As part of the role, I also worked directly with customer-facing activities such as giving product demos to interested customers, sending cold emails and messages, making cold calls, and preparing questions for customer feedback interviews.

Content and product marketing support

A fourth layer involved content marketing for DocHours. I handled social media content planning, created content calendars, formed ideas for posts, wrote content for the product's social media handles, and created an email campaign for DocHours.

Selected Work

A closer look at a few focused pieces of product work, with enough context to show the thinking without exposing internal documents in full.

ABHA/ABDM Readiness Research

Requirement / problem

One of the biggest gaps in healthcare delivery is the lack of continuous care. Even after digitisation, patient records often remain scattered across separate systems, making them difficult to access outside the clinic, hospital, or software where they were created. For an Indian clinic management platform like DocHours, ABHA/ABDM integration felt important because it points the product toward consent-based, unified patient records and keeps it aligned with where digital healthcare in India is moving.

How I approached it

I studied official ABDM/ABHA resources, sandbox documentation, API flows, certification references, and explanatory videos to understand the road before implementation. My research covered ABHA creation and linking, ABHA address verification, HIP/HIU/HRP roles, consent manager and consent artefacts, HPR/HFR registration, sandbox milestones, profile matching for new and returning patients, access-control implications, auditability,FHIR alignment, and the sandbox-to-production path.

What I documented

I documented an ABHA/ABDM overview presentation for the team, a DocHours compliance roadmap, certification and sandbox-exit notes, milestone-level API notes, consent and access-control implications, and product considerations for patient record linking, role permissions, audit trails, and future health-record exchange, with notes on why compliance readiness matters for product trust.

Workflow redesign / reconciliation planning

Invoice & Revenue Reconciliation Module

DocHours had a basic invoice page with a long list of billed services, no reconciliation summary, no export flow, and search that depended mainly on Invoice ID. The redesign was meant to make the invoice module useful for daily clinic operations: not just "find an invoice," but understand daily billing and collections at a glance.

Designed to answer

How much was billed today?
How much was collected today?
Which invoices are fully paid, partially paid, unpaid, or refunded?
How is collection split across Cash, UPI, Card, Other, and Refunds?
Which invoices need attention?

What existed before

The current page showed patient info, invoice ID, date, physician, and a view action. It did not show amount columns, paid/due/refund visibility, payment-mode split, reconciliation summary, doctor or department filters, export workflow, or an edit action.

How I approached it

I referred competitor invoice and revenue workflows, studied the gaps in the existing page, created a Figma prototype, and documented the module through acceptance criteria, business rules, status logic, and a phased implementation plan.

What the new module covered

The planned scope included a default Todayview, top summary cards, payment-mode breakdown, date, doctor, department, payment mode, and invoice/patient search filters, table columns for billed, paid, due, refund, payment mode, status, and actions, plus downloadable reports inside the Report Center.

What I documented

The documentation covered paid, partial, unpaid, and refund handling, invoice edit and locking rules, audit history, admin/owner visibility, and financial integrity checks. It also mapped impacted frontend and backend areas, invoice model updates for Other payments and refunds, computed values such as total paid, balance, and net collection, API filters, a reconciliation-summary endpoint, Report Center exports, sprint-wise delivery tasks, QA checks, and clear non-goals so the module did not expand into a full accounting system.

Research input / doctor usability / clinical coding

Consultation Module, EHR & Clinical Coding

For the Consultation Module, the main visual design was handled by the designer. My role was to bring more clarity into what a module like this should help doctors do during consultation: review the right patient context quickly, reduce documentation friction, and make the screen genuinely useful instead of just visually complete.

What I researched

I referred PubMed/NCBI medical literature, EHR usability references, healthcare UX material, and Indian EHR standards context to study documentation burden, doctor-patient interaction, consultation flow, patient intake, ICD/SNOMED CT handling, and how EHR screens can either support or interrupt a doctor's work.

What it helped clarify

The research pointed toward a Consultation Module view that keeps important patient information easy to scan, avoids too many mandatory clicks, supports quick notes and summaries, and keeps ICD-related complexity from slowing down the doctor during active consultation.

Additional research inputs

I also explored patient intake forms in the Indian clinic context, ICD-code usage, and SNOMED CT/EHR standards as part of thinking through what the Consultation Module should support during implementation, especially around intake information, diagnosis capture, patient summaries, and patient record continuity.

Planning rhythm / reporting / execution tracking

OKR/KPI Planning & Quarterly Reviews

This was the operating rhythm behind my Product Owner work: turning KRs into initiatives, breaking initiatives into team-level tasks, tracking progress during sprint discussions, and preparing quarterly review decks that helped the team see what moved, what stalled, and what needed focus next.

Annual and quarterly KRsInitiative planningTask breakdownSprint progress trackingQuarterly review decksKPI trackingRoadblocks and gapsNext-quarter priorities

How planning worked

The PM planned the annual and quarterly KRs. I worked with team members to break those KRs into initiatives and practical tasks, which were then refined by the PM before finalising the plan.

What I tracked

KR progress was tracked during sprint meetings, while quarterly reviews covered completed work, KPI status, roadblocks, gaps, unfinished priorities, and the work that needed to move into the next quarter.

KPIs covered

Traffic, sign-up conversion rate, active clinics, onboarded clinics, free-to-paid conversion rate, search traffic from GA, and keyword traffic tracked by the SEO analyst.