When I came across the World Health Organization’s stat that up to 70% of digital health innovations fail to achieve widespread adoption, I wasn’t shocked. At all.
Yes, the number is high. But after spending the last four years working closely with healthcare providers across Africa, testing tools, rolling out new systems, listening to feedback, I’ve seen firsthand how easily the wheels come off. I’ve been part of projects that didn’t take off the way we hoped. I’ve also seen the minor (and big) missteps that stack up over time until a promising solution just… fizzles.
The good news? Experience is a tough but honest teacher. So in this post, I want to share some of the lessons I’ve learned, the real reasons why healthtech doesn’t stick, and what we can do differently.
We Focus on the Wrong People
When projects kick off, there’s usually a lot of talk about getting buy-in, which is absolutely essential for success. But here’s where we often get it wrong: we focus on getting buy-in from the wrong people.
Too often, the emphasis is on securing support from government departments, political leaders, large NGOs, or someone sitting at a global HQ in Washington, DC. And yes, their backing matters. But once they give the green light, their role in day-to-day implementation (and whether the tool actually gets used) is minimal.
The real buy-in we should be focusing on is from the end users, the people who will actually interact with the tool. Instead, we tend to present them with a final product and expect them to carry the entire project on their backs, even though they were never meaningfully included in the development process. We build for them, not with them.
I’ve made this mistake too. While rolling out a product in Nigeria, I found myself in front of healthcare workers who were hearing about the tool for the very first time, during training. That moment was a wake-up call.
Since then, we’ve changed our approach. At Palindrome Data, we recently conducted in-depth user research to understand providers’ needs and worked with them to co-design the solution. The result? Not only is the product more intuitive and effective, but the users now refer to it as their tool. They feel a sense of ownership, and that’s made all the difference. They want it to succeed just as much as we do.
We’re Too Far from the Ground
Another common mistake in healthtech implementation, one I’ve made myself, is assuming we can offer meaningful guidance and support from the comfort of our home offices. And listen, I love my home office. It’s cozy, my toddler rewards me with hugs for crossing things off my to-do list, and the coffee is always just how I like it.
But the truth is: distance creates blind spots.
Every time I step into a healthcare facility, I’m reminded that many of our well-intentioned ideas don’t always translate on the ground. We design features for workflows we don’t fully understand. We assume certain pain points exist or don’t without ever observing them in action. We’re often just too far removed from the real day-to-day of our end users.
I’ve been on projects where we planned a site visit six months into implementation — only to find that usage was low, and users were confused, frustrated, or simply unaware of the tool. One project had fewer than five consistent users, and we couldn’t figure out why until we showed up in person. Once on-site, we saw the issues immediately: unclear handovers, competing priorities, and low morale. None of that was visible from our spreadsheets or Slack threads.
Being on the ground changed everything. Not only did it give us insight into the barriers to adoption, but it also helped rebuild trust. Our presence signalled that we were there to listen and support, not just monitor. And funnily enough, once we left, remote support became easier, because we had context, relationships, and momentum to build on.
Here’s the thing: consistent presence matters more than perfect planning. Implementation isn’t a one-and-done event. It’s a relationship. And like any relationship, it needs to be nurtured — in person, over time, with real empathy.
We Focus on Building Features, Not Solving Problems
How often do we ask developers, “How far are you with the feature list?” If you’re anything like me, the answer is: way too often.
