In fall 2020, I got a flustered phone call from a product owner at a US hospital system after a Zoom meeting. “This happens with every project,” they complained, “Everyone wants to put their finger into the pie, and in the end no one wants a slice.”
2020 was a year of digital transformation, and a year of growing pains. From pitch to scoping to implementation, tech companies and hospitals often don’t see eye-to-eye on best practices. How can hospital and tech company teams work together to implement beneficial solutions while mitigating high risk and turning inertia into momentum?
Syllable improves patient access to care using voice and digital interfaces. We’ve automated millions of hospital voice and digital interactions for top 20 hospital systems in the U.S. Last year, Syllable launched the first COVID-19 patient triage digital assistant and the first COVID-19 plasma donation digital and voice assistant in just a few weeks at some of the leading health systems in the country.
When we work with hospital teams, we follow two guiding principles that enable rapid and successful technology implementation:
Principle #1: We do user research and gather data to align on how patient experience can be improved
Technology projects often build without researching patients’ pain points. But without data on the problem, project teams can’t align on relevant metrics and desired impact of the solution, and communication to leadership will be shallow. A more successful approach starts from understanding the problem, framing V1 of your solution as a hypothesis, then adjusting based on real user data.
For example, when leadership tasks you to “perform outreach for annual physicals, colonoscopies, and mammograms,” drive toward a problem statement, not a solution. Ask yourself: What’s the current workflow? What pain does it create and resolve? Why do outreach now?
You might begin by surveying patients to see why they’ve skipped their annual procedures and discover they’re unaware that procedures have restarted, or that their insurance has lapsed. Learning about the patient experience helps you drive to a problem statement. This enables you to state the purpose and impact of your outreach project in terms of the problems it solves.
This makes a big difference. In our example, without user research, you might interpret “success” only as outreach that converts into a scheduled appointment. By understanding pain points, you uncover a broader definition of success. Raising awareness of available appointments, showing users how easy scheduling is, and informing patients of financial resources may each impact the goal leadership identifies. This is not scope creep; quite the opposite, it is determining scope by understanding all the necessary solutions that drive toward a goal.
Principle 2: We use the data we gather to navigate the organization toward success in the implementation process
Clearly understanding patient pain points doesn’t necessarily mean you can solve the problem. However, it does help you take the right next steps during implementation to generate value for your patients and organization.
1. Ensure the data from your V1 launch has no major data deficiencies.
When piloting or testing, product owners often focus on whether the product works for the user, and miss whether the data works for them. Ask questions, poke around the data, and make sure you have everything you need before putting the solution out in the wild.
2. Change your approach based on new understanding.
As you scale the rollout to your solution, spend time understanding what your gathered data say about the project impact on the user pain point. If at first results aren’t promising, go into the weeds on data. If engagement with outbound calling is low, are you calling on the optimal times of day, and days of week? Are the numbers you are using old land-lines that are now in disuse? For small software projects, this is the point to change your approach, not before. As rollout continues,
3. Limit design-by-committee and scope creep.
User data is your primary tool here. Projects fail for only one reason: because they are solutions without problems. If you take steps to understand patient experience and create hypotheses, you’ll have set up a good launching pad for when the project is funded and roadmapped. Against personal opinions and imagined scenarios, your best protection is being the foremost data expert on your patients and their behaviors, expectations, and experiences. You should likely respond either with, “The data show…”, “We can gather data,” or “That is out of scope.” If you ever hear speculations past the data gathering phase, the hair on the back of your next should stand on end.
The Moral of the Story
By learning about the patient’s pain point, thinking in terms of hypotheses instead of “moonshot” solutions, and managing stakeholder input to be data-driven and focused on solving that specific patient pain point, risk is minimized to your project, you are more likely to land on an effective, long lasting solution that will inform you with data when the solution is deteriorating or patient behaviors are changing, and all this will benefit patients and hospital teams.
