An Early Access customer was asking me the other day about the origin of the CloudShell OVA I generated for him. I just mentioned this was using our own internal platform also running CloudShell as an internal delivery service. We have the capabilities to generate the latest image of our software using CloudShell pulling in from our code repository. This image can then be shared with other customers for new feature testing or our own internal development team. When I recalled that story with the customer he expressed interest to do just that type of workflow in their own environment, no questions asked. "That's just what I need for my folks" he replied.
This in turns opened up a few fundamental observations inside my highly caffeinated brain:
An ever present challenge for product managers and alike is to figure out what our target market needs, without wandering around in various directions for too long. Sometimes you stumble across a nugget that's the key validation point that you were after, but most of the time you end up listening to the laud voice that seems to gather most of the attention and may guide to a backward point in your journey or even worse, a "cul de sac". Quite often the best conversations with the "community" of potential adopters are in the early stages, when they share their frustration with a problem, before they may have an agenda with a specific feature or workflow in your product. These interactions tend to happen with good odds on the tradeshow floor, such as the last Cisco Live event in Vegas (no pun intended) . Since chance encounters take a lot of time and volume to really happen, let's consider other alternatives.
The topic of trying things out internally is a common theme in software companies but too often overlooked. Powerful technology trends such as Docker were started that way. In some way it is best illustrated with Apple's approach, who considers their first adopters will be internal employees.
We tend to spend all our energy building a great product for our potential customers and yet we underestimate how it could benefit ourselves in the first place. In the case of Quali, this was all about reducing the time our ever too slim QA team spends validating the various configurations was a slam dunk. What could be easier than procuring them with ready to go images of our latest version? Yet it took some internal commitment and resources to make it happen. It is now a great vector of feedback and efficiency that provides a powerful story when presented to external users. Until that happened it would have been hard to extract that information from our customer.
To sum up, there are different avenues to figure out what your customers want. The pull model is about discovering what the market needs, or may want, relying on the willingness or to share their challenges or even ability to express them. The DIY model is all about experimenting internally and sharing this experience with your potential market. Both are valid approaches we at Quali have been actively using at different maturity level of our product journey. Now it's finally time for that well deserved espresso.