A principle I have used in recent years to manage challenges in my life is to love each problem as I’ve encountered them. It sounds odd, I know, but I believe that from there, solutions will follow. I stumbled on this idea while reading a book by Uri Levine, Fall in Love with the Problem, Not the Solution. Levine was a successful entrepreneur who created Waze, a navigation technology to help people efficiently reach their destinations.
What does loving the problem mean to me? Let’s consider my goal for personal fitness. Five years ago, I entered the gym a bit out of shape. I had a clear objective to build and then maintain my strength. Also, I didn’t want this to become a “fad” effort—here today, gone tomorrow.
So, I began by focusing on the problem. How do I get into a routine I will enjoy? Complacency and boredom are a risk for me – How will I manage the risk of ‘fall off’?” I then identified some possible solutions—a well-selected app to help with engagement and a gym where I could meet people who could push and support each other. I made sure to add variation to my exercise routine to stave off potential boredom.
It has worked. By falling in love with the problem, I engineered a solution, and today, I remain an active gym-goer.
Falling in Love with the Problem When It’s Work
I apply this same principle as Vice President of Product Management and Client Services at ClinOne. I think a lot about what I call “responsible development” as we create site and participant-centered solutions. I recall development teams I was part of where systems required a “heavy lift.” One bug might have far-reaching impacts and cascade to multiple updates and fixes of peripheral systems.
My objective in developing new technologies is always the same: ensure it is flexible enough to address multiple use cases, hopefully seamlessly. The solution must be comprehensive without requiring an army of engineers to support it. When users interact with the system, it should feel intuitive and be adaptable as their needs change. Above all, there should be a transparent and elegant design that is human-centered and will motivate usage.
When responsible development is absent, problems happen—problems that go beyond the high costs of maintaining the technology. It becomes challenging to maintain quality. Validation and testing become very burdensome.
As Levine suggested, we need to fall in love with the problem. The product development team needs to ask many questions, which include:
- Does the roadmap make sense to our customers?
- Will the solution be scalable as organizations grow and change?
- Can the system be easily supported by customers wishing to be self-sufficient?
- What does “intuitive” mean to our customers? Is it keystrokes? Logic? What?
- Is the design truly flexible, enabling it to address a wide range of needs?
These questions and more are part and parcel of designing a system “in the right way.”
I have been a part of development efforts that have only sometimes done this. Too many times, we’d want to please the customer by saying “yes” to something we should have said “no” to. I’ve learned we must act with discipline for every customer request to ensure that our work benefits the many. Falling in love with the problem gives us a better chance of helping the many.
At a more granular level, this means speaking with customers to understand how any potential changes would impact them—whether it’s related to workflow, quality, SOPs, reporting, etc. Are we addressing their most pressing and high-impact needs? Customers talk about meeting timelines and wanting standards-based interoperability. They see bridges, not silos. These are the problems that, once understood, enable possibilities.
So, when a ClinOne customer came to us asking for the ability to customize an authentication method for a specific use case, we didn’t run and design a solution right away. The first thing we did was to dig a little deeper. Why did they need this? How were their needs being met, or not met, today? Through questioning, we identified ways to improve our configuration for maximum flexibility, saving sites time and frustration. It also allowed them to maintain the freedom necessary for more complex studies. In the case of authentication, they could leverage a privacy feature to achieve compliance.
We were able to land in the right place by viewing their stated needs and thinking more broadly. We discovered an approach that tackled their problem but could also help others.
In a word, we fell in love with the problem. We listened, heard, we designed, we tested, we revisited, and we accomplished. They accomplished too, as they could use the technology to focus on pursuing life-saving therapies.
At ClinOne, we’ve named our approach “Pragmatic prioritization.” We know that we can’t solve all our customers’ problems on an individual basis. But we believe that through extensive conversation with our customers and applying analysis and segmentation, we can solve some critical problems—problems we’ve learned to love.
