One of my early Lean experiments at CloudHealth Technologies was to go on a hunt for businesses that had built internal systems to manage their public cloud cost and infrastructure. I knew I would be building a new product category, and therefore could not look to existing commercial products for validation. My assumption was that if there existed sufficient customer pain, there would also exist innovative people that had cobbled together at least a partial solution to their needs. I knew this with some level of confidence since I had built my own internal system at a previous company. But I also knew the failure to find internal systems "out in the wild" would also tell me something: that the pain was likely not high enough and/or the cost of building an internal system was prohibitively expensive.
After networking broadly, I finally found a DevOps engineer at a hosting company using AWS who told me about a system they built called the Inventory Tool. It took a little convincing, but he eventually showed me what they had created. I can still remember my excitement at seeing the first real validation of my business assumptions since I’d left my job to start a company. The system had many of the features I had expected - but also had a few new ideas that took me by surprise. Buoyed by this success, over the coming weeks I would go on to find three more businesses that had built similar systems, ranging from full-fledged products with web consoles, to simple scripts that pushed data into complex spreadsheets.
Since no company wants to divert resources for building proprietary internal systems, their existence is often validation you are on the right track in your pursuit of a new product category. They provide a powerful lens into both the pain points customers are experiencing, and what they view as viable solutions to this pain. Finding these systems can also rapidly triangulate customer needs in ways that cannot be accomplished through interviews. You effectively receive for free the validated learnings of an early "product" in the market, which you can then apply toward your future commercial solution.
I realize this is not a viable approach in many markets - e.g. robotics, biotech, hardware. But when it comes to software, it is rare to not be able to find someone in our industry who has at least crudely solved some of the critical paint points you identify for a new product. So if you are in the early phases of researching a new product category, I encourage you to take a play from my CloudHealth playbook: go on a hunt for internal systems that solve the pain points you are targeting. There are few better ways I know to validate an early idea and fast track your way to an MVP.