Healthtech teams are rarely short of feedback. The harder problem is turning it into evidence that somebody can act on.
A clinician may describe a confusing graph. A service user may report that the app takes too long to load. Delivery may see people drop out during onboarding. Engineering may need exact steps, device details and expected behaviour before it can investigate.
All of those perspectives can be true, but they do not automatically form a usable product decision.
Build routes for feedback to travel
At CareLoop, I worked across implementation, live-service support, product operations and QA. That position made it possible to follow an issue from the point where it was experienced to the point where it could be prioritised and tested.
I used a mixture of user interviews, clinician conversations, feedback forms, service data and direct observation. The goal was not to collect the most feedback. It was to understand the journey around each issue:
- Who experiences it, and in what context?
- Is it a one-off defect or a repeating pattern?
- Does it affect usability, adoption, data integrity or clinical workflow?
- Can we reproduce it reliably?
- Is the right response a product change, clearer training or a different operating process?
Make the problem reproducible
Frontline language and development language are different. A useful bridge preserves the user’s reality while making the issue specific enough to investigate.
That meant reproducing bugs across the app and portal, checking different environments, capturing the sequence that led to the problem and writing actionable Jira tickets. It also meant supporting regression, smoke and release testing so that a fix could be validated in the workflow where it mattered.
In one period of mobile app testing I identified 11 defects. Elsewhere, investigation exposed data-integrity risks around user identifiers and provider assignments, along with issues affecting historical alert reviews. These were not abstract quality concerns; they could change what a clinician saw and trusted.
Use realistic data
Empty demo accounts and perfect test cases hide a surprising amount of friction. I created populated test and demo data so the platform looked more like a real longitudinal record.
One demo set used eight accounts and more than 400 data points. Later, I created a script to populate realistic submissions automatically. That made demonstrations more credible, but it also helped surface performance and workflow problems that were difficult to see in a nearly empty account.
Realism is valuable in QA because users do not experience features one at a time. They experience a growing history, imperfect connectivity, repeated alerts and the consequences of earlier actions.
Close the loop
Feedback is only trustworthy when people can see that something happened because they shared it. Not every request should become a feature, but recurring themes should influence product priorities, training or the implementation model.
Examples included clearer portal workflows, improvements to graphing, changes to wording, better release checks and a larger pipeline of clinician-facing usability work. The specific output varied, but the method was consistent: listen closely, investigate carefully, translate clearly and return to the live service to see whether the change helped.
Product operations in digital health is often this connective work. It is the discipline of preventing valuable insight from becoming stranded between users, delivery teams and developers.