Building It Isn't Enough: What Driving Adoption Has Taught Me About Solving Problems

Throughout my entire professional career, one of the most rewarding challenges, and really the kinds of challenges I always gravitate to invariably, are just whenever there's a really good problem to be solved. The process of learning about that problem, understanding it, building a solution, iterating on it, and helping to drive adoption of that solution across an audience is a little bit like a drug that I can't quit.

On its face, the work itself might seem very obvious, but it's a cycle that has tied all of my various past professions together into a single throughline. I love being part of a solution, and ensuring that that solution fixes the problem for users. Whether those users are smallholder farmers in Zambia, a full-time medical team for a sophisticated medical camping program, or developers at a Fortune 50 company.

Of course, another throughline in my career has been employing technology to solve problems -- when you're familiar and comfortable with a tool, it tends to be the first thing you reach for, regardless of the problem.

In this thread, I really want to explore what building solutions across fields and within organizations has taught me about driving adoption of any solution, because it's simply never a foregone conclusion that users will readily adopt a solution, even if it actually solves the problem.

Sometimes a Problem Simply Isn't Yours to Solve

Probably for the majority of people, this adage is so self-evident, it doesn't even merit its own subheading. But if you're someone who loves finding and solving problems, this really needs to be a fixture in the back of your mind. And that "sometimes" has the tendency to edge into "frequently" territory, or even "only in rare exceptions."

There are so many examples of relearning this basic truth throughout my career, I probably should have it tattooed on my forehead.

Significantly more powerful than solving another team's or community's problem is creating an environment, platform, and/or connection that gives them the tools to solve it themselves -- teaching a team to fish is a multiplier that will always win out over fishing for them -- and it scales much better as well.

During my time at HCA, we've focused on providing self-service solutions that provide teams with the building blocks they need while still allowing them to understand what is being created on their behalf and how it fits together.

You're Only the Second Best Advocate for Your Own Solution; Satisfied Users are Undeniably the First

I've spoken elsewhere on this site about working to introduce Orange Fleshed Sweet Potato into the Eastern Province of Zambia with a number of local partners. I'll spare you the details, but suffice it to say that they have the very real potential to address some nutritional gaps in diets in that part of the world. However, admittedly, introducing the new crop to previously unfamiliar communities can take some finesse.

During one exercise where I hosted a women's group to share recipes and prepare some orange fleshed sweet potato at my house, some of the village kids eagerly partook of the leftovers from the training.

Early the next morning, I was awoken by one of those kids knocking on my door, alongside his father who he had brought to my house directly. He enjoyed the sweet potato recipes with such delight that he convinced his father that they needed to grow them, and that very season if at all possible.

So a satisfied user, even one only tangential to my audience, was responsible for introducing one of the most prolific orange fleshed sweet potato growers in that entire community.

Treat Every Human Interaction as an Extension of Your Solution's Interface

On the Cloud Platform team at HCA, we maintain a number of platforms used across app teams to deploy their infrastructure and host their apps. Those teams interact with those platforms either directly, or via tools that we maintain to automate their interactions. It's easy to think of this as internal tooling rather than a product, but that distinction doesn't hold up. The moment another team depends on what you've built, they're users, full stop, and the fact that they sit inside the same company doesn't make their experience matter less.

The perceived ease of use and reliability of these tools is of paramount importance, and we spend a great many hours testing to ensure that experience is seamless.

However, issues arise. A user hits an error, or has a question. When that happens, the approach our team takes in communicating with that user is, at that point, probably the most important interaction they can have with our entire tech stack.

Approaching these interactions as an extension of our solutions means several things:

A timely response
A tone that's friendly, personable, and receptive
Communication that's well-written, and well-spoken when the channel calls for it
Regular updates while the issue's being addressed
An explanation of the root cause, and, if possible, a brief description of how it'll be avoided for future users
A follow-up after resolution, to confirm the user's fully past the issue

In an organization trying to improve adoption of its solutions, it's often true that a solution isn't judged by its best moments, but by how a team responds when it fails, especially for users who might otherwise be dismissed as "just internal."