Makin' Money, Savin' Time: Are You Solving Problems or Creating Expensive Ones?

Throughout my career, I have been part of several large scale efforts where we were building something, and it wasn’t clear, at least to me, that we didn’t know the problem we needed to solve. We only knew the outcome we wanted. In many instances, stakeholders and leaders were convinced that a new flashy solution would be the trick to increasing profits, reducing losses, saving time, insert any metric. Portals, SaaS tools, AI, a new data structure, insert any flashy technology. None of these solutions are inherently bad, except when implementing them without knowing the actual problem that needs to be solved. I call that a solution in search of a problem.

Many years ago, I was working on a product where the goal was to increase benefit update sales. Another department had developed a really neat portal experience and demoed it to us. Stakeholders were hooked from the word portal. And don’t get me wrong, this portal was sexy. But I was left wondering if it was really necessary. Would it actually increase sales? The current application was short and required very minimal information. I thought this is really important, why aren't they just filling it out? Was a paper form really stopping people from applying? And if we introduced the portal, would it actually increase sales? We needed to figure this out if we wanted the portal to be successful.

Around this time, I was diving deep into User Experience and learning more about product industry trends like MVP and designing to learn. We had a very small and much less experienced team. It was going to take us a very long time to deliver the portal as requested. The situation was ripe for innovation.

So I kicked off a user experience project. I created the script and included our call to action in the testing, not just testing application usability like typically done. I invited our key stakeholders to observe. It was the first time stakeholders had watched real customers use one of our solutions.

The results were unanimous. Every single person said they would ignore our call to action. They explained that they didn’t understand why they needed to complete the application, they were busy, and they received tons of communications. They would probably not take the time to figure it out and would discard our correspondence.

Having this insight, combined with the realization that we didn’t have the resources to build a new portal any time soon, prompted them to consider our proposal for a quick MVP. I partnered with stakeholders and IT leaders to create a simplified solution using a website with very minimal functionality, no integration, and a manual process to monitor and process submissions. From the user’s perspective, they electronically applied. From our perspective, we saved almost a year of development.

So what do you think happened when we launched? Sales actually decreased right after launch. We didn’t lose sales because we delivered a portal, but rather because we weren’t focused on solving problems our customers actually had.

We developed just enough to learn more about our customers. And with the knowledge gained from our User Experience testing, we had a leg up understanding the true issue sooner. It could have been over a year before we found out that our solution was missing the mark and been left to wonder why. Instead, we started building a more robust communication that helped people better understand why they needed to apply. Once we implemented these changes, we finally got what we came for, a steady increase in sales.