Concensus is in on the validation of the solution! (More details on what the solution is later when we're going public, but...) concerning go or no-go, respondants to the solution validation survey were motivated to use a product that provides the two value propositions, almost unanimously. Concerning whether or not the proposed solution would sufficiently give that value, almost a third said yes, while about half were neutral, which I interpret to mean (based on their enthusiasm for the value propositions) that they're not sure if it would or not. I actually would expect so much uncertainty at this point, because the type of tool, while it improves on a previous category of tools, is really its own category, so no one knows what it will be like to use it. That's why it is time to build a functional prototype! ...Or is it?
Anyone familiar with the Lean Startup Methodology has heard of the Minimum Viable Product, or MVP. There's also this thing called the Minimum Viable Prototype. The MVPrototype is a way to put a solution in front of potential customers to learn what needs to change in order to mold it to their needs and wants, just like the regular MVP, except we're talking about really quick "prototypes" like wireframes, screen mockups, and mock applications. I was going back and forth with Nathan Preheim about what my MVP/rototype should be. The textbook story of the MVPrototype is that you enter a customer segment, learn all about the customers and their pain points, propose a solution, and let them tell you what it should really be. You sit down with them, and sketch it out together, speedily spinning through the Build-Measure-Learn cycle each meeting. This saves oodles of time over developing a fully functional app like the traditional MVP (or my recollection of the traditional MVP from my reading over the years).
I believe my situation is different, however. First, I hesitate to give this as a reason, I myself am in the customer segment, as a long-time software developer, who has seen first-hand the problem I am working to solve. This only partially lessens the need for the MVPrototype though. A single person is not a sufficient representative for all customers in the segment. But it does mean I'm not spending time just trying to understand the customer's everyday life as a developer. The bigger reason though is that neither myself nor those that have shown interest in a solution know exactly what the solution should be exactly, until we start using it! A catch 22 in a sense, but really I think it's just a case where we quickly turn from the MVPrototype to a functional MVP. I have described the proposed MVP to them -- this could be considered an MVPrototype -- and they are mostly unsure if it is the right solution. So now we use it for a while and prove it out.
If the solution required extensive work before having the minimum functionality to address the value propositions, then I'd be very much second guessing myself on brushing past the MVPrototype to the MVP. Fortunately this time around, the MVP should only take roughly a single full-time week's worth of work. In fact, I'm almost finished now! ...And would be finishing it as we speak, except that I'm working at my sons' gymnastics location and am waiting for .NET Core 2.0 to slowly download over their generously-provided guest Internet. (If having the free wifi benefits them because it helps them gain and keep more customers, is it generous? But who am I to assume they didn't have generous intentions.)